When Not to Build Custom Software

We build custom software. We also spend a meaningful share of our first conversations explaining why a prospective client should not.

That is not modesty. Custom software has a cost structure that people consistently underestimate, and the failure mode is specific: a system gets built, it works, and then it slowly becomes a liability because nobody budgeted for the eight years after launch.

The four conditions

Custom software is justified when at least one of these is clearly true. Not arguably true — clearly.

The process is a genuine differentiator. If the way you underwrite, route, price or schedule is a reason customers choose you, encoding it in software you control is a defensible investment. If your process is simply how your industry does it, a product already exists.

No product fits without unacceptable compromise. Note the word unacceptable. Every product requires compromise. The question is whether the specific compromises cost you more, annually, than building and running your own.

Integration cost exceeds build cost. Sometimes the product is fine but connecting it to your estate is where the money goes. When you have priced three years of integration and it approaches the cost of a purpose-built system, the comparison changes.

The scale makes per-seat pricing absurd. At 4,000 users, a $40-per-seat-per-month product costs $1.9M a year. At that number, building starts to look like arithmetic rather than ambition. At 40 users it never does.

Four arguments that do not hold

These come up in nearly every build-versus-buy conversation and none of them survive scrutiny.

"We need it to work exactly the way we work." Sometimes true, usually not. The way you work is frequently an accumulation of accommodations to previous tools rather than a considered design. Adopting a well-designed product's process is often an upgrade, and it is certainly cheaper.

"It will be cheaper than the licence fees." Only if you count the build. Total cost of ownership includes hosting, security patching, dependency upgrades, browser and OS compatibility work, incident response, feature development to keep pace with expectations, and the engineer-hours consumed by all of it. Our rule of thumb: annual ownership cost runs 15–25% of the original build, indefinitely.

"We can build it in three months." You can build the demo in three months. Production software includes permissions, audit logging, error handling, edge cases, data export, accessibility, mobile layouts, monitoring, backups, onboarding and the long tail of things a mature product solved years ago. The demo is 20% of the work.

"We will own the IP." You will own a codebase. Whether that is an asset or a liability depends entirely on whether the software is a differentiator. Owning the IP to a mediocre internal ticketing system is not a strategic position.

The comparison nobody runs properly

When we do run the numbers with a client, the buy side is usually understated in one place and the build side is understated in three.

The buy side omits integration and configuration cost, which is often two to three times the first-year licence.

The build side omits the ongoing 15–25%, the opportunity cost of the engineers who are now maintaining an internal tool instead of working on the product, and the key-person risk when the two people who understand the system leave.

Run over five years, with those included, the answer flips more often than people expect.

The middle path people forget

Build versus buy is a false binary. The most cost-effective answer is frequently: buy the platform, build the differentiator.

Buy the CRM and build the pricing engine that is actually your edge. Buy the e-commerce platform and build the configurator nobody else has. Buy the identity provider — always buy the identity provider — and build the workflow on top of it.

This gets you the maintained, secure, feature-complete foundation for a fraction of the cost, with custom investment concentrated where it creates advantage. It is less satisfying than a greenfield build and it is usually the right answer.

Where we land

If you are considering custom software, ask three questions in order.

Is this a differentiator, or is it table stakes? If table stakes, buy.

If a differentiator: can I buy the platform and build only the differentiating part? Usually yes.

If genuinely no: have I costed five years of ownership, not just the build? If not, do that before deciding.

We would rather spend an hour helping you reach buy than six months building something you will regret. It is also, unglamorously, better business — clients who were told the truth early tend to come back when they have a problem that genuinely does need building.

---

Working through a build-versus-buy decision? We are happy to look at it with you, including when the answer is not to hire us. Or read about our approach to ERP and CRM implementation, where the same discipline applies to customisation.