Answer seven weighted questions about capacity, timeline, differentiation, product fit, budget shape, maintenance ownership and operational risk. The tool scores all three options and shows you the margin between them, plus the two questions that moved your result most. All weights are published on this page.
This is a weighted additive scoring model. Each of seven questions carries a published weight, each answer contributes published points to the three options, and the totals are normalised to 100. It structures a judgement; it does not make one, and it knows nothing about your organisation beyond the seven answers.
It is not cost, although cost is what gets argued about. It is which parts of your operation you want to be responsible for forever. Every option creates an obligation. Building creates an engineering obligation that outlives the engineer who built it. Buying creates a dependency on a vendor's roadmap, pricing and continued existence. Hiring an agency creates a handover problem, and the quality of the handover determines whether you have bought an asset or a liability. The useful reframe is to ask what you want to still be true in three years. If the answer is that this capability should be a source of advantage that competitors cannot copy, you are building. If the answer is that you want to never think about it again, you are buying. If the answer is that you need it to exist well before you can staff it, you are hiring an agency and writing knowledge transfer into the contract.
Because it is the only factor in this decision that is still true in five years, and because getting it backwards is the most expensive version of this mistake. Building undifferentiated infrastructure is the classic expensive error. Every hour spent building your own version of something a hundred vendors already sell is an hour not spent on the thing customers actually choose you for, and the maintenance obligation persists long after the novelty of having built it wears off. The inverse error is quieter and more damaging. Buying the thing that is genuinely your advantage means your advantage is now available to every competitor with a credit card, and it means the ceiling on how good it can get is set by a vendor's roadmap rather than by you. The uncomfortable part is that most organisations overestimate their differentiation. A good test: could a competitor buy the same product tomorrow and be at parity? If yes, it is not differentiation, it is preference.
More than the build, and the gap is systematic rather than occasional. The build itself is the visible part and usually the smaller part. Around it sits specification, testing, security review, documentation, onboarding the second engineer, and the opportunity cost of whatever those people were going to do instead. Opportunity cost is the largest line and the one that never appears in a business case. Then there is the eighteenth month, which is where in-house builds go to die. The engineer who built it has moved on or moved teams. The framework it was built on has had two major versions. The person who understood why a particular decision was made is not available to explain it. The tool still works, nobody wants to touch it, and it slowly becomes a constraint rather than a capability. None of that is an argument against building. It is an argument for only building the things worth carrying, which brings you back to the differentiation question.
Buying is usually the right answer and it has three failure modes worth naming before you pick it. The first is fit drift. A product that fits perfectly today is fitting a snapshot of your process, and processes change. The question is not whether the product fits now, it is whether the vendor's direction of travel resembles yours. The second is pricing exposure. Per-seat and usage-based pricing that is trivial at your current scale can become a significant line item at three times the scale, and the leverage in that negotiation runs entirely one way once you are embedded. The third is data gravity. Whether you can leave, and what you take with you, is a question to answer before you sign rather than during the argument. Export formats, API completeness and historical data access are all things vendors are happy to discuss during a sales process and reluctant to discuss afterwards.
When you need the capability to exist before you can realistically staff it, and when the work is bounded enough to specify. Agencies win on time to first working version and on avoiding a hiring commitment for something you are not yet certain about. That combination is genuinely valuable and it is under-rated by engineering leaders who assume outsourcing is always a compromise. The failure mode is the handover, and it is entirely preventable by contract. Specify that repositories, infrastructure accounts and documentation live in your accounts from day one rather than at the end. Specify a knowledge-transfer phase with a named internal recipient. Specify what happens to the code if you stop paying. An agency engagement without those clauses produces a system nobody inside your company can change, which is the most expensive possible outcome of a decision that was meant to save time. The strongest pattern is often hybrid, and this tool will report it as a close margin: buy the platform, pay an agency to integrate it, and staff the ongoing operation internally once the shape of the work is clear.
Whether the capability differentiates you. It carries the highest weight in this model at 1.6, because owning what makes you different and buying what does not is the one principle that holds across industries and survives changes in cost.
Rarely, once you count specification, testing, documentation, the opportunity cost of the engineers and the maintenance obligation in year two. It is frequently better, which is a different claim, and only for things worth carrying.
When you need the capability before you can staff it, and the work is bounded enough to specify. Write ownership of repositories and infrastructure, plus a knowledge-transfer phase with a named internal recipient, into the contract from day one.
Treat a margin under 8 points as a tie. Look at the two decisive questions the tool surfaces, get a better answer to those, and consider making a smaller, reversible decision first rather than a permanent one.