playbook.crastinating.pro
Build vs. buyTwo-way doorPublished 29 April 2026 · 4 min

Build vs. buy: internal tooling edition

When the next 'we'll just write a small internal tool' is sitting on the agenda — a four-question filter.

When to reach for this

The shape of the problem this playbook is for.

  • An engineer has a working weekend prototype of something a vendor sells.
  • A renewal price increase has prompted 'how hard could it be?' in a meeting.
  • The team has bought four tools in a year and is now building a fifth.

Signals you're ready

If these aren't true, you're not deciding yet — you're scoping.

  • You can name the off-the-shelf product the user would compare yours to.
  • The proposed build would touch security, identity, billing, or audit-trail code.
  • There are at least two engineers who'd happily own the tool for the next 18 months.

The rubric

Numbered, weighted, opinionated. Walk through them in order — the first decisive answer often ends the meeting.

  1. Decisive

    Is this a thing the customer pays us for, or a thing the customer assumes works?

    Customer pays for it → strong bias to build, this is your moat. Customer assumes it works (auth, observability, error tracking, billing) → strong bias to buy, the moat is somewhere else.

  2. Heavy

    What does the maintenance look like 12 months in, after the engineer who built it has moved on?

    If the answer is 'an oncall rotation nobody volunteers for' → buy. If 'an annual half-day touch-up' → build is fine. Maintenance, not initial build, is where in-house tools die.

  3. Heavy

    Will this need security or compliance attestation in the next 18 months?

    If yes (SOC 2, HIPAA, FedRAMP, ISO 27001), buying gives you a third-party attestation you can hand to the auditor. Building means you're authoring controls and writing the evidence yourself.

  4. Tiebreaker

    What's the all-in cost over 24 months — the build cost AND the maintenance cost AND the opportunity cost?

    Estimate engineer-months for build, ongoing FTE percentage for maintenance, and the next-best feature that engineer would have built. Compare to 24 months of vendor pricing — including the renewal hike.

Default pick

When the meeting is going in circles, ship this — and write down what would change your mind.

If it's not your moat, buy. Especially for security, identity, billing, and observability — the cost of getting these subtly wrong dwarfs the price of the vendor.

Red flags

Patterns that mean the playbook isn't your real problem.

  • 'How hard could it be?' is the question driving the conversation, not the customer.
  • The build estimate has a 1× number, no 2× contingency, and no maintenance line item.
  • The vendor's killer feature is being dismissed as 'we don't need that' when half the team uses it weekly.

Real applications

The playbook used in anger — context and outcome.

  • Context
    Auth0 contract renewing at 3.4×; an engineer has a Lucia + Postgres prototype.
    Outcome
    Bought (Clerk via Vercel Marketplace). The decisive factor was the upcoming SOC 2 audit — vendor attestation cleared a question we'd otherwise have authored.
  • Context
    Internal feature flag service — proposed because LaunchDarkly was 'too expensive'.
    Outcome
    Built, then rebought 14 months later. Maintenance ate 0.4 FTE; nobody wanted oncall for it.

Related briefs

Real decisions that used this playbook, written up in the Library.