Internal tools: build vs buy

Every growing company hits the same wall. The spreadsheet that ran ops for two years now has 40 tabs, three people who understand it, and one formula that nobody dares touch. Someone asks the obvious question: should we build a real tool, or buy something? The honest answer is that it depends, and most teams get the decision wrong in both directions.

What "internal tool" actually means here

When founders say "internal tool," they usually mean one of a few things: an admin panel to manage users and refunds, an ops dashboard to track orders or inventory, a back-office workflow (approvals, onboarding, content moderation), or a reporting view that pulls from a few systems. These are not customer-facing products. Nobody is going to tweet about your refund console. That changes the math completely, because the goal is throughput for your team, not delight for a market.

The build vs buy question is really three questions hiding in a trench coat: build from scratch, assemble on a low-code platform, or buy an off-the-shelf product. Treating it as a binary is the first mistake.

When buying (or assembling) wins

Buy when the problem is genuinely solved and not specific to you. You do not build your own help desk, your own error tracking, or your own basic CRM. The market versions are cheaper than a single engineer-month and they come with support, integrations, and a team improving them while you sleep.

The middle path, and the one most teams underrate, is the internal-tool builder. Tools like Retool, Appsmith, Budibase, or Tooljet let you point at your existing Postgres or your API and drag a table, a form, and a few buttons into something usable. For a CRUD admin panel over a database you already own, this is often the right call.

Rough numbers, framed as rough: a competent engineer can stand up a working Retool app over an existing database in a few days. Platform cost lands somewhere in the low hundreds of dollars per month once you have a handful of editors and a real number of end users. Compare that to two or three weeks of custom build time for the same screens, and the platform usually wins on speed to value.

Assemble or buy when:

• The workflow is standard CRUD: list, view, edit, delete records.
• You need it next week, not next quarter.
• The people using it are a handful of internal staff, not hundreds.
• The data already lives somewhere clean and queryable.

When building from scratch wins

Custom build wins when the tool is the differentiator, or when the constraints make a generic platform fight you the whole way.

A few concrete triggers:

Deep, weird business logic. If your "approve order" button needs to check inventory across three warehouses, apply customer-specific pricing rules, and trigger a fraud check, you are going to write real code regardless. At that point a drag-and-drop builder becomes a place where you write real code badly, inside someone else's box. Better to own it.

Performance and scale. Internal-tool platforms are great for a dozen users clicking around. Put 200 warehouse staff hammering it during peak season and you will start hitting their pricing tiers and their performance ceilings at the same time. If the tool is load-bearing for daily operations, the custom version pays for itself, the same way it does when you are scaling a web app through traffic spikes.

Compliance and data boundaries. If you are in health, finance, or anything with auditors, "our customer data flows through a third-party SaaS renderer" is a sentence that starts long meetings. Sometimes self-hosting the platform solves it. Sometimes building in your own stack is the cleaner answer.

It will outlive the decision. Tools have a way of becoming permanent. The "quick internal thing" becomes the system of record. If you can see that future coming, the cheap option becomes expensive later.

Rough timeline and cost for a custom internal tool, again clearly rough: a focused admin panel with auth, a handful of resources, role-based access, and an audit log is a 3 to 6 week build for a senior engineer, landing somewhere in the low five figures if you hire it out. A genuine ops platform with custom workflows, integrations, and real-time updates is a multi-month engagement. Anyone quoting you an exact figure before seeing your data model is guessing.

A simple way to decide

Score the tool on four axes before anyone writes code:

1. How specific is the logic?

Generic CRUD leans buy or assemble. Logic nobody else has leans build.

2. How many people, how often?

A tool five people open weekly tolerates rough edges and platform limits. A tool fifty people live in all day justifies a custom build because friction multiplies across every user, every hour.

3. How long will it live?

If it replaces a core spreadsheet or becomes a system of record, treat it as a product with an owner, not a side project.

4. What is the cost of it being down or wrong?

If a bug means a wrong refund or a missed shipment, you want code you control, tests you wrote, and logs you can read.

If three of four point toward "buy or assemble," do that and move on. If three of four point toward "build," budget for it properly instead of pretending it is a weekend job.

What to watch out for

A few traps that cost teams real money:

The low-code lock-in surprise. Your logic now lives inside a proprietary editor. Migrating off it later means rebuilding from scratch, because there is no clean export of your business rules. This is fine if you go in with eyes open. It is painful when it ambushes you in year three.

The "we'll just give them database access" era. Before any tool exists, someone is running raw SQL against production to issue refunds. This works until the day a typo turns one refund into a thousand. An internal tool with guardrails is partly about safety, not just convenience.

Skipping auth and audit. The two things people cut to ship faster are exactly the two things you regret cutting. Who did what, and who is allowed to. Build them in from the start whether you buy or build, because retrofitting an audit trail onto live data is miserable.

Building a product when you needed a screen. The opposite failure. Not every internal tool needs a design system, a component library, and six weeks of polish. If it is a refund button for three support agents, ship the ugly version that works and spend the saved time on the thing customers actually pay for.

The takeaway

Default to buying or assembling for anything standard, and reserve custom builds for tools where the logic is yours, the usage is heavy, or the stakes are high. Decide deliberately using usage, longevity, logic, and blast radius, then resource the decision honestly instead of dressing a real project up as a quick hack. The good kind of lazy is buying the boring 80 percent and building only the 20 percent that actually matters to your business.

If you are staring at a spreadsheet that has clearly outgrown itself and you are not sure which side of the line you are on, that is exactly the kind of call we are happy to talk through.