The Seduction of "We'll Just Build It"

It always starts the same way. A team needs a tool. Someone looks at the commercial options, sees the price tag, and says: "We could build this ourselves for less." The room nods. A developer gets pulled off product work. A sprint or two later, there's a working prototype. It handles the core use case. Everyone's happy.

Fast-forward eighteen months. That prototype is now a production system. It has no documentation. The developer who built it has moved on — or wants to. It doesn't integrate with the three new platforms the company adopted since it was written. And every time something breaks, someone has to stop what they're doing and fix a tool that was never supposed to be anyone's full-time job.

The reason it keeps happening is that the decision to build was made by comparing the wrong numbers.

The TCO Nobody Calculates

When someone says "we can build this for less," they're comparing the purchase price of a commercial product against the development time to build a first version. That's maybe 20% of the actual cost.

Here's what the real Total Cost of Ownership looks like for an in-house tool:

  • Initial development — The part everyone accounts for. Usually underestimated by 2–3x, but at least it's on the spreadsheet.
  • Ongoing maintenance — Bug fixes, dependency updates, security patches, compatibility work when upstream systems change. This never stops. It's not a phase — it's a permanent line item.
  • Opportunity cost — Every hour a developer spends maintaining an internal tool is an hour they're not spending on the product your customers actually pay for. This is the biggest cost and the one most teams never quantify.
  • Knowledge concentration — In-house tools tend to live in one or two people's heads. When those people leave, take vacation, or get pulled onto something urgent, the tool becomes a black box with no support line.
  • Feature stagnation — A commercial product has a team of people whose entire job is to make it better. Your internal tool has whoever can be spared. It will fall behind. It always does.
  • Integration debt — Every new system the company adopts needs to work with the internal tool. That integration work falls on your team, not a vendor's.
The upfront cost of buying a solution is visible. The long-term cost of maintaining one you built is not — and that's exactly why it's more dangerous.

A $30,000/year SaaS product with a support team, a roadmap, and an integration library starts to look very different when the alternative is $200,000/year in developer time that nobody tracks because it's spread across tickets and "quick fixes."

The Prototype Trap

The most dangerous phase of an in-house tool is the one right after it starts working. The prototype handles the happy path. Demos go well. Leadership sees a functioning tool and assumes the work is mostly done.

It isn't. The prototype is maybe 20% of the real effort. The remaining 80% is everything that makes software actually production-ready:

  • Error handling and edge cases
  • Authentication, authorization, and audit logging
  • Monitoring and alerting
  • Backup and recovery
  • Documentation and onboarding
  • Performance at scale
  • Accessibility and multi-user support

Most in-house tools never get this work done. They ship at the prototype stage and stay there — accumulating workarounds, tribal knowledge, and increasingly fragile integrations. The team knows it's held together with duct tape. But rebuilding it would cost as much as building it right the first time, and nobody has the budget or appetite for that conversation.

The Real Trap

The sunk cost fallacy keeps teams invested in internal tools long after the economics have flipped. "We've already put so much into it" is not a reason to keep spending. It's a reason to audit what you're actually getting back.

When Building Actually Makes Sense

I'm not arguing that you should never build in-house. I've built plenty of internal tools — some of them are the right call. But the bar should be higher than "we could do this cheaper." The right reasons to build look like this:

  • Your workflow is genuinely unique — Not "we do things a little differently," but truly no commercial product addresses your core requirement. This is rarer than most teams think.
  • The tool is a competitive advantage — If the tool itself is part of your value proposition, owning it makes strategic sense. If it's plumbing, it doesn't.
  • You can commit to maintaining it — Not "a developer will keep an eye on it," but a real, funded, ongoing commitment to treat it as a product with a roadmap, an owner, and a maintenance budget.
  • You've genuinely exhausted the market — You've evaluated commercial options, talked to vendors, done trials, and confirmed that nothing fits. Not Googled for ten minutes and decided nothing exists.
If the tool isn't your product, it probably shouldn't be your problem.

The honest answer in most build-vs-buy decisions is that the team wants to build because building is more interesting than evaluating vendor contracts. That's a human impulse, not a business case.

The Developer Tax

Opportunity cost showed up in the TCO list, but it deserves its own section because of how it compounds. The damage isn't one big hit — it's a slow, invisible tax on developer velocity that nobody tracks.

A bug in the internal reporting dashboard pulls someone off the feature that was supposed to ship this sprint. An integration breaks because a third-party API updated, and now someone has to spend two days on a tool that isn't even customer-facing.

None of these incidents look expensive in isolation. A day here, half a sprint there. But compound them over a year, across multiple in-house tools, and the picture changes. I've seen teams lose 20–30% of their effective development capacity to internal tool maintenance without anyone realising it, because the time is scattered across dozens of Jira tickets and never aggregated.

A Simple Test

Add up every ticket, every Slack thread, every "quick fix" related to your internal tools over the last quarter. Convert it to developer hours. Multiply by your fully loaded hourly rate. Compare that number to the annual cost of the commercial alternative. Most teams are surprised — and not pleasantly.

The Exit Problem

Commercial products have migration paths. They export data in standard formats. They have APIs. When you outgrow them, you move to something else.

In-house tools have none of this. The data model is custom. The formats are proprietary. The business logic is embedded in code that only one person fully understands. Migrating away from an internal tool you've used for three years is often harder than the original build — and the team that built it may not even be around to help.

This is the coffin part. The tool that was built to save money becomes the thing you can't afford to leave. You're not maintaining it because it's the best option. You're maintaining it because you're locked in to your own creation.

At least with a vendor, lock-in is a known risk you can negotiate around. With your own tool, nobody even thinks about exit strategy until it's too late to have one.

How to Make Better Build-vs-Buy Decisions

If your team is facing a build-vs-buy decision right now, here's the framework I use:

  • Calculate the full TCO of building — not just initial development, but 3 years of maintenance, opportunity cost, and knowledge risk
  • Evaluate at least three commercial alternatives seriously — demos, trials, reference calls, not just pricing pages
  • Ask: "Is this tool our product, or is it plumbing?" — if it's plumbing, the default should be buy
  • Require a maintenance plan before approving a build — who owns it, what's the budget, what happens when they leave
  • Set a review date — revisit the decision in 12 months with real cost data, not assumptions
  • Track internal tool maintenance time explicitly — don't let it hide in sprint overhead

None of this means buying is always right. It means the decision should be made with real numbers, not vibes. The teams that get this right are the ones that treat internal tools with the same rigour they'd apply to any other capital investment — because that's exactly what they are.

The Bottom Line

Every in-house tool is a commitment. Not a one-time project — a permanent, ongoing commitment of time, attention, and developer capacity. Some of those commitments are worth making. Many aren't, and the ones that aren't tend to reveal themselves slowly, after the sunk cost is high enough to make walking away feel impossible.

The question isn't "can we build this?" Your team probably can. The question is "should we own this?" — and what does it cost us, not just to build, but to carry for the next five years?

If your organisation is sitting on internal tools that are quietly draining velocity, or you're facing a build-vs-buy decision and want a clear-eyed assessment before committing, I help teams audit their internal tooling landscape and make build-vs-buy decisions backed by real cost data. Let's talk about what you're actually spending.