Build vs Buy Decision Tool: Should You Build or Buy Your Next System?
Five numbers settle this argument. Put yours on one axis and see which one is pulling against the other four.
17 days average time to first submittal 92% of those hires still in the seat a year later
Build when the capability is your competitive edge and rests on data only you own. Buy when it’s plumbing anyone can license. The tool below weighs five numbers and shows which one is pulling against the other four.
The framework underneath it belongs to Kris Drouet, who spent twenty-five years writing code in mortgage tech and fintech before he started writing about the decision. His version fits in a sentence. Show me the data. The long version lives in his build vs buy framework for engineering leaders, and what you’re looking at here is the same five numbers wired up so you can actually move them.
We built it because our engineering recruiters keep getting the same call. Eighteen months into a homegrown system, the one person who understood it has left, and a technical decision has quietly turned into a hiring emergency. By that point the fix costs more than the build did. Every time.
Five numbers. One axis. No email gate.
Answer each one honestly, including the one you’d rather skip. Every answer drops a mark on the axis below, and the needle is the weighted verdict. When the marks scatter, the tool tells you which number to go argue about first. That’s the useful part.
Not version one. Version one plus maintenance plus the loaded cost of whoever keeps it breathing, against the vendor’s three-year total.
How long until this is live and moving a number somebody in finance already watches.
Could a competitor buy the same result tomorrow, with a credit card and a weekend?
Who owns this at 2 a.m. eighteen months from now, after the engineer who wrote it has moved on.
One-way door or two-way door. A call you can walk back is a call you should make fast.
What the model weighs, and where teams fool themselves
The weights are published because a scoring model you can’t inspect is just an opinion with a progress bar. Edge carries the most because it’s the one question a competitor can answer for you. Reversibility carries the least because it changes how much evidence you’re allowed to skip before committing rather than which option is actually right, and that’s a real distinction even though it’s a smaller one than the other four.
| The number | Weight | The question it forces | Where teams fool themselves |
|---|---|---|---|
| 01 Three-year cost | 1.15 | What does this cost once maintenance and headcount are counted? | Pricing version one against a vendor’s three-year total. You’re pricing the wedding and forgetting the marriage. |
| 02 Time to value | 1.00 | How long until this is live and moving a metric? | Treating the wait as free. Every quarter spent building is revenue not earned or a competitor shipping first. |
| 03 Edge or plumbing | 1.30 | Could a competitor buy the same result tomorrow? | Calling it strategic because it feels strategic. Most of it is plumbing, and plumbing is not a failure. |
| 04 Maintenance load | 1.15 | Who owns this at 2 a.m. a year from now? | Answering with a name instead of a plan. One senior person and no backup is not an ownership model. |
| 05 Reversibility | 0.90 | One-way door or two-way door? | Holding three meetings about the reversible call and greenlighting the irreversible one on a hunch. |
Weights are directional, drawn from what our engineering desk sees on searches that follow a build decision. If you disagree with one, that disagreement is more useful than the score. Two related instruments cover neighbouring ground. The engineering velocity assessment looks at whether your team can ship whatever you pick, and the AI readiness scorecard runs the same style of check on an AI decision specifically.
The number everyone skips is the one that takes the building down
A build isn’t a project with a finish line. It’s a hire. Somebody owns that system for as long as it runs, patches it, answers for it when it dies on a holiday weekend, and keeps owning it long after the clever engineer who wrote it has taken the whole mental model somewhere else.
The public data on this is grim. McKinsey surveyed CIOs and found tech debt worth 20 to 40 percent of an entire technology estate, with another 10 to 20 percent of the new-work budget quietly bled off keeping old work alive. Stripe and Harris Poll went at it from the other end and found the average developer spends more than 17 hours of a 41-hour week on maintenance, debugging and refactoring, with the four hours a week lost to bad code alone adding up to roughly $85 billion in opportunity cost worldwide.
Every system you choose to build adds a brick to that wall. Buying doesn’t. What shows up in year two is the compounding version of that number, where a dependency ships a breaking change at the worst possible moment, a library you never thought about goes unmaintained, and the one person holding the whole design in their head takes another job.
- Loaded cost is not salary. Salary is roughly two thirds of it. Benefits, equity, hardware, the seat license for every tool that engineer touches and a slice of their manager’s week make up the rest, and all of it recurs whether anyone reads the line item or not.
- Answer number four with a plan, not a name. If the honest answer is one senior person with no backup, the model will drag your reading toward buy on purpose.
- Retention is the maintenance strategy. A system whose owner leaves in year two costs you the rebuild, not the handover.
One-way door, or a door you can walk back through
Jeff Bezos split decisions into two kinds in his 2015 letter to shareholders. A type one is a one-way door. You walk through, you hate it, there’s no walking back. A type two you can reopen and stroll back out of.
Swapping one analytics tool for another is a two-way door, so quit agonizing and pick one. Rebuilding your ledger in-house is not, because the day real money starts moving through it you are not casually migrating off on a Friday afternoon.
Most teams get this exactly backwards. Three meetings about the reversible call, a hunch on the irreversible one.
That’s why reversibility carries the lightest weight in the model and still earns a slot. It doesn’t change which option is right. It changes how much evidence you’re allowed to skip before you commit, and a team that can’t tell the two doors apart will burn its scarce decision-making energy on the wrong one every single time, which is usually the real story behind a stalled roadmap.
Every reading on that axis is a different hire
This is the part the spreadsheet leaves out. Build, buy, or something in between, each answer commits you to a different bench, a different pay band, and a different scarcity problem. Pick one, then hire for it. Genuinely different searches.
Build it
You’ve committed to a team, not a sprint. Senior people who’ll own a living system for years and won’t bolt at the first recruiter email.
Direct hire staffingProve it first
Ship one real production slice with a senior contractor, measure one number finance already watches, then staff it properly.
Contract staffingBuy, then build on top
A vendor gets you most of the way and your layer is the rest. That layer needs a small senior team that owns it outright.
Platform engineering staffingBuy it
Buying isn’t outsourcing the thinking. You still need someone who can tell a good vendor from a confident one.
Software engineer staffing
The reading is free. The bench is not.
Run this thing nine times and change your mind twice. Costs you nothing. The constraint shows up the moment you try to hire the people who make the answer real, and in a market where a good senior engineer fields three recruiter emails before lunch, that’s where most of the schedule quietly goes.
The pattern we watch play out is consistent enough to be boring. A team makes a defensible call, then staffs the work with whoever happened to be free, and a technically sound decision still lands eleven months late. Both of the blog posts behind this tool land in the same place from different angles, whether the thing on the table is a notification service or an AI pilot that dies before production. It’s rarely the code. It’s usually a clarity problem wearing a technical costume.
We’ve been placing IT and engineering talent since 2005, on contract, contract-to-hire, and direct hire. The Bureau of Labor Statistics still projects computer and IT occupations growing faster than the average job through 2034, and the supply of engineers who’ll own a system for five years has never kept up with the number of systems teams decide to build. If the project has a date on it, staffing is the line item that decides whether you hit it.
Common Questions
How does a build vs buy decision tool actually decide?
This one weighs five inputs on a single build-to-buy axis: three-year cost, time to value, whether the capability is your edge or plumbing, who maintains it, and how reversible the call is. The needle is the weighted result.
What matters more than the needle is the scatter. Five marks bunched together mean your team already agrees and just hadn’t said so out loud. Five marks flung across the axis mean somebody is about to lose an argument they haven’t had yet, and the tool names which number to start with.
Should we build or buy software?
Buy the plumbing, build the edge. If a competitor could buy the same result tomorrow with a credit card, it’s plumbing and your best engineers shouldn’t be near it. Build only what rests on data or a workflow nobody outside your company has.
The login box is plumbing. So is sending a text, charging a card, and shipping logs to a dashboard. Fraud scoring on data you spent a decade accumulating is not. Teams that get this backwards pour a year into a slightly worse version of something they could have licensed on a Tuesday.
How do you cost a build you haven’t built yet?
Start with the engineering estimate, then add the parts nobody enjoys saying out loud. Take the loaded cost of everyone who’ll maintain it, multiply by three years, and add the buy side’s integration and switching costs so you’re comparing the same thing.
You will not be precise. You’ll be honest, and on this question honest is worth considerably more than precise. If the two totals land within about 15 percent of each other, treat it as a tie and let numbers three and four break it.
Is choosing buy an admission that our team can’t build it?
No, and that framing is how good teams end up building payment stacks. Senior engineers are scarce and expensive. Aiming them at something every other company already rents is the actual waste.
The smallest teams we work with buy nearly everything and build the one thing a customer picks them for. That focus is the whole advantage. They guard it.
What does a spread of 60 or more points mean?
It means your five numbers disagree sharply, which usually points at one input everybody in the room has been quietly assuming rather than checking. The tool names the outlier so you know where the conversation starts.
Wide spreads are common on AI decisions specifically, where the edge case is compelling and the maintenance answer is a shrug. Sixty points of disagreement is not a broken model. It’s a meeting you owe yourself before the contract gets signed.
What is the fastest way to de-risk a build before committing headcount?
Ship one production slice, not a demo. Take the smallest real workflow, put it in front of actual users, and measure exactly one business number. Bring in a senior contractor to do it if your team is already committed.
Three weeks in production with real users hitting real edge cases will teach you more than three months of a pilot that never leaves staging. If it works, staff it as a direct hire and keep the person who built it. If it doesn’t, you spent weeks instead of quarters finding out.
Does KORE1 sell or implement any of the systems this tool compares?
No. KORE1 is a staffing firm, not a reseller, VAR, or implementation partner for anyone. Nobody here earns a commission based on which way your reading lands.
That’s the reason the tool exists in this form. Most build vs buy content is published by a vendor who sells one of the two answers, and it tends to show up in the conclusion.
You have a reading. Now find out whether you can staff it.
Thirty minutes with a KORE1 engineering recruiter tells you what the bench looks like in your market, what it pays, and how long the search really takes. No pitch, no deck.
Talk to an Engineering Recruiter →