Build or buy, decided on the part that actually differs
The decision is usually framed as a cost comparison and decided on a licence fee, which is the smallest number involved. The questions that determine the outcome are whether this capability is where you compete, what the integration really costs, and what happens the day the supplier changes their pricing.
Part ofCustom Software Development
Every organisation runs on capabilities that are identical to everyone else's and a small number that are not. Building the first kind is expensive novelty; buying the second kind means outsourcing the thing customers chose you for. Most bad decisions in either direction come from not sorting the capability into the right category first.
The first question: does this differentiate you?
A capability differentiates if a customer would notice it being worse, or if the way you do it is part of why they chose you. Almost everything fails that test, which is a useful result rather than a discouraging one.
Cost the integration, not the licence
Comparing a subscription against a development estimate omits most of what buying costs and all of what building costs after launch. Both sides need their full shape.
The row that decides most comparisons is maintenance. Software is not a capital purchase that then sits still: it needs dependency updates, security patches and adaptation to platform changes indefinitely. A build justified on first-year cost is usually being compared against a subscription on a basis that ignores years two through seven.
The fit question, asked honestly
A product that meets 80% of your requirements is not 80% of a solution. The remaining fifth determines whether you end up with a tool that works or a tool plus a permanent layer of workarounds.
- List what it cannot do, specifically, from a trial rather than from the sales material.
- Decide which gaps are genuine requirements and which are habits you could change. Adapting your process to a good tool is often correct.
- Cost the workaround for each real gap, including the ongoing human effort, not only the build.
- Check whether the gaps are closable — an extension point or API means the gap is work; no extension point means it is permanent.
- Ask whether the gaps grow with you. A manual step at fifty records is fine and at fifty thousand is a second system.
Step two is where the most value sits and where it is hardest to be honest. Many stated requirements are descriptions of how the current process happens to work, and changing them costs less than the customisation needed to preserve them.
The exit question, which is rarely asked
Every purchase is also a commitment to a supplier's future decisions about price, direction and continued existence. The time to ask what leaving would take is before arriving.
- Can you get your data out, completely, in a usable format? Not a PDF export, not a paginated API you would need weeks to drain
- Do they hold data you cannot reconstruct? Historical events are irreplaceable in a way that a customer list is not
- How deeply would their model shape yours? A tool whose concepts leak into your schema is much harder to leave
- What is the pricing trajectory? Per-seat or per-transaction pricing that is comfortable now may not be at ten times the volume
- What happens if they are acquired or shut down? For a small supplier this is a real scenario with a real plan required
The answers that are neither
Framing it as a binary hides the options that are frequently best.
The last row is the one teams skip past and it is frequently correct early on. A process handled by a person for six months produces a precise understanding of the requirement, which is the input that makes the eventual build or purchase a good one rather than a guess.
The decision reduces to two sentences worth writing down. Build what customers chose you for. Buy what they would never notice — and cost the buy at five years, including getting out.
Questions
How do I decide whether to build or buy?
Start by asking whether the capability differentiates you — whether a customer would notice it being worse, or whether the way you do it is part of why they chose you. Build that; buy everything else. Then cost the buy over five years including integration, migration and eventual exit, and cost the build including maintenance, which is the permanent figure that most comparisons omit.
What is the most commonly regretted decision to build?
Authentication. It looks like a week and is not: password reset, session management, multi-factor, account recovery, enumeration resistance, breach-list checking, audit logging, and an ongoing obligation to keep pace with attacks. The mistakes are severe and silent. Unless identity is your product, it is the clearest buy available.
Is a product that meets 80% of requirements good enough?
That depends entirely on the other fifth. List what it cannot do from a trial rather than sales material, decide which gaps are genuine requirements and which are habits you could change, and check whether the gaps are closable through an extension point or permanent. Also ask whether each gap grows with you — a manual step at fifty records is fine and at fifty thousand is a second system.
What should I check before committing to a supplier?
Whether you can get your data out completely in a usable format, whether they hold anything you could not reconstruct, how deeply their concepts would shape your own schema, and the pricing trajectory at five and ten times your current volume. Per-seat or per-transaction pricing is a commitment whose cost scales with your success, and the date at which it exceeds the cost of building is worth calculating before you integrate deeply.