Build, buy, or fix: the only three answers

Most technology decisions collapse into one of three answers. You build something that doesn't exist, you buy something that does, or you fix something that's already there and broken. Naming which one you're actually in is half the work, and it's the half most teams skip.

The trap is build. Build feels like progress. It's visible, it's fundable, it's the thing founders are wired to do. So a team that actually has a fix problem, a process that breaks, a pricing model that leaks, a system no one documented, reaches for a build, spends six months and a chunk of runway, and arrives back at the same problem with a new piece of software on top of it.

Three quick tests for which answer you're in. If the capability exists in the market and someone else maintains it better than you ever will, you're in a buy, so stop designing it. If the thing you need has never existed and the value is in it being yours, you're in a build, so commit fully. If you already have the thing and it just doesn't hold up, it stalls, it leaks, it lives in one person's head, you're in a fix, and no new system will save you until you do.

We worked with a mid-market operator who was certain the problem was the product. Every conversation was about what to build next. The real cause was two layers down: operations that ran on memory and a pricing model that quietly gave margin away. That wasn't a build. It was a fix. Once it was named correctly, the ceiling they'd been hitting for a year broke in a quarter.

The cost of the wrong answer isn't just the money. It's the year. Name the answer first.

Want to see which of your gaps are builds, buys, or fixes? The Readiness Scorecard tags each one in ten questions. Take the Scorecard