The Build vs Buy Decision

In one line: Default to buying for non-core capabilities; build only where you're the world's expert at that specific thing.

In plain English

People reliably underestimate the cost of building. A "two-week project" to add auth becomes six months of edge cases, security patches, and password-reset emails over the life of the system. Unless auth is your product, buying it from Clerk or Auth0 is almost always cheaper.

When to build

• It's your core differentiator. Building the thing that makes you unique.
• Existing options are genuinely inadequate. Not "I don't like the API"; truly missing critical capability.
• You have unique scale or constraints. Off-the-shelf tools don't fit your specific volume or shape of problem.
• Existing tools are too expensive at your scale and you've already calculated build-and-maintain cost.
• You have a specific competitive reason. A tool nobody else has gives you an edge.

When to buy

• The capability exists as a mature commercial product. Auth (Clerk), payments (Stripe), email (Resend), monitoring (Sentry), analytics (PostHog).
• It's not your differentiator. Building auth is not why customers chose you.
• You can't afford to specialize. Specialized vendors employ teams of experts; you can't match that focus.
• The build cost exceeds 2 years of license cost. You can revisit later.

The hidden cost of building

People underestimate maintenance:

• Initial build: 2 weeks.
• Edge cases discovered in production: 4 more weeks.
• Security updates: ongoing.
• Feature requests from users: never-ending.
• Documentation: months.
• Replacement when the original author leaves: weeks.

A "2-week build" easily becomes 6 months over the project's lifetime.

Specific build/buy cases

Capability	Default	When to build
Auth	Buy (Clerk, Auth0)	If your product IS auth
Payments	Buy (Stripe)	If at PayPal scale
Email	Buy (Resend, Postmark)	If email IS your product
Error tracking	Buy (Sentry)	At very large scale
Analytics	Buy (PostHog)	If analytics is your product
Feature flags	Buy (LaunchDarkly, PostHog)	Custom needs only
CMS	Buy or open-source	Highly custom editorial flow
Search	Buy (Algolia, Typesense)	Specialized at scale
Job queue	Buy (Trigger.dev) or OSS (BullMQ)	Massive scale
Live chat	Buy (Intercom)	Almost never
ML platform	Mixed	Often build at scale

Worked example: a $30 vs $300,000 decision

A small SaaS adds auth.

• Buy path: Clerk free tier today, ~$25/month when they hit 1,000 active users. Total first-year cost: ~$300. Two days of integration work.
• Build path: A "simple" auth system. Estimated 2 weeks. Real cost over 2 years (including password reset edge cases, two minor security patches, one social-login provider migration, one OAuth bug, documentation, hand-off when the original engineer leaves): conservatively 3 engineer-months. At a $300k fully-loaded engineer cost, that's ~$75,000 — and they still don't have features like SSO, MFA, or audit logs that Clerk gives them for free.

Build saved $300/year. It cost $75k. Buy wins by ~100x.

Highlight: the question that exposes the real cost

Before you "just build it," ask: "Who maintains this in three years, when the author has left and no one remembers why the password reset uses base32?" If you can't answer that question with a real name, buy.

Common mistakes

Where people commonly trip up

• Comparing the vendor's price to $0 instead of to the build cost. "$25/month is so expensive!" — compared to what? Compared to three engineer-months of work the vendor is replacing, $25/month is essentially free. Always price the build path at fully-loaded engineer cost, not at "we'd write it anyway."
• Building a "thin wrapper" that becomes the whole product. Teams convince themselves they're buying Stripe but "just wrapping it lightly for flexibility." Two years later, the wrapper has more code than the product. If you'd build a wrapper around it, you're really planning to build it — admit that now and decide deliberately.
• Forgetting that buying is also reversible. Engineers anchor on switching costs and refuse to buy because "we'll be locked in." You can usually swap auth providers in a couple of weeks if you isolate the integration. The lock-in story is a defense for the build instinct, not a real constraint.
• Underweighting what the vendor's roadmap gives you for free. When you build, every new feature (SSO, audit logs, passkeys, regional compliance) is your job. When you buy, the vendor ships those by default. The buy path quietly accumulates capabilities you didn't ask for — that's part of its real value.

Page checkpoint

Checkpoint Quiz

Did build vs buy stick?

Required

What's next

→ Continue to The Two-Pizza Rule — keep teams small enough that two pizzas can feed them.