Build vs Buy: A Decision Framework for Internal Tools

Almost every build-vs-buy article is published by a company selling one of the two answers. Vendors argue for buying. Development agencies argue for building. Low-code platforms argue for a third thing that happens to be their product.

The honest version is that the decision is usually not close once you ask the right question - and the right question is not “can we build this?” It is “what happens to us if this is mediocre for three years?”

Start with the 80% rule

The practical test: if a mature off-the-shelf product covers roughly 80% of your requirements without heavy workarounds, buying is almost always correct.

The decision then turns entirely on what the missing 20% costs you. Not what it costs in theory - what it costs per week, in real terms.

Missing 20% that means someone exports to a spreadsheet on Fridays is an annoyance. Missing 20% that causes revenue leakage, compliance exposure or a customer-visible failure is a different category of problem, and can justify a build on its own.

Be honest about which one you have. Most teams describe the first and budget for the second.

When building is genuinely right

Four situations justify a custom build. Retool and Zylo frame these similarly, which is notable given both sell products that argue against building.

It is how you compete. Not important - differentiating. If a competitor could buy the same capability off the shelf and be at parity with you, it is not differentiation. A logistics company’s routing algorithm might be. Its expense approval flow is not.

Nothing mature fits. Genuinely new categories, or requirements so specific that every product would need heavy modification. Rarer than most teams believe, but real.

Integration cost exceeds build cost. Sometimes the product exists but connecting it to your systems is harder than building the thing. This is common in organisations with substantial legacy infrastructure.

You need control of the roadmap. If a capability must evolve on your schedule and no vendor will commit to it, you are choosing between building and waiting.

The costs each side hides

Building hides ongoing cost. The build price is the smallest part. Budget 15-25% annually, forever - dependency updates, security patching, browser changes, small feature requests. Add the opportunity cost of engineers not working on the product, and key-person risk when the one person who understands the system leaves. Custom builds also carry a documentation burden that internal tools almost never get.

Buying hides scaling and exit cost. Per-seat pricing that is trivial at 20 users and painful at 400. Integration work that gets treated as free because it is not on the invoice. Vendor roadmap risk - the feature you need may never ship. And migration cost, which grows every month you use the product and is the real reason switching rarely happens.

Neither column is a trick. They are simply the parts that do not appear in the comparison spreadsheet, which is why the spreadsheet usually favours whichever option the person building it already preferred.

The third option most teams skip

The framing is rarely binary. In practice there are three paths: build custom, buy off-the-shelf, or buy a platform and extend it.

Platform-plus-extension covers a large share of internal tooling well. You get authentication, permissions, audit logging, hosting and the boring 70% for free, then build the specific logic that is actually yours on top. It is meaningfully cheaper than building, and meaningfully more flexible than buying.

The trade-off is real lock-in: you are betting on the platform’s pricing and continued existence. That is an acceptable bet for internal tools and a poor one for anything customer-facing that is core to your business.

Where AI has actually changed the maths

This is worth being precise about, because the claims are running well ahead of the evidence.

AI-assisted development has genuinely compressed one category: simple, well-understood, low-risk internal software. Admin dashboards, CRUD interfaces, integration glue, one-off migration scripts. Work that used to take a quarter can ship in days. For that category, the build/buy line has moved, and buying a product to solve a problem you can now generate in an afternoon is often the wrong call.

It has changed far less for anything requiring security review, compliance evidence, complex domain logic or years of maintenance. Generation speed was never the constraint there - correctness, review and accountability were, and those still cost what they cost. There is also emerging evidence that AI-generated code carries elevated vulnerability rates, which matters most in exactly the systems where you cannot afford to be wrong.

We went deeper on this in what AI actually changed about building software, including which of these claims hold up in production.

Running the numbers properly

Most build-vs-buy spreadsheets compare a build quote against an annual subscription, which is not a comparison. Use a five-year total cost of ownership on both sides.

Buying, five years: subscription at your projected user count (not today’s), integration and setup, internal admin time, and an allowance for price increases. Vendors raise prices; assume they will.

Building, five years: build cost, then 15-25% annually for maintenance, plus hosting and third-party services, plus the internal time to support users, plus a replacement or major refactor somewhere around year four.

Two things usually surprise people when this is done honestly.

The first is that buying looks worse than expected at scale, because per-seat pricing compounds. A tool at $30 per user per month is $7,200 a year at 20 users and $144,000 at 400.

The second is that building looks worse than expected at small scale, because maintenance does not shrink with user count. A tool with 15 users costs almost as much to maintain as one with 500.

That crossover is the actual decision, and it moves with headcount growth. A build that is wrong at today’s size may be right in two years - which argues for buying now with an exit plan rather than building early on a projection.

Where build decisions go wrong

Four failure modes account for most of the regret.

Nobody owned it after launch. The build was a project with a budget and an end date, and no ongoing owner. Within eighteen months it is out of date, undocumented, and the person who wrote it has moved teams. This is the single most common outcome of internally-championed builds.

The 20% grew. The requirement that justified building turned out to be one of five, and each new one extended scope. Buying was rejected on an 80% fit; the build shipped at 60% of a much larger scope.

It was scoped against today. Built for the current process, then the process changed. Bought products absorb this through vendor roadmaps; custom builds absorb it through your budget.

The champion left. Internal tools frequently depend on one enthusiast. When they leave, the tool becomes an orphan that everyone uses and nobody maintains - the worst possible position, because it is now load-bearing.

None of these are technical failures. They are ownership failures, which is why the maintenance question in the sequence below is the one that matters most.

A decision sequence

Work through these in order. Stop at the first clear answer.

1. Is this differentiating, or merely important? If merely important, default to buying.
2. Does a mature product cover ~80% cleanly? If yes, buy - unless step 3 overrides.
3. What does the missing 20% cost per month, in money or risk? Quantify it. If it is small, buy and move on.
4. Can a platform cover the boring 70%? If yes, this is usually the best value.
5. If still building - can you fund 20% of build cost annually, indefinitely? If not, you cannot afford to build. Buy something.

Step 5 is where most build decisions should die and usually do not. Organisations approve capital for a build and then fund no maintenance, which produces the worst outcome available: a custom system that is nobody’s job.

Buying well is a skill too

Choosing to buy is not the end of the decision. Most of the value is won or lost in how you buy.

Pilot with real work, not a demo. Vendor demos are optimised environments with clean data. Run a genuine workflow with your actual data for two weeks. The gap between demo and reality is where post-purchase regret lives.

Negotiate the exit before you sign. What happens to your data if you leave? In what format, at what cost, on what notice? A vendor confident in their product will answer plainly. One who deflects has told you something about the next renewal.

Price the growth case. Get pricing at your projected headcount, not today’s, and get the increase mechanism in writing. Per-seat tools that are trivial at 20 users are budget items at 400.

Assign an owner. Bought tools rot in the same way built ones do - unmaintained configuration, stale integrations, permissions nobody has reviewed in two years. Someone needs to own it.

Check the integration story honestly. “We have an API” covers everything from an excellent documented REST API to an undocumented endpoint that returns XML. Have an engineer look before you commit, because integration effort is the cost most consistently underestimated on the buy side.

Done well, buying gets you 80% of the outcome for a fraction of the cost and none of the maintenance. Done badly, it gets you an expensive subscription to something nobody uses, which is the same failure as an unmaintained internal tool with a worse renewal cycle.

If you do decide to build

Scope it against real numbers rather than optimism. What custom builds actually cost covers the tiers and what drives them, and if you are early-stage, scoping to a fixed timeline beats scoping to a feature list every time.

One final test, and it is the most useful one: would you still build this if it took twice as long and cost twice as much? Because for in-house builds without a dedicated team, that is the base rate, not the worst case.

The question behind the question

When a team is arguing about build versus buy, the disagreement is usually not about software. It is about control, and about who is accountable when the thing does not work.

Engineering often prefers building because owning the system means owning the outcome, and because integrating with someone else’s constraints is genuinely frustrating. Finance prefers buying because a subscription is a predictable line item and a build is an open-ended commitment. Operations prefers whichever option gets them working sooner.

None of those positions is wrong, and none of them is really about the 80% rule.

Naming that explicitly tends to shorten the argument considerably. Once everyone agrees the real question is “who owns this in three years and what happens if they leave,” the technical comparison becomes much easier - because most of the time, nobody wants to answer that question, which is itself the answer.