Off-the-shelf or built for you? How to decide, and when each is a mistake

Every firm that outgrows its spreadsheets faces the same fork: buy a package, or have something built. Both camps have salespeople, and both routes have wreckage. Having built systems for firms that tried packages first, we see the decision from an unusual angle, and the honest version fits in one article.

The question that decides it

Strip away the feature lists and one question remains: is the way you run your operation a commodity, or is it part of your edge? A commodity process should be bought. Your bookkeeping is not why clients instruct you, so buy the accounting package everyone else uses and enjoy the maturity, the compliance updates and the accountant who already knows it.

But some firms win work precisely because of how they operate: faster turnarounds, a referral model competitors cannot match, a standard of evidence others do not offer. Software shapes process, so putting an edge like that through a package grinds it toward the industry average, one "the system does not do that" at a time. Processes that ARE the business are the case for building.

How buying goes wrong

The failure of the package route is rarely the day-one decision; it is the drift that follows. The signs, usually visible about eighteen months in: you pay per seat for modules nobody opens. The workflow lives half in the package and half in spreadsheets covering its gaps, so people key things twice. Reports need exporting to Excel to become useful. And the renewals keep coming, because leaving means losing the history locked inside.

None of that means the package was wrong. It means the fit was wrong: a standard tool was asked to carry a non-standard operation. The spreadsheet sprawl it was bought to end has quietly reassembled around it.

How building goes wrong

Custom software has its own graveyard, and pretending otherwise would make this article a pitch. Builds fail when they start from a wish list instead of the actual workflow, when scope grows faster than working software appears, and when the thing finally ships as a prototype that cannot survive real load. They also fail through dependence: a system only its builder can change is a rented system, whatever the invoice said.

The protections are unglamorous. Start from how the firm runs today, not how anyone wishes it ran. Ship something real early and put it under real work. Insist the code, the data and the deployment belong to you. And judge a builder by working systems in production, not by decks; ours are here.

What building looks like when the fit is right

The clearest example we can offer: a UK probate property services firm whose edge included a two-sided introducer model connecting estates to agents. No product on the market matched it, because the model was theirs. So we built Appraised, a valuation engine covering England and Wales on public data, with the introducer platform around it, alongside the operations system that runs their daily casework. A package would have flattened the very thing that made them different; the build amplified it.

Whichever route you take, the destination worth paying for has the same shape, built from the same six elements: one record everything references, live figures, generated paperwork, and a history that stands up to scrutiny.

A test you can run this week

Book demos of the two leading packages for your sector and bring your three most awkward real cases. If a demo can walk each one end to end without the phrase "you would handle that outside the system", buy the package with a clear conscience. Every time you hear that phrase, note what "outside the system" actually means: another spreadsheet. Three or more, and you have your answer about which route you are on.

Common questions