We build custom software for a living, and the honest position is that most organisations asking us about it should buy something instead. Bespoke development is the right answer for a minority of problems. The skill is telling which minority you are in, and the decision is rarely about features — it is about which costs and risks you are willing to own permanently.
Start by classifying the process, not the software
The first question is not “can we find a product that does this?” but “is the way we do this a source of advantage, or just the way we happen to do it?”
Payroll, accounting, holiday requests, helpdesk ticketing, email marketing, expense claims — these are generic processes. Thousands of organisations do them approximately the same way, several vendors have spent a decade refining products for them, and your variation from the norm is usually accident rather than strategy. Building your own here means paying to reinvent something you can rent, then paying again forever to keep it working. There is a specific version of this trap worth naming: a process that feels unique to you because of how it evolved, but which a well-configured standard product would handle if you were willing to change the process. Changing the process is almost always cheaper than encoding the accident in code.
Now the other side. Some processes genuinely are the business. A logistics firm whose routing and consolidation logic is why customers choose it. A manufacturer whose quality workflow encodes twenty years of hard-won knowledge about its own equipment. A firm whose regulatory position depends on data never leaving a specific environment. In those cases the software is not overhead, it is the product, and the constraints of someone else’s roadmap are a real cost.
A test that cuts through most of it
If you adopted the market-leading product and did things exactly the way it expects, would you lose anything a customer would notice or pay for? If the answer is no, buy it. If the answer is yes, be specific about what would be lost and what it is worth per year — that figure is your budget for the bespoke alternative, and it is often smaller than expected once written down.
Total cost of ownership, honestly compared
The common mistake is comparing a one-off build price against a monthly subscription and concluding the build wins after eighteen months. That comparison omits most of what a SaaS subscription actually buys you.
- Buying: licence fees that grow with headcount, configuration and implementation effort, data migration, integration work, training, and the cost of working around whatever the product does not do. Plus the risk of price rises, feature removal, or acquisition and sunsetting.
- Building: the build, plus infrastructure, plus security patching and dependency upgrades, plus platform changes forced on you by browser and mobile OS vendors, plus support, plus the feature backlog that never ends because your own users keep asking. And the standing requirement that someone competent remains available to maintain it.
Model both over five years, not two. Include the year in which you are not adding features but still paying to keep the system safe and current, because that year exists and it surprises people. And include the exit cost on both sides: migrating off a SaaS product you have outgrown, or decommissioning a bespoke system that nobody remaining understands.
Both options create dependency — they just differ in kind
Vendor lock-in is the usual argument for building. It is a real risk: pricing power sits with the vendor, your roadmap requests compete with everyone else’s, and your data lives in their schema. If a product becomes critical to your operations, you have handed someone else a lever.
But custom software creates its own dependency, and it is quieter. It attaches to whoever built it, to the specific people who understand it, and to the technology choices made at the start. A bespoke system three years old, undocumented, with dependencies nobody has upgraded and an original developer who has moved on, is not more independent than a SaaS subscription. It is less, because at least the SaaS vendor has a support desk.
You reduce build-side dependency with things you should insist on contractually from day one: you own the source code and the intellectual property outright; the repositories and cloud accounts are in your organisation’s name, not the supplier’s; the system runs on mainstream, widely-understood technology rather than something exotic; another competent team can set it up locally from written instructions; and there is documentation aimed at a successor rather than at you. If a supplier is reluctant about any of these, that reluctance is the answer to your build-versus-buy question.
When bespoke is clearly wrong
- The process is generic and a mature product exists. You will not out-build a vendor with a hundred engineers and a decade of edge cases already handled.
- The requirement is regulatory paperwork rather than operations — accounting, statutory filing, payroll compliance. Buy the thing whose vendor is contractually obliged to track legislative change.
- Nobody internally will own it. Custom software needs a decision-maker on your side indefinitely, not just during the project.
- You cannot fund year two. A build you cannot maintain is a liability with a launch party.
- The real motivation is dissatisfaction with a product you have not properly configured or trained anyone to use.
When bespoke earns its keep
- The workflow is a genuine differentiator and standard products force you to work around it in ways customers feel.
- You are paying per seat for a fraction of a product’s capability at a scale where the arithmetic has decisively turned.
- The system spans several existing tools and the value is in the connective logic between them, which no single vendor owns.
- Data residency, security or audit constraints rule out available products outright — a real constraint, not a preference.
- The software is what you sell.
- The hardware or environment is unusual enough that no product targets it — which is common in industrial and IoT work, where fleet-specific telemetry, provisioning and update requirements rarely match a generic platform.
The middle option that usually wins
Framing this as a binary is the most expensive mistake available. In practice the strongest architecture for most organisations is standard products for the generic parts, connected by bespoke integration, with custom development reserved for the narrow slice that is genuinely yours.
Concretely: keep the off-the-shelf accounting system, CRM and identity provider. Build the pricing engine, the operational workflow, or the customer-facing portal that no vendor sells. Move data between them deliberately, with a clear view of which system is the source of truth for each entity. You get vendor-maintained commodity software where commodity software is fine, and you spend your engineering budget only where it buys something.
This does introduce its own cost — integrations break when vendor APIs change, and someone has to own that. It is still usually far cheaper than rebuilding a CRM. The discipline is to keep the custom layer thin and clearly bounded, and to resist its steady expansion into territory a product already covers.
Before you commission anything
Write down the three things a standard product cannot do for you, in operational terms rather than feature names. Put a number on what each is worth per year. Then ask whether that total funds not just building the alternative, but running it for five years. If it does, you have a case worth taking to a supplier. If it does not, you have saved yourself a project — and that is a good outcome, not a failed one.