Buy it or build it?

The question normally arrives as "how much would it cost to have this built?". That's the wrong question, because the price only makes sense once you know whether building is the right answer at all.

When you should buy

• The problem is common: accounting, payroll, email, e-signatures. Thousands of companies have exactly your version of it
• A mature product exists, with years of features you'd otherwise have to think of yourself
• The process isn't a competitive advantage — it's just a process that has to happen
• You want somebody else responsible for maintenance, security and keeping up with regulation

Most of the time, the answer is buy. We say this regularly to people who arrived asking us to build something.

When off-the-shelf stops being the cheap option

The moment you start paying people to work around the software. The licence is visible and modest. The two hours a week that four people spend copying data between systems is invisible and enormous, and it never appears on an invoice.

• You export from one system to paste into another, every week
• You pay per user for a tool where most of those users need three of its two hundred features
• The one process that makes you different from your competitors is the one the software refuses to do
• You need a change, and you're waiting on a vendor who has no reason to care

The honest arithmetic

Custom costs more up front and carries no per-user fee. That trade only pays back if the thing lives long enough. So the real question isn't about price — it's: will this process still exist, roughly in this shape, in three years?

If yes, building can win comfortably. If it's a workaround for a temporary mess, buy something cheap or do nothing at all, and fix the mess.

The obstacle: whatever you build has to be maintainable by somebody else

The failure we see most often isn't a bad build. It's a good tool built by someone who then left. It works until the day it doesn't, and by then nobody can open it.

So if you build, insist on the boring guarantees: the code in an account you own, plain-language documentation, ordinary well-known technology, no exotic dependency that only one person understands.

We say this against our own commercial interest. The best outcome of a project is a system you could hand to another company tomorrow. Anyone unwilling to set that up is selling you a hostage situation with an invoice attached.

The answer is usually both

In practice most real answers are hybrid: buy the standard parts — accounting, CRM, mail — build the thin layer that is genuinely yours, and connect them properly. The custom piece is almost always much smaller than people fear before they ask.

Buy what makes you the same as everyone else. Build only what makes you different.