When to Build vs Buy in AI (My Edition)

I've gotten this wrong before.

Not in a small, low-stakes, "oops we picked the wrong software" kind of way.

In a way that cost me a year of my life, hundreds of thousands of dollars, and nearly killed a business.

So when I tell you the build vs buy question in AI is the most important decision a founder can make right now, I'm not being dramatic.

I'm speaking from the scar tissue.

The Year I Built What I Should Have Bought

I was running a B2B fintech product. SaaS pricing. Paying customers. Real revenue.

The product worked.

And I kept building.

More features. More tools. More automation. More custom infrastructure. Every time a customer needed something, my instinct was to build it ourselves. We're technical. We can do it better. We'll own the whole stack.

So we built payment processing tools. Document analysis. Custom workflows. Internal dashboards. Automation pipelines.

We kept layering capability on top of capability because that's what founders do. You build.

Then the support tickets started piling up.

Not a few. A flood. Every edge case, every integration hiccup, every confused user — they all came to me. Not a support team. Not a help desk. Me. The founder.

Because we'd built so much surface area that maintaining it had become a full-time job on top of the full-time job of actually running the company.

I remember the week it clicked.

I was buried in support requests. I hadn't shipped a feature in weeks. I hadn't thought strategically in longer than that. I was sitting there debugging a payment edge case for a customer paying us less per month than it cost to serve them.

And I realized: this isn't a tech company.

It's a service business wearing a SaaS price tag.

It had been this all along. I just couldn't see it because I was too deep inside it.

Every feature we'd built had created a new surface to maintain. Every custom tool had created a new thing that could break. We hadn't built a moat.

We'd built a cage.

Then AI hit. And almost everything we'd spent a year building — the document analysis, the automation, the smart routing — went from "our competitive advantage" to "a feature anyone can add with an API call" in about six months.

We killed the product. Not because the market disappeared. Because the moat did.

And honestly? By the time we killed it, I was relieved. We'd been drowning in the thing we built.

Then I Made the Opposite Mistake

After that, I swung hard the other direction.

Buy everything. Use every managed service. Don't build anything you can outsource. Stay lean. Stay fast.

This wasn't even my first time learning this lesson.

A few years before the SaaS, I was running a quant trading operation. We'd built our backtesting infrastructure on top of Zipline — an open-source tool created by a company called Quantopian.

Quantopian was respected. Well-funded. Popular in the quant community.

Building on Zipline felt like the smart choice. Why build your own backtesting engine when a good one already exists?

Then one month, Quantopian shut down.

The whole company. Gone.

The repo was still open source, technically. But "open source" doesn't mean "works."

The Python environment dependencies started breaking almost immediately. Package conflicts. Version mismatches. Things that had worked fine under Quantopian's maintenance started failing in ways that were genuinely hard to diagnose.

We put four engineers on it. Full-time.

Weeks went by. Then months.

Four engineers. Full-time. And we still couldn't get it stable.

This was before AI could help with debugging. Before you could paste an error into Claude and get a working fix in thirty seconds.

We were doing it the old-fashioned way — reading stack traces, hunting through GitHub issues, trying to patch a codebase nobody was maintaining anymore.

Months of engineering time. Nothing shipped. Nothing traded. Nothing earned.

All because we'd built our core workflow on top of someone else's tool and assumed they'd always be there.

That was the first time I learned what happens when you buy without an exit plan. You don't just lose the tool. You lose the time it takes to replace it.

And if it's core to your operation, that time can kill you.

Same Lesson, Both Directions

Two mistakes. Opposite directions.

Building too much buries you. I built a SaaS with so much surface area that I stopped being a founder and became a support desk.

Buying too deeply traps you. I built a trading operation on someone else's tool, and when that tool died, we spent months trying to resurrect it instead of trading.

Building too much wastes your time slowly. Buying too deeply takes it all at once.

Both cost me the same thing in the end. Not just money. Time. Months and years I can't get back.

The question isn't build or buy.

It's: what do I need to own to stay free?

How I Think About It Now

I don't have a 2x2 matrix. I have one question I run every decision through:

Will this still be mine — and still matter — in 12 months?

If yes, build it.

If no, buy it.

If I'm not sure, buy it with an exit plan.

What I Build

My own AI training pipeline.

We rent GPUs directly from providers. We run our own training jobs. We manage our own checkpoints and data.

More work than using a managed AI platform. Significantly more.

But it means we're not locked into anyone's ecosystem. If a better GPU provider shows up tomorrow, we switch. If a cheaper model architecture emerges, we adopt it.

I build this because I've lived the alternative — twice. Once building too much of the wrong things. Once depending too deeply on someone else's platform. The training pipeline is core to what we do.

If Quantopian taught me anything, it's that you don't outsource the thing your business runs on.

My distribution.

Content. Audience. Relationships.

Nobody can take my YouTube channel. Nobody can deprecate my email list. If every platform disappeared tomorrow, I'd still have direct relationships with the people who matter.

Distribution compounds permanently. I will never outsource it.

My data infrastructure.

Where our data lives, how it's stored, what format it's in. PostgreSQL. Open file formats. Portable storage. Nothing proprietary.

Not glamorous work. But when we needed to move between cloud providers and it took a month with three developers, the lesson was clear.

Own your data layer or pay for it later.

What I Buy

AI models for general tasks.

I call Anthropic and OpenAI directly for things that don't need to be custom. Content assistance. Analysis. Code generation.

These models are better than anything I could build. They improve every quarter. And the switching costs are low if you use an abstraction layer.

I don't build general-purpose AI. I buy it. And I make sure I can swap providers in an afternoon.

Commodity infrastructure.

Servers. Storage. Databases. I use AWS and Google Cloud for the boring stuff — infrastructure that's interchangeable between providers.

I rent computing power from people who are better at running data centers than I'll ever be.

Specialized tools I'd only use 5% of.

Accounting software. Payment processing. Email delivery. Anything where the tool is mature and the market is competitive.

The SimpleDirect experience taught me what happens when you build things that should be bought. You become a maintenance company. If it's not core, buy it and move on.

What I Buy With an Exit Plan

This is the category most people forget.

The things that are smart to buy today but could become a problem tomorrow.

I think about this more than the other two categories combined. Because this is where Quantopian lived. A perfectly reasonable buy decision that turned into a months-long disaster when it disappeared.

Cloud services beyond basic infrastructure.

We use some Google Cloud and AWS features that go beyond commodity compute. Monitoring. Managed databases. Container orchestration. They save us time.

But we document how to replace each one. If any service we use disappeared tomorrow — like Quantopian did — we need to know how long it takes to replace and what the fallback is.

If the answer is "we'd be stuck for months," that service is too deep. We either find an alternative or build a thin version ourselves.

Third-party AI tools in our workflow.

Some of the tools we use daily will get acquired, deprecated, or priced out of reach.

This isn't paranoia. It's happened to me.

So every tool that touches our core workflow gets one question: what happens if this disappears in 90 days?

The tools that survive that question, we keep. The ones that don't, we start planning around.

The Rule That Ties It Together

Here's how I think about what AI can and can't replace. Five layers:

Identity — AI can't be you.

Relationships — AI can't text your lawyer.

Stakes — AI doesn't take risk.

Selection — AI can't decide what matters.

Accountability — AI isn't responsible when it goes wrong.

Build vs buy maps directly onto this.

If it's in one of those layers — if it requires your identity, your relationships, your judgment, your risk, or your accountability — build it. Own it. Never outsource it.

If it's below those layers — execution, processing, tooling, infrastructure — buy it. Buy the best version. Switch when something better comes along.

Build the part that's actually you. Buy the rest without getting trapped.

Why the Stakes Are Higher Now

I used to think build vs buy was a technical decision. Architecture diagrams. Cost comparisons.

It's not.

It's an identity decision.

What you choose to build is a statement about what you think makes you valuable. And in AI, where the landscape shifts every few months, getting that wrong doesn't just cost you money.

It costs you time.

And time is the one thing a founder can't get back.

I spent a year building features that became commodities. I spent months trying to resuscitate an abandoned codebase. Both mistakes taught me the same lesson from different directions.

Build what's yours. Buy what's everyone's.

And never, ever confuse the two.

Where I Am Now

Today my stack looks like this.

I build my own AI training pipeline, my own data infrastructure, and my own distribution.

These are the things that make my company mine. They're scarce. They compound. They can't be commoditized.

I buy AI models from Anthropic and OpenAI. I rent servers from cloud providers. I use off-the-shelf tools for everything that isn't core.

It's not a permanent answer.

Six months from now, something I'm building might become a commodity. Something I'm buying might become a lock-in risk.

So every quarter, I ask myself the same questions.

What can AI do better now? Kill it.

What still requires me? Double down.

What am I building that's about to become a buy? Let it go before it buries me.

What am I buying that's about to trap me? Get out before it's Quantopian all over again.

That's not a framework. It's a practice.

And in a world that moves this fast, a practice is worth more than a strategy.