Build or buy: how startups should decide which internal tools to code

Every internal tool your engineers build is a product with one customer, no revenue and a permanent maintenance bill. That framing sounds harsh, but it is the most useful way to think about the build-or-buy question that lands on a founder's desk every few months.

The request usually arrives innocently. Someone needs an admin panel, a billing reconciliation script, a lightweight CRM or an onboarding tracker. An engineer says it is a weekend of work. The weekend is real. What follows it is the part nobody prices.

The cost that does not show up in the estimate

A build estimate measures the first version. The real cost is everything after: patching dependencies, fixing the tool when an upstream API changes, adding the permission model someone asks for in month four, and answering questions from the colleague who inherits it when the original author leaves. Internal tools rarely get documentation, tests or an owner, which is why they tend to break at the worst possible time.

There is also an opportunity cost that is easy to state and hard to feel. An engineer-week spent on an internal dashboard is an engineer-week not spent on the product customers pay for. At an early-stage company with a handful of engineers, that trade can eat a meaningful share of a quarter's capacity.

Security is the third hidden line. A homegrown tool that touches customer data needs access controls, logging and a plan for removing access when employees leave. Commercial software has its own risks, but a reputable vendor has usually already done that work and can show you evidence of it.

A simple test: core or context

The cleanest filter is whether the tool touches what makes your company different. If the workflow is part of how you win customers or deliver the product, owning it can be a real advantage. If it is a function every company performs in roughly the same way, such as payroll, expense management, ticketing or applicant tracking, buying is almost always the better default.

A useful gut check: imagine a competitor running the exact same tool. If that would not hurt you, the tool is context rather than core, and it should not be consuming scarce engineering time.

There are exceptions. Sometimes the off-the-shelf options are built for companies ten times your size and force a heavy process on a small team. Sometimes your data model is unusual enough that every vendor needs expensive customization. And sometimes the commercial product is priced per seat in a way that gets painful as headcount grows. Those are legitimate reasons to build, but they should be stated explicitly rather than assumed.

What buying really costs

Buying carries hidden costs too. Subscription software brings integration work, admin overhead and a contract that renews whether or not anyone still uses the tool. Per-seat pricing scales with headcount, and annual contracts often include auto-renewal clauses with notice windows that are easy to miss.

The bigger risk is lock-in. Before you sign, confirm that you can export your data in a usable format, that there is an API if you will need to connect the tool to other systems, and what happens to your data if the vendor is acquired or shuts down. A tool that holds your operational history without a clean export path is a liability dressed as a convenience.

Vendor sprawl is the slow version of the same problem. Young companies tend to accumulate overlapping subscriptions bought on individual cards. A quarterly review of every recurring software charge, with a named owner for each, catches tools nobody uses and duplicates that do the same job.

The middle path most teams skip

The choice is rarely binary. Low-code platforms, spreadsheet-backed apps and workflow automation tools let a non-engineer assemble something good enough without touching the main codebase. AI coding assistants have also made the first version of a custom tool much cheaper to produce. That lowers the build cost but does not change the ownership cost, because someone still has to maintain whatever gets generated.

A sensible sequence for many startups is to start with the simplest thing that works, buy when the workflow stabilizes and a mature product fits, and build only when you have outgrown the market's options and can name the specific limitation that is costing you money or customers.

What to do before the next request lands

Write a one-page decision memo for any internal tool that will take more than a few days to build or will cost more than a modest annual subscription. It should name the problem, the options considered, the estimated maintenance burden and the person who will own the result.

Assign an owner to every internal tool, built or bought. Ownerless tools are the ones that quietly break or quietly keep billing.

Set a revisit trigger. A tool that made sense at ten employees may not make sense at fifty, so agree in advance on the headcount, cost or pain level that reopens the decision.

Keep an exit plan for every bought tool that holds important data: where the export lives, what format it comes in and how long a migration would take. You will rarely need it, but the one time you do, it will save weeks.

And when an engineer says a new tool is only a weekend of work, ask who will be fixing it a year from now. If nobody has an answer, buy.