Build vs buy: when to glue, when to roll your own

Founders romanticize "owning your stack." Indie folks especially. They roll their own auth at 11pm, name a function verifyToken, and act like it's a feature. It's almost always the wrong call. The opposite group goes too far the other way and pays $400/month for a stack that should cost $40, then wonders why the unit economics never work. Both are losing, just at different speeds.

Build vs buy is the question you'll answer twenty times before launch. Auth, payments, email, storage, search, analytics, CMS, admin, scheduling. Each one shows up as a fork in the road, and each one has a wrong default that feels right.

Three questions, in order

Before you write a line of code or sign a contract, run the decision through these.

Is this the thing your users pay you for? If yes, build it. If no, buy it. Your moat is your product, not your auth setup. Nobody has ever told a friend about a SaaS because the login flow was bespoke. The thing your customer notices, the thing they'd miss if you turned it off, that's where your code goes.

What's the cost of getting it wrong? Roll-your-own auth that gets exploited is a company-killer. Roll-your-own onboarding emails that bounce is a Tuesday. Match the rigor to the blast radius. Most founders flip this: they spend a weekend on a custom auth flow and then send transactional email through their personal Gmail.

How long does this lock me in? Buying a SaaS for the first 18 months is renting. You can swap. Writing custom code is a marriage. Every line is a future maintenance bill, every dependency is a CVE waiting to happen, every clever abstraction is a thing the next contributor has to learn before they can ship.

Three rules of thumb

Buy anything regulated or security-critical. Auth, payments, identity, email deliverability. The hidden cost of building these isn't day-1, it's day-300 when a CVE drops, or day-90 when your sender reputation tanks and your password resets land in spam. Specialists exist for a reason. Use them.

Glue when the integration cost is hours, not days. Webhooks plus Zapier (or Make, or n8n) between two SaaS products beats a custom integration in 9 out of 10 cases. The 10th case is when the glue itself becomes load-bearing for revenue, at which point you graduate it to real code.

Build only when one of three things is true: it's your moat, the SaaS option costs 5x what you can build it for at your current scale, or no SaaS exists for your specific niche. "I could probably do this in a weekend" is not on the list. You can probably do anything in a weekend. The question is what it costs you in month 14.

What to do, by category

• Auth: buy. Clerk, Auth0, Supabase Auth, WorkOS. Never roll your own.
• Payments: buy. Stripe. Same answer.
• Email: buy. Resend or Postmark for transactional, Mailchimp or Beehiiv for marketing.
• File storage: buy. S3, R2, Supabase Storage. The "I'll just store it on the server" instinct ends in tears.
• Search: buy if it's a core user feature (Algolia, Typesense Cloud). Build if it's internal or small (Postgres full-text gets you surprisingly far).
• Analytics: buy initially (PostHog, Mixpanel, Plausible). Build internal dashboards later if you outgrow.
• CMS / blog: glue. Markdown in the repo, or a headless option like Sanity or Contentlayer.
• Admin panel: glue (Retool, Tooljet) for small teams. Build only when the admin panel is itself the product.
• Background jobs: buy first (Inngest, Trigger.dev). Build when you're paying more in vendor fees than an engineer's afternoon would cost.

The hidden tax of each path

There's no free option, only different bills.

Buy has subscription creep. $19 here, $49 there, $79 for the tier that includes the feature you actually need. Six months in, you're at $800/month and you can't remember what half of it does. Audit quarterly. Cancel ruthlessly.

Glue is brittle. Zapier raises prices. An API endpoint deprecates. A webhook silently stops firing on Sunday at 3am and you find out Monday morning from a customer. Glue is fine, but log everything and have a fallback path for the integrations that touch money.

Build is forever maintenance. Every line you write today is a line someone (probably you) maintains, upgrades, and patches for as long as the product exists. The bill never arrives in one piece, which is exactly why it's so easy to underestimate.

The rent-then-own pattern

The cleanest path for almost everything in the gray zone: rent for the first 12 to 18 months. If it becomes a real cost line, and you understand the problem deeply because you've watched it run, then consider building. Most founders skip the first 12 months and try to build day one, when they understand neither the problem nor the customer well enough to draw the right boundaries. They lose.

Renting first is not a compromise. It's the research phase.

Next up

You've got the framework. The next guide, "Stack picks for solo builders in 2026," gets specific: the actual tools, the actual prices, the actual combinations that ship.