Most companies treat build-vs-buy as a decision they make once, at the start of a project, and never formally revisit. That makes sense at the time — it’s a real decision with real analysis behind it, and once it’s made, attention moves to execution. The problem is that the conditions that justified the original decision don’t stay fixed, and a decision that was correct three years ago can be quietly wrong today without anyone noticing, because nobody scheduled a moment to check.
Here’s a framework for recognizing when it’s time to look again.
Why the Original Decision Stops Being the Right One
Your scale changed. A “build” decision often makes sense when your needs are specific enough that no off-the-shelf tool fits well, or when you’re small enough that a commercial tool’s pricing model doesn’t work for you yet. As you grow, both of those conditions can flip — vendors you dismissed as too expensive at your old scale may now offer better economics than maintaining custom software, and vendors who didn’t have your specific feature three years ago may have built it since.
The vendor landscape matured. Three years is a long time in software. A category that had no strong options when you made your original “build” decision might now have several mature competitors solving the exact problem you built custom software for. This is one of the most common reasons a build decision ages poorly — not because building was wrong at the time, but because the market caught up.
Your team’s priorities shifted. A “build” decision commits ongoing engineering time to maintaining that system, indefinitely, as a cost that’s easy to undercount at decision time. If your engineering priorities have moved toward a different core competency, the maintenance burden on a system that was worth building three years ago may now be pulling attention away from what actually differentiates your business today.
The original “buy” option had real gaps that got fixed. Sometimes the reverse happens — you built because the buy options were missing a critical feature, and that feature has since been added by a vendor. Revisiting isn’t just about looking for reasons to switch off custom systems; it’s equally about recognizing when a buy option has become viable that wasn’t before.
A Practical Review Cadence
The mistake most companies make isn’t picking build or buy incorrectly — it’s never scheduling a review at all. A build-vs-buy decision, once made, should have a standing calendar reminder to revisit it, not wait for a crisis (a maintenance burden becoming unbearable, a key engineer who understood the system leaving) to force the conversation.
Annually, for any significant build-vs-buy decision: a light check — has the vendor landscape changed, has our scale changed enough to shift the economics, is the maintenance cost still proportionate to the value the system provides.
Triggered review, regardless of schedule: a significant change in team size, a key person leaving who was the primary maintainer of a custom system, or a new vendor entering the market with a credible offering in the relevant category.
What Makes Revisiting Hard (And Why to Do It Anyway)
The natural resistance to revisiting a build decision is sunk cost — you’ve already invested in building and maintaining the system, and switching to a vendor means admitting some of that investment won’t carry forward. This is a real psychological pull, and it’s exactly the trap the review cadence is designed to counteract: the original investment is sunk either way, and the only question that should matter going forward is which option is better from today, not which option makes the original decision look more justified in hindsight.
The same resistance can work in the other direction — a company that bought a solution years ago may resist building a replacement even after their needs have outgrown what the vendor offers, because switching feels like admitting the original vendor relationship has run its course.
The Bottom Line
Build-vs-buy is not a decision you make once. It’s a decision you make, then schedule a specific point to genuinely reconsider, with the same rigor as the original analysis — not just a rubber stamp on the status quo. The companies that do this well aren’t the ones who always pick build or always pick buy. They’re the ones who keep checking whether the decision they made still matches the world they’re actually operating in.