Engineers have a default instinct: build it ourselves. It's more fun, we'll understand it deeply, and how hard could it be? Applied selectively, that instinct is great. Applied to everything, it's how teams end up maintaining a pile of homegrown infrastructure instead of shipping the thing that actually makes them money.
Build vs. buy is one of the most consequential decisions a team makes repeatedly, and most teams make it by gut rather than by framework. Here's the framework.
The build-vs-buy rule: build what differentiates you; buy everything else.
Building undifferentiated infrastructure feels productive but quietly drains the time you should spend on what makes you special. When in doubt, buy.
Building feels productive — you're writing code, making progress, in control. But every system you build is a system you must maintain forever: fix its bugs, patch its security, scale it, document it, onboard people onto it. The build cost is just the down payment; maintenance is the mortgage.
When you build undifferentiated infrastructure — the auth system, the email sending, the payment plumbing — you take on all that maintenance for something that gives you zero competitive advantage. Your users don't care that you built your own auth; they care about your actual product. Every hour on homegrown plumbing is an hour stolen from what makes you special. That's the quiet velocity killer.
The core question that resolves almost every build-vs-buy decision: does building this give us a real competitive advantage?
| Question | Build | Buy |
|---|---|---|
| Is this core to our product? | Yes → build | No → buy |
| Would doing it ourselves differentiate us? | Yes → build | No → buy |
| Do users value our version specifically? | Yes → build | No → buy |
| Is it undifferentiated plumbing? | — | Yes → buy |
If building something would genuinely make your product better in a way users value, build it — that's where your engineering effort creates advantage. If it's necessary infrastructure that every product needs and yours wouldn't be special, buy it. The test cuts through the "but it'd be fun to build" instinct.
Some categories are almost never worth building yourself because mature, reliable solutions exist and your version wouldn't differentiate:
In each case, specialized providers have poured years into solving the problem well. Your reimplementation would be worse, take forever, and need endless maintenance — all for something users don't value as yours. Buy these and move on.
Build the things that are your product — the core logic, the unique capabilities, the experience that makes users choose you over alternatives. This is where your engineering effort compounds into competitive advantage.
The clearest signal: if it's the reason customers pick you, build it and build it well. If it's something every competitor also needs and nobody chooses a product for, buy it. Your scarce engineering time should concentrate on the differentiated core, not get diluted across infrastructure that everyone has anyway. Modern AI app builders and developer tools can even accelerate the differentiated building — letting you spend your effort where it counts and buy or generate the rest.
Here's why this quietly determines velocity: teams that build everything spread their engineering across a sprawling surface of self-maintained systems. They're slow not because they're bad, but because they're maintaining ten things when they should maintain three. Every bug fix and security patch on homegrown plumbing is velocity stolen from the product.
Teams that buy the undifferentiated parts concentrate their full effort on the differentiated core. They ship faster on what matters because they're not distracted by maintaining infrastructure that gives them no edge. The build-vs-buy discipline is, ultimately, a focus discipline — and focus is velocity.
Q: Isn't buying more expensive than building it ourselves? Rarely, once you count maintenance. The build cost is just the start — you then own bugs, security, scaling, and upkeep forever. A paid service that handles all that is usually far cheaper than the true lifetime cost of a homegrown system, and it frees your team for differentiated work.
Q: What if no existing tool fits our needs exactly? First question whether your needs are genuinely special or just slightly different — most "we're unique" cases aren't. If a tool gets you 90% there for undifferentiated functionality, take it. Only build when your needs are both genuinely unmet and core to your competitive advantage.
Q: We already built something undifferentiated — should we rip it out? Not necessarily — if it works and is stable, the migration cost may not be worth it. But stop investing in expanding it, and when it needs major work or causes ongoing pain, that's the moment to migrate to a bought solution. Don't sink more into undifferentiated infrastructure.
Build vs. buy comes down to one test: does building this give you a real competitive advantage? Build what differentiates you and makes users choose you. Buy everything else — auth, payments, email, plumbing — because your version wouldn't be special and maintaining it forever quietly steals velocity from what matters. The engineer's instinct to build everything is the trap.
For your next "should we build this?" moment, ask whether users would value your version specifically. If not, buy it and pour the saved time into your differentiated core. That focus is what actually makes you fast.
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
I chased big, audacious goals for years and burned out every time. Then I built my whole life around wins so small they felt like cheating.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!