Most businesses should buy. We build custom software, and we still say that.

Buy, in most cases — here’s why we say that

A product that thousands of businesses already use has had its edge cases found by those thousands of businesses. Yours has not. That is the single biggest difference between buying and building, and it does not show up on a feature comparison.

The second difference is who carries the maintenance. When a product changes its tax handling because the law changed, that is the vendor’s problem. When your custom system needs the same change, it is yours — forever, and at your cost.

We say this on a page that exists to sell custom software because the alternative is selling builds to people who did not need one, and then watching those builds rot. Selling three businesses and watching them keep running teaches you what an unmaintained system looks like three years on.

The three conditions that justify custom

A build has to clear at least one of these. Two makes it comfortable. None makes it a mistake you pay for over five years.

• 1. The process is how you compete Not "we do it a bit differently" — genuinely the reason customers pick you. If a product forced you into the standard way, you would lose the thing you sell.
• 2. The workarounds cost more than the build Measured, not felt. Hours per week × loaded hourly cost × 52, against a quoted build. Most people have never done this sum and are surprised in both directions.
• 3. Nothing exists for what you do Rare, and rarer than people think. Usually something exists and is unfashionable, or exists overseas and needs local tax handling. Both are cheaper than a build.

The workaround audit: how to measure the real cost

Take one real job. Follow it from enquiry to paid invoice and write down every time a human moves the same information from one place to another. Not what should happen — what does.

Count the re-keying, the copy-pastes, the "I’ll just email it to you", the spreadsheet that exists because the system cannot do a thing. Then price it: hours a week, times what that person costs you loaded, times 52.

That afternoon of counting is worth more than any feature comparison, because it is the only number in the decision that is actually yours. Every vendor can quote you a licence fee. Nobody can tell you what your workarounds cost except you.

Five-year cost, honestly compared

Buying looks cheap in year one and compounds. Per-seat pricing rises, headcount rises, and the two multiply. Building looks expensive in year one and then mostly stops — except it does not stop entirely, and anyone who tells you it does is selling.

The honest comparison has four lines on each side. Buy: licences over five years with realistic seat growth and annual increases, implementation, the cost of changing your process to match the product, and the integration work you will still need. Build: the build, hosting, ongoing maintenance and change requests, and the risk premium for having a smaller pool of people who can work on it.

Run both to five years. If they land close, buy — because the buy path has less variance, and variance is what hurts a small business.

Risk: what goes wrong with each

The failure modes are different in kind, not just in size, and they are worth knowing before you pick.

• Buying fails by constraint The product will not do the one thing you need, so a person does it by hand, forever. Cheap to start, and it never gets better on its own.
• Buying fails by price Per-seat cost rises faster than you grow. You are locked in by the data and the training, and you know it, and so does the vendor.
• Building fails by abandonment The person who built it moves on and nobody picks it up. This is why the code, the repository access and the documentation matter more than the build quality — see <a href="/ownership-and-security">ownership and security</a>.
• Building fails by scope Six weeks becomes six months because nobody agreed what "done" meant. Two-week increments exist to make this visible early rather than late.

The middle path most people miss

Keep the products. Build the joins. This is the answer for most of the businesses we talk to, and it is the cheapest of the three options by a wide margin.

Your accounting package is fine. Your job management system is fine. What is not fine is that they do not talk, so somebody re-types. Building that one connection costs a fraction of replacing either system, and it removes the actual pain.

It is also reversible. If you change job management systems in two years, you rebuild one connector — not a platform. What we build is mostly this, and it is deliberately the cheapest thing on the list — see how we charge for why that is not a loss-leader.

If you want the framework rather than the argument, the build-vs-buy decision framework walks the same ground as a structured hour with a scorecard at the end.