Custom Software · Deep dive
Custom or platform: the build-vs-buy decision grid
When to build custom software and when to buy a platform: a decision grid built on process fit, total cost of ownership, lock-in, data ownership and time-to-value.
ARCHITECTURE · BUILD-VS-BUY
In · Capabilities to enable
Out · Build / Buy / Compose
Core vs commodity (value map)
Breaks the system into its capabilities and places each on the core/commodity axis: it separates what differentiates you in the market — and deserves owned code — from what has commoditized and is simply bought from the cheapest provider.
Fit with the process
Measures how proprietary your workflow is: a generic process with settled industry standards pushes toward the platform, while a workflow that is part of your advantage pushes toward custom, because here the workarounds a platform imposes cost more than purpose-built code.
5-year TCO
Computes the five-year cost including maintenance, integration and training — not just license or initial quote — because most of the cost of software lands after go-live and that is what flips the verdict.
Lock-in & exit rights
Weighs the exit cost before you enter: contracts, data portability and hard-wired integrations decide whether you'll hold leverage at renewal or find yourself with none, facing a vendor who knows it.
Data ownership
Checks that the data setting you apart stays yours, exportable in open standards and independent of the vendor: a single non-exportable item can flip the decision, because an asset turned hostage outweighs any sticker-price saving.
Time-to-value
Balances the urgency of value against the durability of the advantage: a proven, already-available solution gets you moving now, while a structural differentiator justifies a longer, sustained implementation.
The signs your build-vs-buy line was drawn in the wrong place
The question is never "custom or platform." It is: which capability deserves owned code, and which is a commodity to buy. These symptoms mean the line was drawn in the wrong spot.
- You are customizing a standard platform until it no longer resembles itself: every vendor release breaks your configuration, and "off-the-shelf" has become a permanent development project.
- You built a commodity from scratch — authentication, payments, notifications — spending engineering capacity on problems the market already solved, instead of on your competitive edge.
- The data that sets you apart lives inside a vendor in a proprietary format with no export to open standards: it is no longer an asset, it is a hostage.
- No one ever ran the five-year number : the decision was made on a license sticker or a build quote, ignoring the maintenance, integration and training that dominate the lifecycle.
- Switching vendors is unthinkable : multi-year contracts, non-portable data and hard-wired integrations have raised the exit cost to a level that strips you of all leverage at renewal.
For CTOs, COOs and operations leaders who must decide where to invest engineering capacity and where to lean on the market, with criteria that hold up in front of the board.
Buy the commodity, build what sets you apart
The most durable operating rule is not financial, it is strategic: place every capability on the value map and decide by where it sits, not by the preferences of whoever writes the code. A discipline formalized by Wardley Mapping.
Core vs commodity, not personal taste
A capability that differentiates you in the market and evolves fast deserves owned code. A capability that has commoditized — the same for you and your competitors — is a cost center: you buy from the cheapest provider and move on. Building a commodity is burning engineering capacity on a solved problem.
Process fit is the real divide
If your workflow is generic and the industry has settled standards, a platform wins on speed. If the workflow is proprietary and part of your advantage, the platform forces workarounds that, summed up, cost more than purpose-built code. A platform bends you to its model; custom bends the software to yours.
Configuring is not free
Between buy and build sits a third path — configure and integrate — but it is not neutral. Fitting a complex platform into a specific workflow, with data migration and training, carries a real cost before the first transaction. The trap is over-customization: start from the recommended setup and iterate on usage data, don't rewrite everything on day one.
Compose: the best of both, with discipline
The mature approach is hybrid: market capabilities for the standard functions, connected through documented APIs, with internal engineering capacity concentrated on what truly sets you apart. This is the composable logic (microservices, API-first, cloud-native, headless): replaceable components that change without collapsing everything wired to them.
The decision must be structural, not emotional
Mapping capabilities makes the choice legible: you see where each component sits on the genesis-to-commodity axis, what it depends on, and where evolution is pushing. The build-vs-buy line stops being a departmental preference and becomes a defensible architecture decision.
How we draw the line, capability by capability
We don't decide "custom or platform" for the whole system. We break the system into capabilities and run each through the same gates. The output is a map, not an opinion.
We break the system into its capabilities and place each on the core/commodity axis: what differentiates you, what has become standard. This separates what is worth owned code from what you simply buy.
For each capability we test how proprietary your workflow is. 60-70% standard with manageable exceptions: configure. Workflow that is part of the advantage: build. Generic workflow: buy.
We compute the five-year cost including maintenance, integration and training — not just license or initial quote. In parallel we measure the exit cost: data portability, export rights, dependence on integrations.
Each capability gets a verdict — build, buy or compose — and its place in the architecture. Commodities go behind documented APIs; the differentiator becomes owned code with the data under your control.
From capability map to a defensible decision grid in weeks, not a quarter of studies.
Build, Buy or Compose: the decision gates
Every capability runs through five levers. It is not a point total: a single lever can flip the decision (proprietary, non-exportable data outweighs any sticker-price saving).
| Decision lever | Pushes toward BUY / platform | Pushes toward BUILD / custom |
|---|---|---|
| Position on the map | Commodity capability, identical to competitors | Core capability that differentiates you and evolves fast |
| Process fit | Generic workflow, settled industry standards | Proprietary workflow; the platform forces costly workarounds |
| 5-year TCO | Maintenance and risk carried by the vendor | Volume and length of use amortize the build cost |
| Lock-in & exit | Export to open standards, exit for convenience, API integrations | Critical data must stay owned, independent of the vendor |
| Time-to-value | Value needed now; proven solution already available | The advantage justifies a longer, sustained implementation |
The four assets the grid keeps safe
A sound build-vs-buy decision doesn't only optimize cost. It protects what, once lost, cannot be bought back.
Data ownership
The data that sets you apart stays yours, exportable in standard formats and independent of the vendor. Not a hostage in a proprietary silo, but a negotiable asset that gives you leverage at renewal.
Engineering capacity, well spent
Every development hour goes to your competitive edge, not to a commodity the market already solved. Custom where it counts, market where it doesn't.
Exit rights
Data portability, documented API integrations and no proprietary wiring keep the switching cost low. The ability to leave is what keeps you on fair terms.
Composable architecture
Replaceable capabilities connected through APIs: one component changes without the rest collapsing. The system stays alive over time, not a monolith to rebuild.
Build what sets you apart, buy what you share with your competitors.
The questions we get before we decide
Is custom always more expensive than a platform?
Not over the lifecycle. Most of the cost of software lands after go-live — maintenance, integration, training. On a commodity the platform wins because it offloads that cost to the vendor. On a core capability with high volume and length of use, custom amortizes while a platform's pricing climbs over time. The answer is in the five-year TCO, not the entry price.
Can I buy now and build later?
Yes, and it is often the right move — as long as you don't get trapped. Buying to start fast makes sense if the data stays exportable in open standards and integrations run through documented APIs. If the vendor holds your data in a proprietary format, "later" becomes a costly migration you will never do. Portability is negotiated at signing, not at divorce.
How do we avoid building something the market does better?
By mapping every capability before writing code. If a function has become standard — the same for you and your competitors — building it is engineering capacity burned. Owned code is reserved for what differentiates you and evolves; everything else is bought or composed through APIs. That discipline is what separates an investment from an expense.
Cases
From problem to result — anonymised.
The platform bent out of shape
Problem A retailer had customized a standard e-commerce platform until it no longer resembled itself: every vendor release broke the configuration and "off-the-shelf" had become a permanent development project, with the pricing engine — their real differentiator — trapped inside constraints they didn't control.
Method We mapped capabilities on the core/commodity axis: catalog, checkout and payments kept on the platform as commodities behind documented APIs; the pricing and promotions engine, part of the competitive edge, extracted as an owned service wired in a composable way.
Result Vendor releases stopped breaking the system, engineering capacity went back to pricing instead of workarounds, and the logic that sets them apart became their own code — replaceable without collapsing the rest.
Data held hostage
Problem A financial services firm kept the customer data that set it apart inside a vendor, in a proprietary format with no export to open standards: switching was unthinkable and at renewal the vendor held all the leverage, because exit was effectively foreclosed.
Method We applied the lock-in and data-ownership gates: renegotiated export rights to standard formats at the contract break, moved critical integrations onto documented APIs, and brought the differentiating data back under internal control, leaving commodity functions where they were.
Result The exit cost dropped to the point of restoring leverage at renewal, the data became a negotiable asset again instead of a hostage, and the ability to leave is what kept them on fair terms.
The commodity built from scratch
Problem A logistics operator had built commodity capabilities from scratch — authentication, notifications, user management — burning engineering capacity on problems the market had already solved, while route planning, their real advantage, stayed under-invested.
Method We ran every capability through the value map and the five-year TCO: retired the custom commodities in favor of market services behind APIs, and concentrated developers on route optimization, where volume and length of use amortize the purpose-built code.
Result Every development hour went back to the differentiator, commodity maintenance shifted to vendors, and the architecture became composable — replaceable components that change without rebuilding the whole block.
Go deeper