Building Internal Tools vs Buying Off the Shelf

A founder asked me last month whether they should build their own CRM.

The honest answer was: it depends. But not in the vague, hand-wavy way people usually mean. It depends on specific, mappable things. Things you can write down before you spend a single dollar.

The build-vs-buy question sounds like a technology decision. It isn’t. It’s a systems decision about who owns the process, who maintains it, and what happens when something breaks at 2 AM on a Sunday.

When buying works

Off-the-shelf tools are excellent when the process they serve is standard. If your sales pipeline follows the same shape as ten thousand other companies, a $20/month Notion workspace or a $50/seat Airtable base will handle it. You don’t need a custom database for a process that already has a name.

Buying works when:

• The process is common. CRM, project management, invoicing, basic reporting. These are solved problems. The tool already exists because thousands of businesses needed the same thing before you.
• The team is small. Five people can adapt to a tool’s constraints. They learn its quirks, work around its edges, and move on. The friction is manageable.
• Flexibility matters more than control. You want to change the workflow next quarter without rewriting code. Drag-and-drop beats deployment pipelines when the requirements shift monthly.
• Nobody can maintain custom software. This is the one most people skip. If nobody on your team can debug a Postgres query or update an API endpoint, a custom tool becomes a liability the moment the person who built it leaves.

Most businesses should start here. Not because off-the-shelf tools are better, but because buying is reversible. Building usually isn’t.

When building works

Custom tools earn their cost when the off-the-shelf option requires more workarounds than actual work.

Building works when:

• The process is genuinely unique. Not “we’re special” unique — structurally unique. Your data model doesn’t fit standard columns. Your workflow has branching logic that no template accounts for.
• Data ownership matters. You need to control where data lives, who accesses it, and how it’s backed up. A Supabase instance with proper row-level security is a different thing than a shared Airtable base where anyone with the link can export everything.
• The workaround ratio exceeds 40%. If you’re spending 40% of your time in the tool working around the tool, you don’t have a tool. You have a constraint dressed as a solution.
• Maintenance capacity exists. Either someone on the team can maintain the system, or you’ve budgeted $200/month for someone who will. Without this, custom tools decay on a predictable timeline.

The math is straightforward. A custom internal tool might cost $2,000 to build and $200/month to maintain. A SaaS tool might cost $20/month per seat. At ten seats, you’re paying $200/month either way — but one of them fits your process exactly and the other one almost does.

“Almost” is where the real cost hides.

The hidden cost of buying

Workarounds accumulate. They’re small at first. A manual step between two automations. A Notion page that should update automatically but doesn’t. A Zapier chain that breaks every month and takes an hour to debug.

Each workaround is trivial. Together, they form a parallel system — an invisible layer of manual labor that holds the official system together. Nobody documents it. Nobody accounts for the time it consumes. It just exists, distributed across the team, eating hours that never show up in any report.

The Airtable automation that doesn’t quite trigger correctly. The Monday.com board that requires someone to manually move cards because the status logic doesn’t match reality. The Google Sheet that someone maintains alongside the “real” system because the real system can’t produce the report the CEO wants.

This is the tax on buying. It’s real, and it compounds.

The hidden cost of building

Custom tools need maintenance. Not occasionally — continuously. APIs change. Dependencies update. The business evolves and the tool doesn’t, unless someone makes it evolve.

If nobody maintains the custom tool, it becomes the exact same problem it was built to solve. A rigid system that doesn’t match how work actually happens. Except now it’s worse, because there’s no vendor to call, no community forum to search, and no upgrade path.

I’ve seen custom tools go from “this changed everything” to “nobody uses it” in under a year. Not because they were badly built. Because nobody was responsible for keeping them alive.

The build decision is also a maintenance decision. If you can’t answer “who maintains this after it ships?” — don’t build it.

The decision framework

Before choosing a tool, map the process. Not the dream process. The real one. The one with the exceptions, the edge cases, and the step where someone calls another person because the system can’t handle what just happened.

Then ask three questions:

1. Does a standard tool cover 80% or more of this process? If yes, buy. Accept the 20% gap. It’s cheaper than maintaining custom software.
2. Is the remaining gap causing real cost? Not annoyance — cost. Lost revenue, compliance risk, hours that should go elsewhere. If the gap is just inconvenient, live with it.
3. Can you maintain what you build? Not “can you build it” — can you maintain it? Building is a one-time event. Maintenance is forever.

Most businesses should buy first. Use the tool until buying breaks. When buying breaks — when the workarounds cost more than the subscription, when the data model can’t hold what the business needs, when the gap between the tool and the process becomes a structural problem — then build.

Not before.

The founder’s answer

The founder who asked about building a CRM? They didn’t build it. Their sales process was standard. Their team was six people. Nobody on staff could maintain a database.

They bought a $30/seat CRM, added two Zapier automations, and moved on with their quarter.

Six months later, their onboarding process — which was genuinely unique — broke every project management tool they tried. They built a custom onboarding system on Supabase. It cost $3,000. Their operations lead maintains it.

Both decisions were right. Because they understood the system before they chose the tool.

---

Related

• Service: Operational Systems & Backend Architecture — Backend architecture, automation pipelines, and AI workflows.
• Article: The Difference Between Automation That Helps and Automation That Compounds — Why most automation doesn’t stick, and what makes the difference.
• Article: Workflow Automation vs Systems — Why automating a broken process just breaks faster.