Early-stage teams spend a surprising amount of time debating whether to build something in-house or use an existing solution. It’s a worthy debate — the wrong call either direction can cost months.
Here’s the mental model I use, distilled from making this call dozens of times across very different projects.
The Core Question
Before anything else, ask: is this a differentiator?
If the thing you’re considering building is part of what makes your product unique — what customers are actually paying for — build it. If it’s plumbing that every application needs, look for something to buy or borrow first.
Authentication is plumbing. Your domain-specific recommendation engine is a differentiator. Your billing logic might be plumbing; your pricing model might be a differentiator. The line isn’t always clean, but the question focuses the discussion.
When to Buy
Buy when:
- The problem is well-understood and solved. Why rebuild a PDF generation library, an email sending service, or a geocoder? Hundreds of teams have already done it, and the best solutions have battle-tested edge case handling you’d spend months discovering on your own.
- The maintenance burden is real. Every line of code you write is a line of code you own forever. Third-party solutions outsource that maintenance to people whose entire job is maintaining it.
- Speed matters more than perfect fit. Getting something working in a day beats spending a sprint on something bespoke.
When to Build
Build when:
- You’ve tried what’s available and it doesn’t fit. This sounds obvious, but teams often jump to building before genuinely evaluating alternatives. Do the evaluation first.
- The vendor risk is unacceptable. If the solution you’re considering is a single-founder SaaS that could disappear next year, and this is core to your product, that’s a real risk to factor in.
- You need to understand the internals. Sometimes building a thing — even if you’ll eventually replace it — is how you learn what you actually need.
The Third Option: Borrow
There’s a middle path that doesn’t get enough attention: open-source solutions you host yourself.
You get the benefits of not building from scratch (the hard problems are solved, there’s a community, the code is auditable) with more control than a managed service. The tradeoff is operational overhead — you’re running it, so you’re responsible for it.
For teams with some infrastructure comfort, this is often the best of both worlds.
The Honest Answer
The honest answer is that this decision is always a judgment call, and it should be made quickly. Spend an afternoon evaluating, pick a direction, and revisit in six months if the choice isn’t working.
The teams that get stuck are the ones optimizing for the perfect answer rather than a good-enough answer made fast.