Build vs Buy Internal Tools: When Founders Should Build Their Own

Build an internal tool when it touches your core data or core workflow, when per-seat SaaS pricing scales faster than your headcount justifies, or when the off-the-shelf version forces your team to work around it every day. Buy when the tool is a commodity, when your need is standard, and when the vendor's uptime and security are things you would rather rent than own. AI-assisted development has moved the line toward building, but it has not moved the line on maintenance, and that is where most founders get the math wrong.

Why the question is back on the table

For a decade the default advice to founders was simple: never build what you can buy. Engineering time was scarce, SaaS was cheap, and every hour spent on an internal tool was an hour not spent on the product.

That advice was written for a world where a "small" internal tool took a team a quarter. It no longer does. Developers now routinely rebuild a scoped version of a commercial product, a browser screen recorder, a photo search tool, a lightweight CRM, in a weekend with an LLM doing most of the typing. The cost of the first version has collapsed.

But the first version was never the expensive part. Owning the thing is. Our own outreach engine, described below, took far less time to get working than it has taken to keep working: scrapers break, model versions change, and one engineer still spends part of every month on it. The first version was cheap. The second year is the real price. So the question has changed from "can we afford to build this" to "can we afford to keep this alive", and that needs a different framework.

The four questions that decide it

1. Does the tool sit on your core data?

If the tool reads or writes the data that makes your business valuable, customer records, usage events, clinical notes, pricing logic, then buying means handing your most important asset to a vendor's data model and export policy. You will spend months fighting their schema and their API limits. Tools on core data lean strongly toward build.

If the tool holds data you would not miss, meeting recordings, design mockups, standup notes, buy it and move on.

2. How does the SaaS price scale?

Per-seat pricing is the trap. It looks trivial at five people and becomes a line item the finance lead asks about at forty. Do the three-year arithmetic before you sign.

An illustrative example: a tool at $30 per seat per month for 40 people is $14,400 a year, or $43,200 over three years. That is before the inevitable tier upgrade when you need SSO or an audit log. A focused internal tool built in two to three weeks and maintained a day or two a month usually lands well under that over the same period.

Usage-based pricing is friendlier. If you only pay for what you use and usage tracks revenue, buying is often fine even at scale.

3. Who fixes it when it breaks?

This is the question founders skip. An internal tool has dependencies that rot, a third-party API that changes its auth flow, a database that needs a migration, and a security patch that lands on a Friday. If nobody owns it, it quietly becomes the kind of debt we describe in technical debt management: working, unloved, and terrifying to touch.

Rule: an internal tool with no named owner is a liability, not an asset. If you cannot name the person who will maintain it next year, buy.

4. Will you keep changing it?

If your requirements for the tool shift weekly, because you are still learning your own process, SaaS will fight you at every step. Custom fields, Zapier glue, and workaround spreadsheets pile up. Building wins when the tool is a moving target.

If the process is stable and standard, invoicing, expense reports, calendar booking, the vendor has already solved it better than you will.

Our own example: the outreach engine

We run our own outbound at the agency, and this decision came up for us directly. The off-the-shelf personalization tools either produced generic emails or charged per enrichment credit in a way that scaled badly with the volume we wanted.

So we built it. A self-hosted Firecrawl instance scrapes each prospect's site, a local LLM reads the result, and the engine writes one tailored email per company. It runs on hardware we already had, so the marginal cost per prospect is close to zero.

The part that mattered for build versus buy was what happened after the first version. Our initial pipeline chained several steps: extract facts about the company, plan the angle, then draft. When we collapsed that into a single call that extracts and drafts together, it came out ahead on both cost and quality. We could only learn that because we owned the tool and could change the prompt architecture in an afternoon. With a SaaS product that experiment is not available to you. We cover the general pattern in single call vs agent chains, and the specific case in AI cold email agent: build vs buy.

The honest cost of that decision is that one engineer spends part of every month keeping it healthy, because scrapers break and model versions change. We consider that worth it. You should decide whether your equivalent is.

What a good "build" looks like

If the four questions point toward building, keep it disciplined:

• Scope to one workflow. Not "an internal CRM", but "the view the sales lead needs every Monday morning". You can widen it later.
• Use a boring stack. For us that is Next.js, PostgreSQL or Supabase, and TypeScript. Sometimes it is a script and a cron job. The goal is that any engineer on the team can fix it.
• Time-box the first version. One to three weeks. If it does not fit, the tool is bigger than you think.
• Name an owner and budget their time. Treat it as a small product with a backlog, not a side project.
• Instrument it. A tool nobody knows is broken is worse than no tool. Log runs, alert on failures.

When buying is clearly right

Some categories are not close:

• Authentication, payments, transactional email. The vendor's security and deliverability are the product. Do not own these.
• Anything with a compliance surface. If the tool will be in scope for SOC 2, HIPAA, or a data-residency audit, you want a vendor's attestation, not your own.
• Commodity collaboration. Video calls, docs, chat. Your version will be worse and nobody will thank you.
• Anything you need this week that is not core. Buy it, set a calendar reminder for the renewal date, and re-run this framework then.

A rule you can apply in one meeting

Score the four questions. If two or more say build, build a time-boxed first version for one workflow with a named owner. If fewer than two do, buy, and revisit at the next renewal.

Run our outreach engine through it and you can see the scoring in practice. Core data: partly, since prospect research feeds our pipeline but we would survive losing it. Pricing: the per-enrichment-credit model scaled badly with the volume we wanted, so build. Owner: one engineer, named, with part of each month budgeted, so build is allowed. Changing it: we rewrote the prompt architecture from a multi-step chain to a single call once we had data, so build. Three of four said build, and the decision has held.

Write the decision and the date down, because the right answer changes as the company grows and the honest thing is to re-check it rather than defend it.

Where an agency fits

Most founders do not lack the judgment to make this call. They lack an engineer with two free weeks. That is the gap we fill: a scoped internal tool, built on a stack your team already knows, handed over with an owner's manual rather than a dependency. If you are staring at a SaaS renewal and wondering whether to build instead, let's talk.