Build, buy or extend? A framework for deciding when a custom internal platform is justified — and when it just recreates software you could licence.
The build-versus-buy conversation usually gets framed as a cost comparison. It is not. It is a question about where your business is genuinely different from everyone else's, and whether that difference is worth maintaining software for.
The one question that decides it
For each process, ask: is the way we do this a competitive advantage, or just how we happen to do it?
- Advantage — a routing algorithm that saves you 20% on fuel, a pricing model competitors cannot replicate, a workflow that lets you quote in an hour when the industry takes a week. Worth building and owning.
- Just how we do it — payroll, general ledger, expense claims, holiday booking. Licence it. Nobody has ever won a market with a better expenses form.
Most organisations have one or two genuine advantages and a long tail of the second kind. That points at the answer for most: buy the platform, build the differentiator, integrate them properly.
The honest cost of custom
Building is not a one-off. The costs that get forgotten:
- Maintenance — roughly 15–20% of build cost annually, forever
- Key-person risk — the developer who knows why it works that way
- Compliance — audit trails, data retention, access control, all of which a licensed platform ships with
- Onboarding — no external training material, no hiring pool who already know it
The honest cost of off-the-shelf
- Process compromise — you will change how you work to match the software
- Customisation debt — heavy configuration makes upgrades painful and is its own form of lock-in
- Per-seat pricing that scales with headcount whether or not value does
- Exit cost — getting your data out in a usable shape years later
The failure mode to avoid: buying a large platform and then customising it so heavily that you have paid for both options and can upgrade neither. If you find yourself rebuilding core behaviour inside someone else's system, that decision was made wrong.
The middle path most companies should take
Licence the commodity layer. Build a thin, well-defined system for the part that is genuinely yours. Integrate them with a clear contract between the two, so either side can be replaced without a rewrite.
In practice this means:
- Map every process and mark it advantage or commodity — honestly
- Buy for commodity, without customising beyond configuration
- Build only the advantage, small and well-tested
- Define the integration boundary explicitly — an API, a schema, an owner
- Review annually; things move between categories over time
Signs you are about to make an expensive mistake
- The business case rests mainly on avoiding licence fees
- Nobody can name the specific advantage the build protects
- The scope includes reporting, user management and workflow you could licence
- There is no plan for who maintains it in year three
- The timeline is longer than eighteen months before anything ships
We cover this ground in more detail when scoping enterprise platform work — the useful first deliverable is usually a written problem statement everyone signs off on, before any technology is chosen.
Frequently asked questions
How long does a custom internal platform take?
Something genuinely useful should be in users hands within a few months, not at the end of a two-year programme. If the first release is more than six months out, the scope is probably wrong.
Can we start with off-the-shelf and build later?
Usually the best sequence. Buy to establish the baseline and learn where the real friction is, then build the specific piece that friction justifies — with evidence rather than assumptions.
What about low-code platforms?
They fit well for internal tools with modest logic and low volume. They struggle at scale, with complex data models, and when you need fine control over performance or integration.
