Build or buy? When bespoke software makes sense

Buy the tool when the process is the same as everyone else’s. Build when the process is the thing that makes your business different. That is the whole framework, and almost every business we talk to agrees with it in principle. The difficulty is telling which of your processes is which, and most people find out later than they would like, after the subscription has been bent out of shape.

So this piece is about the telling. When a subscription is plainly right, how to spot the moment it stops being, the costs people leave out of the sum on both sides, and a staged approach that avoids the two classic mistakes: building everything, or buying everything and calling the workarounds “process”.

When a subscription tool is right

Most of what a business runs on should be bought, and we will say so across a table even though we build software for a living.

A subscription is right when:

The process is generic. Accounting, payroll, email, calendars, document storage, e-signatures, video calls. Your invoices are not more special than anyone else’s, and the tools for these are mature, cheap per head and well supported.
You do not yet know what you need. Buying something lets you learn what matters for a modest monthly cost before you commit to anything.
The team is small and the process is still changing. Software built around a process that changes next quarter is wasted.
Someone else carries the compliance burden. Payroll and payments are the obvious cases. Let a specialist keep up with the rules.

If every box above is ticked, stop reading and buy the tool. The rest of this piece is for the cases where one of them is not.

When it quietly becomes a spreadsheet with a monthly fee

A bought tool rarely fails loudly. It drifts. The signs are familiar to anyone who has read our piece on outgrowing spreadsheets, because they are the same signs:

Custom fields multiply. The tool has been bent so far that its own vocabulary no longer matches yours, and new starters need a glossary.
“We export it to do the real work.” The tool holds the data, but the actual reporting, planning or allocation happens in a spreadsheet pulled from it every Monday.
Glue everywhere. Three tools connected by automations that one person set up and nobody else understands. When one of them changes its interface, the glue breaks quietly.
Re-keying between tools. The same customer typed into the CRM, the quoting tool and the accounts package, with three slightly different spellings.
The process has been changed to suit the tool. Not because the new way is better, but because the tool could not do the old way.

Any one of these is tolerable. Three together mean you are paying a subscription for a system you have built yourself out of workarounds, and that is the worst of both options: you carry the maintenance burden without the ownership.

The costs people forget when buying

The headline price per seat per month is the one everyone sees. The ones that get left out of the sum:

Seats multiplied by years. A per-seat price is small until you multiply it by the whole team and a five-year horizon, and renewals rarely go down.
Tier jumps. The one feature you need, often single sign-on, an audit log or an API, sits on the next tier up, and the next tier up is priced for a company three times your size.
Workarounds. The daily time cost of doing the task the tool’s way rather than your way, across everyone who uses it.
Re-keying and reconciliation. Any time two tools hold the same fact, someone is paid to keep them agreeing.
Lock-in. Your data in their shape. Export is usually possible and rarely complete, so leaving later costs a migration anyway, on top of whatever you move to.
Their roadmap, not yours. Features arrive when the vendor’s biggest customers want them. Prices and terms change when it suits the vendor.

None of this means do not buy. It means put these in the sum, because the subscription price alone is not the cost.

The costs people forget when building

The build cost is the obvious one and it is real. The ones that get left out:

Hosting and running. Servers, databases, backups, monitoring, certificates. Modest for a well-designed system, but never zero.
Keeping it current. Libraries, frameworks and operating systems move on. A system nobody updates becomes a security risk within a couple of years.
The person who answers. When something breaks at nine on a Monday morning, someone has to be on the end of the phone. Agree who that is before you build, not after.
Year two. The first version proves the idea; the second is when the team knows what they really want. Budget for changes, because a system that cannot change is just a more expensive spreadsheet.

Against all of that sits the thing you get for it: ownership. The code, the data and the direction are yours. Nobody raises your price at renewal, retires the feature you depend on, or decides your data should live somewhere else. If the process is the business, that ownership is worth a great deal. If it is not, it is an expensive way to run a to-do list.

How to tell if a process is yours

This is the question that settles most build-or-buy decisions, and the tests are simple:

Would a competitor copying this process be copying you? If the honest answer is no, buy.
Does it decide who you win, keep or lose? A process that touches revenue directly deserves more scrutiny than one that does not.
Do you describe it in words the tools do not have? If your team has its own vocabulary for stages, roles and hand-offs, and every demo you have sat through calls them something else, that is a sign.
Have you already bent two tools to fit it? Then you have your answer, and the third tool will not be different.
Does it involve data you must control? Who can see what, what must never be deleted, and what a regulator or an auditor will ask for. Bought tools have their own opinions on all three.

The brokerage CRM we built for ABA Commercial Insurance is a fair example. Every brokerage sells and renews policies, so the generic shape is common. But the way this team prospected, handed accounts between roles and tracked renewals was theirs, and it had already outgrown the spreadsheets and the renewal tracker it ran on. The system was built around those stages, with history that is kept rather than overwritten, and it signs in through the Microsoft accounts the firm already used, which is the integration most firms care about first.

A staged approach

Build or buy is rarely all of one. The approach we recommend:

Buy the generic. Accounts, payroll, email, documents, calendars. Pick good ones with proper export and an API, and do not build any of them.
Build the differentiating part, and only that. The one process that is yours. Scope it narrowly: one process, the people who run it, the data it needs. Resist the pull to rebuild everything around it.
Integrate the two. The bespoke system should sign in with the accounts you already have, read from and write to the tools you kept, and avoid holding a second copy of anything they own. Integration is where most of the re-keying disappears.
Review yearly. Processes change. A thing that was generic can become differentiating as the business grows, and the reverse happens too. Ask the question again rather than assuming last year’s answer holds.

What to do next

Write the processes down, one line each, and mark each one generic or yours. Most lists end up with a dozen generic entries and one or two that are not. Those one or two are where bespoke software earns its keep, and the dozen are where it does not. If you would like a second opinion on the list, we are happy to give one, including when the answer is to buy.

Build or buy? When bespoke software makes commercial sense