“Build it yourself and you own it. Buy from a vendor and you’re locked in.”
I’ve heard this a hundred times. And I used to believe it.
Here’s the thing: this framing is wrong. Building your own platform creates lock-in too. Lock-in to your own codebase, your own team, and your own technical decisions.
But there’s an even more fundamental problem with the build vs buy debate. Most teams are asking the wrong question entirely.
The “Why Build At All?” Filter
Before asking “build or buy?”, ask a different question: Does building this give us a competitive edge?
If the answer is no, the conversation is over. Buy it. Move on.
The Bad Reason to Build
“We can build the same features cheaper than buying.”
I’ve seen this argument derail teams for months. It sounds reasonable. It’s also a trap.
You’re comparing sticker price to sticker price. But that’s not the real math. The vendor amortizes their R&D across thousands of customers. You don’t. They have a dedicated team maintaining that system. You’ll need one too.
And here’s what most people miss: you can always accommodate the cost of buying in your unit economics. If a vendor costs $10k/month, price it into your product. Your customers won’t notice the difference. But they will notice if you ship six months late because you were building auth instead of features.
Feature parity at a lower price isn’t a strategy. It’s a cost center waiting to become technical debt.
The Only Good Reasons to Build
So when should you build? There are really only four good reasons:
Competitive moat. Stripe built their own payment infrastructure. But payments ARE their product. That’s not overhead, that’s the business.
Differentiation. Netflix’s recommendation engine isn’t a nice-to-have. It’s core to why people stay subscribed.
The market doesn’t exist. Sometimes no vendor solves your exact problem. Fair enough.
Speed of iteration. You need to move faster than any vendor can keep up with. This is rare, but real.
Notice what’s not on this list? “It’s cheaper.” “We want control.” “The vendor’s UI is ugly.”
The Litmus Test
Here’s a sharper question: If we build this, does it help us win customers we couldn’t win otherwise?
If the answer is no, you’re building commodity infrastructure. Every dollar you spend there is a dollar not spent on what actually differentiates you.
The Hidden Cost You Can’t See
“But if we build, we save $50k/month on vendor fees. That’s $600k/year!”
Okay. Let’s do the real math.
What’s the fully-loaded cost of 2-3 engineers maintaining this? That’s $400-600k/year right there. What’s the opportunity cost of those engineers not building your core product? What’s the cost of being six months slower to market?
The vendor fee you can see. The opportunity cost you can’t. Guess which one kills more startups/ideas?
The “Competitive Edge” Test Is Harder Than It Looks
Here’s the trap: teams convince themselves everything is a competitive edge.
“Our custom deployment pipeline is a competitive advantage!”
No. Your customers don’t care how you deploy. They care what you deliver.
Try this test: Would a customer choose us BECAUSE of this system? Or despite it?
Auth? SSO? Deployment pipelines? Billing? Customers don’t care. They’re table stakes. Buy them.
Your recommendation engine? Your core product logic? The thing that makes you different? Build those.
The “We’re Special” Delusion
Every team thinks their requirements are unique.
“We can’t use off-the-shelf because our workflow is different.”
I’ve got three questions for that:
- Is your workflow different because it’s genuinely novel? Or because it evolved organically and nobody cleaned it up?
- Would adapting to the vendor’s workflow actually be… better?
- Are you building to serve customers, or to preserve internal politics?
Before you build because “our requirements are unique,” ask: are they unique because they’re valuable, or unique because they’re accidental?
When “Buy” IS the Competitive Move
Here’s something counterintuitive: sometimes buying creates competitive advantage.
You ship six months faster because you didn’t build auth. Your engineers work on what customers actually pay for. The vendor’s team has already solved edge cases you haven’t imagined yet.
The team that buys auth and ships a product beats the team that builds auth and ships nothing.
The Paradox of Internal Lock-in
Okay, so let’s say building is justified. You’ve passed the competitive edge test. You’re building something that genuinely differentiates you.
Here’s the catch: even justified builds create lock-in.
I’ve seen this pattern play out over and over. Systems start flexible, full of possibility. “We can change anything!” Over time, layers accumulate. SOAP. XML. That Java version nobody wants to upgrade. Each year adds another layer of calcium.
Eventually you’ve got a system that’s hard to change and scary to replace. Sound familiar?
Lock-in isn’t a bug of platform decisions. It’s a feature. The question isn’t whether you’ll be locked in. It’s which form of lock-in serves you better.
Why Internal Lock-in Is Actually Worse
Here’s something that took me years to understand: internal lock-in is often worse than vendor lock-in.
The villain problem. With vendor lock-in, you have an external enemy. “Oracle is holding us hostage!” You can rally the team against a common foe. But internal lock-in? There’s no villain. Just mirrors. Admitting the system needs replacing means admitting past decisions were wrong. That’s psychologically harder to confront.
The inheritance problem. New engineers didn’t build this system. They inherited it. To them, your internal platform might as well be a vendor product. But worse: no documentation, no support contract, no roadmap. At what point does a “build” become indistinguishable from a “buy”?
The compounding fear. Technical fear: “If we touch this, something breaks and we don’t know what.” Organizational fear: “The people who built this are gone.” These multiply, not add. You can’t ask the system, and you can’t ask the people.
The Better Questions
So here’s the reframe. Instead of “build or buy?” ask:
- What form of lock-in serves my goals?
- How do I make lock-in visible and discussable?
- How do I build in escape hatches before calcification sets in?
The answer isn’t to avoid building. It’s to build for replacement.
Building for Replacement
Every system you build will eventually need to die. Design for that from day one.
Contracts over implementations. Invest in API boundaries. The implementation behind the contract can be swapped. Your Java service exposes REST. The “Java” part should be invisible to consumers. When you need to rewrite it in Go (or whatever’s next), your consumers shouldn’t notice.
Data outlives code. Code rots. Data (in portable formats) survives. Keep your data extractable, documented, in standard formats. Your system dies, but its knowledge persists. I wrote more about this in Data Outlives Code.
ADRs that don’t decay. Document why you built it this way, not just what you built. Store decisions where they won’t rot (with the code, not in a forgotten wiki). This makes it safe to say “this decision was right then, not now.”
Explicit sunset dates. This is the big one. Node.js 24 has an EOL date from day one. Why don’t your internal systems?
Here’s what I propose: every internal system gets a “Support Window.”
Service: PaymentProcessor
Launched: 2024-01-15
Architecture Review: 2026-01-15 (2 years)
End of Life Consideration: 2029-01-15 (5 years)Not “we will definitely replace this.” Just “we will reconsider this.”
This changes the psychology completely. Replacement isn’t failure. It’s planned. New engineers know what they’re signing up for.
The Real Questions
Build vs buy isn’t a choice between freedom and lock-in. It’s a choice between lock-in with a vendor you can blame, and lock-in with a codebase that’s entirely your responsibility.
So here are the two questions that replace “build or buy?”:
Question 1: Does building this help us win customers we couldn’t win otherwise?
If no, buy. Accommodate the cost in your unit economics. Move on.
Question 2: If we must build, are we building something that can die gracefully?
Because even justified builds become legacy. Plan for that from day one.
This is part of a series on what lasts. Previously: Data Outlives Code on why your data is the real asset. Next: Context Outlives Prompts on what this means when AI enters the picture.