Build vs. Buy: The Point Where Off-the-Shelf Software Starts Costing You More

A decision framework with actual numbers: license creep, workaround hours, and integration debt — the breakeven point where building your own system wins, and the cases where off-the-shelf genuinely doesn't lose.

Every off-the-shelf tool looks cheap on the invoice. A per-seat license, a monthly bill, a logo you recognize. What the invoice never shows is the second cost curve: the hours your team spends bending the tool to fit a process it was never built for, and the integrations you keep patching because the vendor's API stops where your workflow gets interesting.

Build vs. buy is not a philosophy question. It is arithmetic. The problem is that most teams only count one side of the ledger — the sticker price — and never measure the drift. Here is how to put real numbers on both sides, and how to spot the point where the tool you bought quietly became the more expensive option.

Where the money actually leaks

Sticker price is the honest part of buying. It is predictable and it shows up in your accounting. The damage happens in three places nobody budgets for: seats that multiply as headcount grows, tiers that unlock a feature you already assumed you had, and the manual work people do to route around a rigid tool.

A team of 20 on a $40/seat SaaS pays $9,600 a year. At 60 people two years later, with a mandatory upgrade to the tier that has SSO and audit logs, that same tool is $120–180/seat and closer to $100k a year. Nothing about your usage changed. The pricing did. This is license creep, and it compounds silently because each individual renewal looks reasonable.

The three numbers that decide it

You do not need a spreadsheet with forty rows. You need three figures, measured honestly, projected over three years — because software you build and software you rent are both three-to-five-year commitments, not one-year ones.

• License creep: current annual spend multiplied by your realistic growth, plus the tier jumps you already know are coming (SSO, audit, higher API limits).
• Workaround hours: time people spend on manual steps the tool forces — CSV exports, re-keying data, copy-paste between systems. Twenty minutes a day across ten people is roughly 800 hours a year.
• Integration debt: the glue code between the tool and the rest of your stack. Count what you have already written, and what breaks every time the vendor ships a change you did not ask for.

Doing the breakeven math

Put a build estimate next to that three-year total. A focused internal tool that replaces one bought product is typically 2–4 months of a small senior team, plus a maintenance tail of 15–25% of the build cost per year. Call the build $120k and the tail $25k/year: $195k over three years.

Now the bought side: $100k/year in licenses climbing with headcount, plus roughly 800 workaround hours at a loaded $60/hour — another $48k/year in disguised labor. That is over $150k a year and rising. Breakeven lands inside the second year, and everything after is pure divergence. When the numbers are that far apart, the decision is already made; you are just choosing when to act on it.

When buying genuinely wins

Honesty cuts both ways. For most companies, some categories should never be built, and we will tell a client to buy without hesitation. The rule of thumb: buy anything that is a solved commodity, is not your differentiator, and carries compliance risk you do not want to own.

• Payments, tax, and payroll — the regulatory surface is enormous and it changes under you; Stripe and its peers exist for a reason.
• Email delivery, auth providers, error monitoring — mature, cheap, and a distraction to rebuild.
• Anything where the vendor's compliance certifications (SOC 2, PCI, HIPAA) would otherwise become your problem to earn and maintain.
• Early-stage validation: when you do not yet know the workflow, renting one lets you learn it before you spend six figures encoding the wrong version.

The expensive middle: customizing what you bought

The worst position is not build or buy. It is buy-then-heavily-customize. You take a rigid product, wrap it in scripts, bolt on a middleware layer, and hire a consultant certified in that specific platform. Now you carry the license cost and a codebase — except you own the fragile half and the vendor owns the half that breaks your customizations on their release schedule.

This shows up constantly with heavyweight ERP and CRM rollouts, where the customization budget quietly grows past what a purpose-built system would have cost. If you find yourself writing more integration and workaround code than the vendor gives you value, you have already paid to build — you just do not own the result.

Signs you have already crossed the line

You rarely get a clean signal that buying stopped making sense. It arrives as a pattern of small frustrations. Watch for these:

• A person, or a fraction of one, exists mainly to feed and babysit the tool.
• Your differentiating workflow is constrained by the tool's opinion of how it should work.
• Renewal quotes climb faster than your usage of the product.
• You maintain a growing pile of scripts whose only job is to make the tool talk to your other systems.
• A feature you need is on the vendor's roadmap 'sometime,' and your business waits on their priorities, not yours.

A five-minute decision

Before the next renewal, run the short version. Is this a commodity or your differentiator? Project the three-year license curve with real growth, not today's headcount. Add up the workaround hours and the integration code you already maintain. If that total crosses a two-to-four-month build plus its maintenance tail — and the capability is core to how you compete — building stops being the expensive option and becomes the cheaper one. If it is a commodity with real compliance weight, keep buying and do not look back. The mistake is not choosing wrong once; it is never re-running the math as the numbers move underneath you.