Build or buy? Buy, unless this is true.

For any capability that is not specific to how your business competes, a subscription is almost always the better decision. Accounting, payroll, email, storage, HR records, helpdesk, video calls - these are solved problems with mature products, and building your own version means paying to reach a standard the market reached years ago.

That default holds even when the product is imperfect. A tool that does eighty per cent of what you want, today, with someone else carrying the security patching and the uptime, usually beats a bespoke tool that does a hundred per cent in six months and then needs an owner forever.

The default breaks in a small number of specific situations. They are worth naming precisely, because vague dissatisfaction with an existing tool is not one of them.

Building is justified when at least one of the following is clearly true - and the clarity matters, because each of these has a plausible-sounding imitation that does not justify a build.

Build-versus-buy comparisons usually fail by comparing a build quote to a monthly licence, which is not a comparison of like things. The build quote is a one-time construction cost. The licence includes construction, hosting, maintenance, security patching, compliance, support, and continued development, spread over the vendor's whole customer base.

A fair comparison prices the same scope on both sides over three years. On the build side that means the initial build, plus hosting and infrastructure, plus ongoing maintenance - dependency updates, security patches, browser and platform changes, integration breakages when other vendors change their APIs - plus support and the cost of changes as the business evolves, plus the internal time to specify, test, and adopt it.

On the buy side it means subscription costs at realistic future headcount, plus configuration and implementation, plus any integration work, plus the cost of the workarounds the team will maintain for whatever the product does not do.

Run both. Sometimes the build wins clearly, sometimes the subscription does, and often they are close enough that the decision should turn on strategic fit and risk rather than on cost.

The framing that produces the best outcomes is not build-versus-buy at all. It is: buy the commodity, build the differentiator, integrate the two.

Keep the accounting package, the CRM, the storage, the email. Build the specific thing your business does that none of them represent - the quoting engine, the compliance workflow, the operations dashboard, the client portal - and connect it over APIs so the systems of record stay where they are.

This keeps the surface area you own small, which is the single best predictor of long-term maintenance cost. It also fails better: if a bespoke component turns out to be wrong, you replace one component rather than a platform.

A custom build should leave you with an asset you control, not a dependency on whoever wrote it. That is a matter of contract and practice, and it is much easier to agree before a project than during one.

Insist on full ownership of source code, database, and documentation, delivered into your own accounts and repositories rather than the builder's. Insist on documented deployment - a written, followed procedure for getting the system running from scratch. Insist on tests around the parts where a failure is expensive, and on monitoring and alerting from launch rather than after the first incident. Insist that access control, secret management, backups, and a tested restore are in scope, not optional extras.

Then agree what happens after launch. Software that is used changes; software that stops changing stops being used. A defined support arrangement - who fixes what, how quickly, and at what cost - is part of the decision to build, not a separate conversation afterwards.