Build vs. Buy: The Software Decision That Quietly Determines Your Velocity

Build vs. Buy: The Software Decision That Quietly Determines Your Velocity

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.

Quick Answer

The build-vs-buy rule: build what differentiates you; buy everything else.

• Build the things that are core to your product, where doing it yourself is a genuine competitive advantage.
• Buy (or use existing tools/services) for everything that's necessary but undifferentiated — auth, payments, email, infrastructure plumbing.

Building undifferentiated infrastructure feels productive but quietly drains the time you should spend on what makes you special. When in doubt, buy.

Photo by Carlos Muza on Unsplash

The hidden cost of building everything

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 differentiation test

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.

What to almost always buy

Some categories are almost never worth building yourself because mature, reliable solutions exist and your version wouldn't differentiate:

• Authentication — solved, security-critical, easy to get subtly wrong.
• Payments — heavily regulated, complex, high-stakes to build badly.
• Email/transactional sending — deliverability is a deep specialty; use a transactional email service.
• Infrastructure plumbing — hosting, queues, caching, monitoring.
• Common SaaS functions — CRM, analytics, scheduling.

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.

What's worth building

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.

The velocity connection

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.

The bottom line

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.

The Opportunity Cost of ‘Just One More Feature’

Teams often justify building undifferentiated components by framing them as ‘just one more feature’—a small addition to an existing system that feels low-effort. The trap lies in the cumulative effect: a custom auth layer, a homegrown payment processor, and a bespoke email service don’t feel like a burden when built in isolation. But together, they form a sprawling surface area that demands constant attention. The opportunity cost isn’t just the initial build time; it’s the compounding tax of context-switching between these systems when debugging, scaling, or onboarding new engineers. Every time an engineer touches one of these systems, they’re not working on the core product. Over a year, this adds up to hundreds of hours diverted from what actually moves the needle.

The antidote is to treat undifferentiated systems as shared liabilities, not isolated projects. Before adding a new component, ask: If we had to maintain this for the next five years, would we still build it today? If the answer isn’t an emphatic ‘yes,’ buy it. This mindset shift forces teams to confront the long-term cost of ownership, not just the short-term convenience of control.

When ‘Buy’ Becomes a Strategic Lever

Buying undifferentiated components isn’t just about saving time—it’s about accessing capabilities you couldn’t build yourself. Specialized vendors invest decades into solving problems like payment fraud detection, email deliverability, or global CDN performance. These aren’t just ‘nice-to-haves’; they’re table stakes that most teams couldn’t replicate even if they wanted to. For example, a transactional email service doesn’t just send emails—it handles spam filters, bounce rates, and regional compliance, all of which are invisible to users but critical to reliability. By buying these services, you’re not just offloading work; you’re upgrading your product’s quality in ways that would be prohibitively expensive to achieve in-house.

The strategic advantage of buying becomes even clearer when you consider time-to-market. A team that buys its auth, payments, and hosting can ship a functional product in weeks, while a team building all three might take months. That speed isn’t just about efficiency—it’s about learning. The faster you ship, the sooner you get feedback, iterate, and refine your differentiated core. In competitive markets, this feedback loop can be the difference between leading and playing catch-up. Buying the undifferentiated parts isn’t a shortcut; it’s a force multiplier for the work that actually matters.

The Migration Playbook: How to Escape the Build Trap

Teams often find themselves stuck maintaining undifferentiated systems they built years ago, even when they know they should migrate. The problem isn’t a lack of awareness—it’s the perceived cost of migration. The key is to treat migration as a phased process, not a big-bang rewrite. Start by identifying the pain points of the existing system: Is it causing outages? Is it hard to scale? Is it a black box that only one engineer understands? These are the signals that it’s time to move. Next, pick a low-risk migration path:

• Parallel run: Deploy the new system alongside the old one, using feature flags to gradually shift traffic. This lets you validate the new system without risking downtime.
• Strangler pattern: Incrementally replace parts of the old system with the new one, starting with the least critical components. This reduces risk and spreads the migration effort over time.
• Hybrid approach: Use the new system for new features while keeping the old one for legacy functionality. This lets you stop investing in the old system without a full rewrite.

The goal isn’t to migrate everything at once—it’s to stop the bleeding. Once the new system is in place, you can decommission the old one piece by piece. The critical insight is that migration isn’t an all-or-nothing decision; it’s a series of small, reversible steps that gradually reduce your maintenance burden. The sooner you start, the sooner you free up your team to focus on what actually moves the needle.

Key Takeaways

• Apply the differentiation test: build only what gives you a real competitive advantage—users must value your version specifically, not just the functionality.
• Default to buying undifferentiated infrastructure (auth, payments, email, hosting) unless your needs are genuinely unmet and core to your product’s edge—most ‘unique’ cases aren’t.
• Treat homegrown systems as mortgages: the build cost is the down payment; maintenance (bugs, security, scaling, docs) is the recurring debt that quietly drains velocity.
• Concentrate engineering effort on the differentiated core—every hour spent on undifferentiated plumbing is an hour stolen from what makes your product special.
• When evaluating ‘buy,’ prioritize tools that cover 90% of your needs for undifferentiated work; only build if the gap is both critical and a true competitive lever.
• Migrate away from self-built undifferentiated systems when they cause pain—don’t rip out stable ones, but stop investing in expanding them.