Build vs Buy: A Framework for Internal Tools
Executive TL;DR
- Both sides of the usual comparison are wrong. Building costs the build plus maintenance every year after plus the product work that engineer did not do. Buying costs the licence plus integration, seat growth and conforming your process to someone else's model.
- Decide on one question: is this workflow something you do differently from your competitors, or is it a commodity everyone does the same way? Commodity work gets bought or assembled. Build only where the way you do it is part of why customers choose you.
- Make the decision reversible instead of perfect. Keep the data in a system you own and treat the tool as an interface over it — then a bad choice costs a migration of screens, not a migration of history.
Operations requests for a tool. SaaS option: somebody puts a price of a few hundred a month, the engineer says 3 weeks, and the meeting becomes arithmetic, 12 months of license versus 3 weeks of salary. The team builds because it looks cheaper to build.
That comparison ignores the entire cost of ownership for software. Week three purchases version one. What comes after is boundless: the edge case no one defined, the dependency upgrade, the permission model someone needs when the team gets bigger, the export for the auditor, and the bug report at 6pm on a Friday by the person who cannot invoice without it. A good planning heuristic is to set aside 15-25% of the original build cost annually just to keep an internal tool running—and that’s before anyone asks for a feature.
The bigger omission is the one that no one bills for. The engineer building the internal approvals tool is not building the product that customers pay for. The early-stage company is generally the most expensive line in the decision and never shows up on the slide.
The buy side gets misunderstood too. The license is rarely the real cost. Integration is, along with per-seat pricing that grows with headcount rather than value, the data you cannot get out cleanly, and the quiet reshaping of your process to match the vendor's assumptions. That last one matters most when the workflow is genuinely yours.
Buy, assemble, build, or keep it manual — which is right for this internal workflow?
| Buy a SaaS tool | Assemble | Build custom | Keep it manual | |
|---|---|---|---|---|
| Upfront cost | Subscription, plus an integration project nobody budgeted | Low — configuration and some glue code | Highest — and the estimate is usually the optimistic one | None |
| Three-year cost | Predictable until seats or usage grow, then it compounds | Moderate; per-seat tool pricing plus occasional rework | Build cost plus roughly 15–25% a year in maintenance (planning heuristic), plus the features nobody has asked for yet | Grows with volume — it is paid in salaried hours, which is why it stays invisible |
| Time to value | Days to weeks | Days | Weeks to months | Immediate |
| Who maintains it | The vendor | Whoever configured it, usually one ops person | You, permanently, including on-call | The people doing the work |
| Fit to your workflow | You adapt to their model; usually fine, occasionally fatal | Good — most of the shape is yours | Exact, which is the only real argument for building | Perfect and unscalable |
| Data ownership and lock-in | Varies — check export and API access before signing, not after | Moderate; your data is usually retrievable | Total ownership | Total, and usually in one spreadsheet one person understands |
| Fails when | The workflow is your differentiator, or seat pricing outgrows the value | Volume, compliance or complexity outgrow the platform's limits | The thing you built is a commodity everyone else rents | The manual step blocks a customer, or the person who does it leaves |
When to pick each option
Purchase when the workflow becomes a commodity. Payroll expense approval. Applicant tracking. Helpdesk ticketing. Accounting. Thousands of companies do it the same way. A vendor already solved the edge cases you have'n't even been aware of yet. The engineering you’d spend reproducing is engineering not spent on your product. There are three things that are costly to find out later, so you should verify them before signing: how data exports, what the API allows, and how the price behaves at three times your current headcount.
Configure when the workflow is special but not specific. This is where the bulk of the internal tools belong and where teams rarely get to. A shared database or low-code platform, a workflow automation layer, a dashboard over your warehouse, and a little glue code will serve an internal process for years, and the people who understand the process can change it without filing a ticket. Know your ceiling, and accept it honestly. Platform limits on records, rate limits, permission models, and audit requirements are the things that eventually force a rebuild, so know where yours are before you depend on them.
Build when the way you do business is part of why customers choose you. A pricing engine encoding your commercial model, a matching algorithm, an underwriting workflow, and an internal console that lets your support team do something competitors cannot. The test is blunt: if every vendor gave you their tool for free, would you make your own? If the answer is no, you’re building a commodity. Build even when a hard constraint makes buying impossible—data residency, a regulated environment, an integration no vendor supports
Keep it manual on purpose while the volume is low and the process is still morphingdelay—so. Automating a workflow that changes monthly means rewriting the automation monthly. Write down the trigger that ends it—hours per week, error rate, or a customer-facing delay — so the decision gets made on evidence rather than when someone finally loses patience.
Rendering diagram…
// Fill in your own numbers. The point is that two lines usually decide it, and
// neither appears in the meeting: maintenance, and the product work displaced.
const inputs = {
// Build side
buildWeeks: 3,
engineerWeeklyCost: 2500, // fully loaded, not salary / 52
maintenanceRate: 0.20, // per YEAR, share of build cost — planning heuristic
opportunityFactor: 1.0, // 1.0 = an engineer-week on internal tools is an
// engineer-week not spent on the product. Set to 0
// only if you genuinely have idle capacity.
// Buy side
monthlyPerSeat: 15,
seatsToday: 12,
seatGrowthPerYear: 1.5, // headcount multiplier — the line that surprises people
integrationWeeks: 1, // nobody budgets this and everybody pays it
years: 3,
};
function compare(i) {
const buildOnce = i.buildWeeks * i.engineerWeeklyCost;
const displaced = buildOnce * i.opportunityFactor; // the invisible cost
const maintenance = buildOnce * i.maintenanceRate * i.years;
const build = buildOnce + displaced + maintenance;
let seats = i.seatsToday;
let licence = 0;
for (let y = 0; y < i.years; y++) {
licence += seats * i.monthlyPerSeat * 12;
seats = Math.round(seats * i.seatGrowthPerYear); // compounding, like headcount
}
const buy = licence + i.integrationWeeks * i.engineerWeeklyCost;
return {
build: Math.round(build),
buy: Math.round(buy),
seatsAtEnd: seats,
// If these land within ~30% of each other, cost is not the deciding factor.
// Decide on the differentiator question instead and stop arguing about money.
verdict: Math.abs(build - buy) / Math.max(build, buy) < 0.3
? 'too close to call on cost — decide on strategy'
: build < buy ? 'build is cheaper over 3 years' : 'buy is cheaper over 3 years',
};
}
console.log(compare(inputs));
// Run it twice: once with opportunityFactor at 1.0, once at 0. The gap between
// those two answers is the real argument your team is having.MVP development planner
Scope, budget, and launch plan
Choose the product, platforms, and modules. The range, phases, and team update as you go. It is a planning figure, not a quote.
Newsletter
One architecture teardown or evaluation, every other week
Practical writeups about framework choices, migrations, scaling decisions written for people who have to defend the call in a meeting.
Newsletter
Get the 2026 Tech Stack Guide
Join the KarmaKoders newsletter for architecture notes, stack evaluations, and build playbooks.