- Price comparison answers "which is cheaper this year," not "which is right." It is the last question, not the first.
- Four questions decide most cases: how differentiating the capability is, how well an existing product fits, what it truly costs to own, and how you would leave.
- Most teams miss the hybrid: buy the commodity, build only the part that makes you different, and integrate the two deliberately.
- Score the decision in writing. A one-page record is what makes it defensible eighteen months later.
- Get an outside opinion when the people deciding are also the people who would build it.
Why cost is the wrong first question
A build-vs-buy decision usually surfaces as a line item. Someone needs a billing system, a customer portal, a scheduling engine, an analytics layer. A vendor quote arrives. An engineer says "we could build that in a month." A spreadsheet appears.
The spreadsheet is seductive because it produces a number, and numbers feel like decisions. But it compares two things that are not the same shape. A subscription is a recurring, predictable, mostly fixed cost for a capability that already exists. A build is an upfront investment plus an open-ended maintenance commitment for a capability that does not exist yet and might not turn out the way the estimate assumed.
Comparing them on cost alone hides the three things that actually determine whether you will regret the choice: whether this capability is central to what makes your business win, whether the thing you would buy actually fits, and what it will cost to change your mind later.
Put the spreadsheet down. Ask these four questions first.
The four questions that actually decide it
1. How differentiating is this capability?
Some things your product does are the reason customers choose you. Most things it does are table stakes: login, billing, email delivery, file storage, dashboards. Customers do not pick you because your password reset flow is elegant.
Build what differentiates you. Buy what does not. This is the single most reliable heuristic in the whole decision, and it is the one teams most often invert. Engineers gravitate toward building the interesting infrastructure and buying the boring product logic, when it should be the other way around.
A useful test: if a competitor had exactly this capability, implemented exactly as well, would it change your position in the market? If the honest answer is no, you are looking at a commodity. Buy it.
2. How well does an existing product actually fit?
"There's a SaaS for that" is true for almost everything and useful for almost nothing until you check the fit. Fit has three parts.
Functional fit. Does it do what you need, or eighty percent of what you need with the remaining twenty percent being the part you actually care about? The last twenty percent is where most buy decisions go wrong. A product that does eighty percent, with no way to close the gap, is often worse than one that does sixty percent with a good API.
Workflow fit. Does it match how your team works, or will your team have to bend to it? Some bending is fine and even healthy. A product that forces you to restructure a core process to accommodate its model is a product you will fight every day.
Technical fit. Does it integrate cleanly with what you already have? Does it have a real API, webhooks, an export path, a data model you can reason about? A product with a beautiful interface and no API is a dead end the moment you need it to talk to anything else.
3. What does it really cost to own?
Now the spreadsheet, but an honest one. Both columns are longer than people think.
The cost of buying is the subscription plus integration work plus the ongoing tax of working around the product's limitations plus the price increases you cannot control plus the seat-count creep that happens when the vendor charges per user. Most bought tools cost two to three times their list price in total.
The cost of building is the initial build plus the maintenance, which for a system in active use runs at roughly fifteen to twenty-five percent of the build cost every year, indefinitely. Plus security patching. Plus the on-call burden. Plus the opportunity cost: every engineer maintaining your homegrown scheduling engine is an engineer not building the thing customers pay for. Plus the risk that the estimate was wrong, which it usually is, and usually in one direction.
The number that matters is total cost of ownership over three to five years, not year one. Run it over that window and the answer often flips.
4. How would you leave?
Every decision has an exit, and the exit is where the real risk lives.
If you buy: can you get your data out in a usable format? Is the vendor likely to exist in five years? What happens to your business if they double the price or get acquired by a competitor? Is there a second vendor you could move to, or is this a one-of-a-kind product with no substitute?
If you build: who maintains it when the engineer who built it leaves? Is it documented well enough that a new hire could take it over? If it turns out to be a mistake, can you replace it with a product later, or has it become so entangled with everything else that removing it is a rewrite?
A decision that is easy to reverse is a low-stakes decision, even if it is expensive. A decision that is hard to reverse deserves more care, even if it looks cheap. Most build-vs-buy analysis ignores this entirely.
The scoring table
Put the four questions into a table and score them. This is deliberately simple. The value is not in the arithmetic; it is in forcing the conversation to cover all four dimensions instead of the one that happens to be loudest in the room.
| Criterion | Weight | Favors build when | Favors buy when |
|---|---|---|---|
| Differentiation | 35% | This is why customers choose you | It is table stakes; nobody will notice |
| Product fit | 25% | Every candidate misses the part you care about | A product covers the need with an API to close gaps |
| 5-year cost of ownership | 25% | Buying scales badly with users or volume | Building carries a maintenance tax you cannot staff |
| Reversibility | 15% | Vendor lock-in would be severe; no substitute exists | The build would entangle with everything; migration later is a rewrite |
Score each row from one to five in the direction of build, weight it, and sum. A score near the middle is not a tie; it is a signal that the hybrid below is probably the right answer.
The hybrid most teams miss
Build-vs-buy is framed as binary, and it almost never is. The strongest answer for most capabilities is: buy the commodity core, build the thin layer that makes it yours, and integrate the two deliberately.
Consider a customer portal. The authentication, the account management, the notification delivery, the file storage: commodity. Buy those as services. The specific workflow your customers go through, the piece of the experience that reflects how your business is different: build that, on top of the bought parts.
This is not a compromise. It is usually the design that would have won on all four questions if the question had been asked correctly. The build effort shrinks to the part that matters, the maintenance burden shrinks with it, and the bought components can be swapped later because you never let them own the differentiating logic.
The hybrid does require one discipline: keep the boundary clean. The bought product should sit behind an interface you control, so that replacing it later is a bounded piece of work rather than an archaeology project.
The mistakes we see most often
Building because "it's just a CRUD app." It is a CRUD app for the first two weeks. Then it needs permissions, audit logs, exports, an admin view, rate limiting, and a way to handle the case where two people edit the same record. Every "simple" internal tool grows the same set of features, and every one of them is already built into the products you decided not to buy.
Buying because "it's just a subscription." The subscription is the smallest part of the cost. The integration, the workarounds, and the process contortions are where the real spend goes, and none of them appear on the invoice.
Letting the builders decide. The engineers who would build it are the least neutral people in the room. Not because they are wrong, but because building is more interesting than integrating, and interest is not a criterion. Have the decision made or at least reviewed by someone who does not have to do either.
Deciding once and never revisiting. A buy decision that was right at ten customers may be wrong at ten thousand. A build decision that was right when there was no product in the market may be wrong now that there are five. Put a date on every decision to reconsider it.
Ignoring the exit. Covered above, and worth repeating: the cost of being wrong is determined by how hard it is to change course, and almost nobody prices that in.
How to run the decision in a week
You do not need a month. You need a structured week.
Day one. Write down, in one paragraph, what the capability needs to do. Not features: outcomes. If you cannot write it in a paragraph, you are not ready to decide.
Day two. Shortlist three candidate products. Get actual demos or trials, not the marketing page. Check the API documentation before you check the pricing page.
Day three. Have an engineer who did not propose building it write a one-page estimate of what a build would take, including the first year of maintenance. Have a second engineer challenge it.
Day four. Fill in the scoring table. Do it as a group, argue about the scores, and write down why each score is what it is.
Day five. Decide. Write a one-page record: what you chose, what you rejected, why, and the date you will revisit it. That page is the most valuable artifact of the whole exercise. Eighteen months from now, when someone asks why the company is paying for this or maintaining that, the answer will be in writing instead of in the memory of someone who has since left.
When to bring in an outside opinion
Most build-vs-buy decisions can be made in-house with the framework above. Three situations justify an independent view.
The first is when the decision is large and hard to reverse: a core platform, a system of record, anything the rest of the architecture will depend on for years.
The second is when the people deciding are also the people who would build it, or the people who chose the current vendor. Neutrality is hard to manufacture from inside.
The third is when you have run the exercise and the score landed in the middle. That usually means the real answer is a hybrid, and designing a good hybrid is architecture work rather than procurement work.
That last one is what our build-vs-buy analysis and technology selection engagements are for: we do not sell a platform, a framework, or an engineering team to build it, so the recommendation is only ever about the decision. If you have one of these on the table, talk it through with us before the spreadsheet decides for you.
