Why technology decisions go wrong
Most bad technology decisions share a common root cause: the decision was made before the requirements were clearly understood.
Teams choose platforms based on what they’ve used before, what an agency recommends (often the platform the agency builds on), what they saw at a conference, or what a competitor uses. The requirements — what the technology actually needs to do, for whom, at what scale, maintained by which team — are established after the decision, not before it.
The result is a platform that doesn’t fit the use case, a build that doesn’t account for operational reality, or a vendor relationship that becomes impossible to exit.
The build vs buy question is the wrong starting question
Most teams frame the decision as “should we build this or buy it?” But this is the second question, not the first. The first question is: “What does this system actually need to do?”
Until you’ve answered that with specificity — not “we need a CMS” but “we need a system that allows three non-technical editors to publish content across four content types, with a structured approval workflow, maintaining brand compliance, integrated with our CRM, accessible to an offshore development team, with a total cost of ownership under £X per year” — any evaluation you run is comparing incomparable things.
| The requirement “we need a CMS” has approximately 300 right answers. The requirement above has about four. |
A five-question framework
Question 1: Is this a commodity or a differentiator?
Buy commodities. Build differentiators.
If the thing you’re building does something that dozens of existing products already do well — content management, email marketing, analytics, booking systems — buy a product. Your time and development budget is better spent on the things that are genuinely specific to your business.
If the thing you need is specific to your business model, requires custom logic that no off-the-shelf product supports, or represents a genuine competitive advantage — consider building, but with clear eyes about what that means.
Question 2: What is the true total cost of ownership?
Off-the-shelf products have a sticker price. They also have implementation costs, ongoing licence fees, integration costs, training costs, and the cost of working around the things the product doesn’t do. Custom builds have build costs, hosting costs, and — most significantly — ongoing maintenance costs. Software has to be maintained. Security patches. Dependency updates. Bug fixes. New feature development.
Calculate a five-year TCO for both options. Include the maintenance cost of a custom build at a realistic developer day rate. Include the platform-lock and switching cost of an off-the-shelf product. Most teams who choose to build underestimate maintenance costs by a factor of three to five.
Question 3: What is your team’s operational capability?
The right platform for a team with three developers is different from the right platform for a team with one part-time developer. The right CMS for a technical marketing team is different from the right one for a team of content editors who have never touched a code editor.
Evaluate options against your team as it exists today, with a realistic projection of how it will change in the next 18 months. Don’t evaluate against the team you wish you had.
Question 4: What are the exit costs?
Every platform decision creates lock-in of some kind. Proprietary CMS platforms lock in your content schema. Custom builds lock in your development team’s knowledge. Cloud platforms lock in your data architecture. Vendor-specific features lock in your workflows.
Before committing, ask: if this doesn’t work out, what does switching look like? Is our data portable? Can a different team maintain this? What would it cost to migrate in three years? The answer rarely changes the decision — but it should inform how you negotiate contracts and structure your implementation.
Question 5: What is the timeline pressure?
Builds take longer than estimates. Always. If you need something in six weeks, a custom build is almost certainly not the right answer regardless of its other merits. Buying a product and configuring it is faster — and in most cases, faster is the right trade-off.
Timeline pressure also degrades build quality. A custom build delivered under pressure is a maintenance liability. If the timeline is fixed, buy or configure. If the timeline is flexible enough for a proper build, make sure that’s genuinely true before you start.
Applying the framework: an example
A mid-sized e-commerce business is choosing between extending their existing WooCommerce store and migrating to Shopify Plus. Using the framework:
- Commodity or differentiator? E-commerce functionality is a commodity for most retailers. The differentiator is in the brand, the product, and the customer experience — not the platform.
- TCO? WooCommerce extension requires ongoing developer maintenance for security and compatibility. Shopify Plus is a predictable monthly fee with maintenance handled by the platform.
- Team capability? Their team has a part-time developer and no dedicated DevOps. WooCommerce hosting and security management is a burden they struggle with.
- Exit costs? Shopify has proprietary features but decent data export. WooCommerce data is owned but requires hosting management.
- Timeline? They need to launch a new international market in four months. Custom development is ruled out.
Conclusion: Shopify Plus, strongly. The framework didn’t produce a surprising answer — but it produced a documented, defensible answer that the team could present to stakeholders with confidence.
