I have a graveyard of SaaS subscriptions I paid for instead of building and custom tools I built instead of buying. Both kinds of mistakes cost me real money and real time. After enough of them, a pattern started to emerge in what made some decisions obviously right in hindsight and others obviously wrong.
The pattern is a three-part question, and it has nothing to do with cost or capability. It has everything to do with where your competitive advantage actually lives.
The Framework
Every capability your business needs falls into one of three buckets: build, buy, or borrow.
Build means you write the code, own the infrastructure, and maintain it forever. You do this when the capability IS your product or your core differentiation. If a competitor could get the same thing by signing up for the same vendor you use, it is not a competitive advantage.
Buy means you subscribe to a platform someone else built and maintains. You do this when the capability is necessary but not differentiating. Someone else does it better than you ever will, and your time is worth more spent on your actual product or service.
Borrow means you call an API, hire a contractor, or lean on open source for something you need right now but do not want to own long-term. You do this when the technology is moving too fast to commit, when you need it temporarily, or when the maintenance cost of owning it outweighs the value.
The decision tree is simple. Ask one question first: does this capability create competitive distance between me and everyone else? If yes, build. If no, ask a second question: is this a stable, well-solved problem that someone else has already productized? If yes, buy. If it is unstable, temporary, or evolving faster than you can keep up with, borrow.
Where I Got It Right
Morpheus, my personal AI agent, was a build decision. I looked at every off-the-shelf agent platform and none of them could do what I needed. I wanted an agent that reads my email, triages my inbox, manages my calendar, monitors my portfolio, reviews and contacts companies for potential investment, generates and pursues growth ideas, and operates across a dozen different systems with judgment calls baked in. That system IS the capability. No vendor was going to build it for me because the value comes from how deeply it integrates with my specific workflows. Building was the only option that made sense, and it has been one of the best decisions I have made this year.
CRM was a buy decision. I run a travel network with thousands of advisors. We need customer relationship management, but CRM is not what makes us different. Dozens of companies have spent billions of dollars building CRM platforms. I would be insane to think my engineering team could build something better than what already exists. We bought a platform (HubSpot), configured it, and moved on. That freed up resources for things that actually differentiate us (the agentic advisor operating system).
The borrow category is where I think most people under-invest. I use Tavily's API for web search, Ghost for publishing, and a handful of other services through their APIs. I do not want to build a search engine. I do not want to build a CMS. These are capabilities I need but they are changing fast enough that owning them would be a liability. If a better search API shows up next month, I can switch in an afternoon. If I had built my own, I would be stuck maintaining it while the market moved past me.
Where I Got It Wrong
The mistakes taught me more than the wins. I once bought a SaaS tool for something that was close enough to our core product that it should have been built in-house. The integration was always awkward. The vendor's roadmap never aligned with ours. We spent more time working around its limitations than we would have spent building the thing ourselves. Eventually we ripped it out and built it anyway, which means we paid twice.
I also built things I should have borrowed. Early in Morpheus, I spent time writing custom code for problems that had perfectly good API solutions. The code worked, but maintaining it became a tax on every future feature. When I replaced those pieces with API calls, development velocity jumped because I stopped carrying weight that was not earning its keep.
The Trap Most People Fall Into
The research backs this up. HatchWorks published a framework this year arguing that the build-vs-buy question has shifted to "own vs. orchestrate." I think that framing is exactly right. Gartner says 73% of enterprises will have AI in production by end of 2026, and the companies getting burned are the ones building commodity infrastructure instead of buying it and building differentiating capabilities instead of buying those too.
The trap is ego. Engineers want to build. Executives want to own. Neither impulse is wrong on its own, but both become expensive when applied to the wrong problem. The discipline is in being honest about what actually differentiates your business and what is just infrastructure that needs to work.
I think about it like a restaurant kitchen. A great chef builds their own menu, their own flavor profiles, their own techniques. They do not build their own oven. They do not grow their own wheat. They buy the equipment, source the ingredients, and pour their creative energy into the thing that makes people come back.
How to Use This
Next time you are evaluating a capability, run it through three filters:
First, is this where our competitive advantage lives? If you removed this capability and replaced it with an off-the-shelf alternative, would customers notice? Would competitors be able to replicate your offering? If the answer to either is yes, build it.
Second, is this a solved problem? If the market has mature, reliable options and the capability is not differentiating, buy it. Your time and talent are better spent elsewhere.
Third, is this temporary, fast-moving, or peripheral? Borrow it. Use APIs, contractors, and open source. Stay light. Stay flexible. Commit only when you have enough information to know which bucket it actually belongs in.
The most expensive mistake is not picking the wrong option... it's never asking the question.
Keep building,
– JW
