Reinventing the Wheel
People love saying “don’t reinvent the wheel” as if it ends the conversation.
It doesn’t. It’s a lazy metaphor that dodges the real question: What do we gain or lose by building something ourselves?
Most “wheels” in tech aren’t wheels at all—they’re rented parts with hidden constraints, vendor lock-in, opaque decision-making, and unpredictable pricing. They’re not simple mechanical objects. They’re dependencies. And dependencies always have a cost.
Vendors want one thing: to own your product. Every vendor will tell you it’s “wise,” “strategic,” and “efficient” to buy instead of build. Of course they will—you’re their revenue. The more you depend on them, the higher your LTV.
If they can own your authentication, your notifications, your payments, your analytics, your infrastructure… they effectively own your customers, your operations, and quickly your product roadmap.
When the core parts of your stack live behind someone else’s APIs, your leverage evaporates. You’re no longer designing a system—you’re assembling a dependency tree and hoping no leaf falls off.
Convenience feels good in the short term. Ownership pays off in the long term.
The most resilient products and systems aren’t the ones with several dozen APIs neatly strung together. They’re the ones that can survive when the world around them breaks.
Resilience comes from having fewer external dependencies, not more.
Teams that lean too heavily on external services become risk-averse, overly cautious, and shallow in technical depth. They stop understanding the problems they claim to solve. They become operators of glue code, not builders.
API-stitched products are brittle by design. One upstream outage becomes your outage. One pricing change becomes your crisis. One deprecation becomes your roadmap.
“Build vs. buy” isn’t about saving time or a few dollars. It’s about sovereignty, optionality, and competence.
• Build when the problem is foundational.
• Buy when the problem is peripheral.
• Never buy something that controls your customer experience more than you do.
• Never delegate your core value prop to a company whose incentives misalign with yours.
It doesn’t. It’s a lazy metaphor that dodges the real question: What do we gain or lose by building something ourselves?
Most “wheels” in tech aren’t wheels at all—they’re rented parts with hidden constraints, vendor lock-in, opaque decision-making, and unpredictable pricing. They’re not simple mechanical objects. They’re dependencies. And dependencies always have a cost.
Vendors want one thing: to own your product. Every vendor will tell you it’s “wise,” “strategic,” and “efficient” to buy instead of build. Of course they will—you’re their revenue. The more you depend on them, the higher your LTV.
If they can own your authentication, your notifications, your payments, your analytics, your infrastructure… they effectively own your customers, your operations, and quickly your product roadmap.
When the core parts of your stack live behind someone else’s APIs, your leverage evaporates. You’re no longer designing a system—you’re assembling a dependency tree and hoping no leaf falls off.
Convenience feels good in the short term. Ownership pays off in the long term.
The most resilient products and systems aren’t the ones with several dozen APIs neatly strung together. They’re the ones that can survive when the world around them breaks.
Resilience comes from having fewer external dependencies, not more.
Teams that lean too heavily on external services become risk-averse, overly cautious, and shallow in technical depth. They stop understanding the problems they claim to solve. They become operators of glue code, not builders.
API-stitched products are brittle by design. One upstream outage becomes your outage. One pricing change becomes your crisis. One deprecation becomes your roadmap.
“Build vs. buy” isn’t about saving time or a few dollars. It’s about sovereignty, optionality, and competence.
• Build when the problem is foundational.
• Buy when the problem is peripheral.
• Never buy something that controls your customer experience more than you do.
• Never delegate your core value prop to a company whose incentives misalign with yours.
Published on Sunday, November 16th at 00:07 AM from Amsterdam, Netherlands