Build vs buy for internal tools: a practical framework

The short answer

Buy when your process is standard — if a thousand other businesses do this workflow roughly the same way, someone has already built the tool, and they maintain it for less than you ever could.

Build when the workflow is your edge, when it’s genuinely unusual, or when you’re paying for three overlapping subscriptions and a spreadsheet to approximate something small and specific.

The interesting cases are in the middle — and the middle is where most businesses make the expensive mistake in both directions.

Start with an honest question: is your process actually special?

Most businesses believe their workflow is unique. Most workflows aren’t. Invoicing, scheduling, CRM, payroll, help desks, project tracking — these are solved problems with mature products, and “but we do it slightly differently” is usually a habit rather than an edge.

The buy-side default exists for a reason: a product company spreads development and maintenance across thousands of customers. You can’t beat that economics for a standard problem, and you shouldn’t try.

The test: would changing your process to match the tool cost you anything real? If adopting the off-the-shelf workflow loses you nothing but familiarity, buy the tool and adapt. If matching the tool would mean abandoning something customers actually pay you for — a pricing model competitors can’t match, a turnaround time built on a specific handoff, an intake process that wins deals — that’s the genuine build signal.

When buying quietly goes wrong

The failure mode of “buy” isn’t the tool being bad. It’s the accumulation:

• The 60% fit. The tool does most of the workflow, so staff bridge the rest with spreadsheets and re-entry. You’re now paying subscription and workaround payroll.
• Subscription sprawl. Three tools each covering part of the job, plus Zapier duct tape, plus the intern who reconciles them. At some point the monthly total exceeds what a small custom tool would have cost to build — annually, forever.
• The customization trap. Heavy configuration, custom fields, scripts inside someone else’s platform. You’ve built custom software anyway — on rented land, in the vendor’s format, unexportable.

If your team’s real workflow lives in the gaps between your tools, buying more tools won’t fix it. That’s usually an integration problem or a small-build problem.

When building quietly goes wrong

The failure mode of “build” is almost never the first version. It’s everything after:

• Nobody budgeted for maintenance. Custom software is a pet rather than a rock. Platforms update, staff request changes, edge cases surface. A tool with no owner degrades into next year’s rescue project.
• Scope grew until it competed with products. The “small tool” absorbed features until it was a bad version of something buyable. Small custom tools win by staying small and specific.
• It was built by whoever was handy. The ops person who knows some Python builds something genuinely useful — then leaves. Now it’s load-bearing, undocumented, and frozen. (This is one of the most common ways businesses acquire legacy software without noticing — see the real cost of maintaining it.)

Every one of these is avoidable with the same move: treat even a small build as a product with an owner, documentation, and a maintenance arrangement, rather than a side quest.

The framework

Walk the decision in order:

1. Can a standard tool do this with minor process change? → Buy. Done. (Be honest at this step; it filters most cases.)
2. Is the gap between tools, rather than a missing tool? → Integrate what you have before buying or building anything new.
3. Is the workflow a real differentiator, or genuinely absent from the market? → Build small. One workflow, one owner, documented, maintained.
4. Is the pain a spreadsheet that became a system? → That’s a build signal in disguise: the spreadsheet proves the need, defines the spec, and demonstrates the workflow is stable enough to encode.

And two cross-cutting rules:

• Count total cost on both sides. Subscriptions + workaround labor for buy; build cost + realistic annual maintenance (15–25% of build cost is a sane planning number) for build.
• Whoever recommends building should not be paid by the hour to build indefinitely. Fixed scopes, staged delivery, and a maintenance plan named up front.

What “build small” actually looks like

The internal tools worth building are usually boring and shockingly high-value: an intake form that enforces the rules the spreadsheet couldn’t; a dashboard that joins three systems so the morning meeting stops being data assembly; a quoting tool that encodes the pricing logic only two people know; an approval flow that stops things falling between email and Slack.

These take weeks to build. They replace the most expensive spreadsheet in the company, they’re owned and documented from day one, and they don’t try to become platforms — that’s what makes them keep working. That’s the shape of good internal tools work.

FAQ

How much does a custom internal tool cost?

Small, single-workflow tools typically land in the four-to-low-five-figure range built properly (documented, tested, maintainable) — often comparable to two or three years of the subscription sprawl they replace. The number that matters more is the maintenance line: if a quote has no answer for “who supports this next year,” it’s not a complete quote.

Isn’t no-code/low-code the answer here?

Sometimes, for step 3 workflows with simple logic — and it’s worth trying first. The caveats are the same as buying: you’re on rented land, complexity has a ceiling, and heavily-scripted no-code apps become unmaintainable custom software with extra steps. Use it where the workflow is simple; graduate deliberately when it isn’t.

We already built something and it’s now fragile — rebuild or fix?

Usually fix: the tool proved its value by becoming load-bearing, and stabilizing it (access, documentation, error visibility, an owner) is far cheaper than rebuilding. The framework for that call is in fix or rebuild.

Do you build tools for companies outside Ontario?

Yes — internal tools work is remote-first. I’m based in Oshawa, Ontario and work with businesses across North America, with ongoing support after delivery.

Stuck in the middle?

If you’re not sure whether your situation is step 1, 2, 3, or 4, that’s a diagnosable question. A Business Systems Audit maps the workflow, the tools, and the gaps — and gives you the build/buy answer with numbers attached. Or describe the workflow and I’ll tell you what I’d do.