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.
A framework, not a sales tool
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
20 minutes. We find where the money's going. No pitch.
Book a free Leak Check