A fork in a service road at an industrial park seen from the driver’s seat, both directions equally plausible, no signage.

A framework, not a sales tool

Build vs buy, settled in about an hour.

Buy unless one of three conditions holds: the process is your competitive advantage, the workarounds cost more than a build, or no product exists for what you do. Most businesses meet none of them. This framework takes about an hour to work through.

The three conditions

One condition makes a build arguable. Two makes it comfortable. None makes it an expensive way to solve a process problem.

They are deliberately hard to clear. That is the point of a framework — if it approves everything, it is not deciding anything.

  • Competitive advantage The process is a reason customers choose you, and standardising it would cost you that reason.
  • Workarounds exceed the build Measured annual cost of the manual work is larger than a quoted build plus its five-year running cost.
  • Nothing exists Genuinely nothing — including unfashionable products and overseas products with a local tax layer bolted on.

Working through it: the hour-long version

Block an hour with whoever actually knows the process, not whoever owns the budget. Those are frequently different people and the second one has a tidier and less accurate picture.

Twenty minutes mapping the real path of one job. Twenty minutes counting and costing the manual steps. Twenty minutes testing the three conditions honestly against what you just wrote down. You will know by the end.

Nine questions. Answer them about one specific process, not the business in general — the answer differs per process, which is why "should we build" is usually the wrong shape of question.

  1. Is this process a reason customers choose you?Not "we do it well" — would standardising it lose you work?
  2. Have you counted the manual steps on one real job, start to finish?
  3. Do you know what an hour of the person doing them costs you, loaded?
  4. Does a spreadsheet exist beside your software because the software cannot do a thing?
  5. Have you evaluated at least three products, including one you had not heard of?
  6. Is the process stable — same steps this month as six months ago?An unstable process should not be automated at all yet.
  7. Is there one person who can decide and sign?
  8. Could you describe "done" in a sentence someone else would agree with?
  9. If the person who built it left, could you hand it to someone else?

0 of 9 answered. The result appears once you have answered them all.

This runs entirely in your browser — nothing is sent anywhere, and there is no form at the end. If it says buy, that is a real answer and you can stop here.

Costing the workarounds properly

Most people undercount by a factor of two or three, because they count the obvious re-keying and miss the chasing, the checking and the fixing.

Count four things: moving information between systems, chasing information that has not arrived, checking that something was done, and correcting it when it was not. The last two are usually larger than the first, and are the ones nobody thinks of as a software cost.

A stack of worn job dockets and forms on a scratched surface, edges frayed from handling.
The chasing and the checking cost more than the typing. Count all four.

Five-year total cost, both paths

Buy: licences with realistic seat growth and annual increases, implementation, the cost of changing your process to fit, and the integration work you will still need afterwards.

Build: the build itself, hosting, maintenance and change requests, and a risk premium for the smaller pool of people who can work on it later.

If the two land within about twenty per cent of each other, buy. Variance hurts a small business more than an average, and the buy path has less of it.

Risk on each side

Buying risks constraint and price: the product will not do the thing, or its cost rises faster than you do. Both are slow and survivable.

Building risks abandonment and scope: nobody maintains it, or nobody agreed what finished meant. Abandonment is the one that actually kills systems, which is why code access and documentation matter more than they sound.

The hybrid most people miss

Buy the products, build the connections. Cheapest of the three paths, reversible, and it targets the thing that is actually costing you — which is almost always the joins rather than the systems. It is most of what we build.

It also fails gracefully. Swap a product in two years and you rebuild one connector, not a platform.

What the answer usually is

Buy, then automate the joins. That is the honest distribution, and it is what the framework returns for most of the businesses that run it. The longer argument is on custom vs off-the-shelf.

If yours comes back the other way, the Leak Check is twenty minutes and free, and it will either confirm it or tell you it was the joins after all.

Objections

What if we’re borderline?

Buy. Borderline means the case for building is not strong enough to carry five years of maintenance, and the buy path has less variance. Revisit in a year with better numbers — the decision keeps.

Doesn’t buying lock us in?

Yes, somewhat — by your data and your team’s habits more than by any contract. Building locks you in too, to a much smaller pool of people who can maintain it. Pick which lock-in you would rather have, with your eyes open.

Book a free Leak Check

20 minutes. We find where the money's going. No pitch.

Book a free Leak Check