Historical account — October 11, 2026: These are the two mistakes I described on April 7: building too much support surface and depending on an abandoned workflow without a tested exit. Stack choices and quarterly practices below describe that period. For a current decision record, use Review a business decision; record the fallback, access requirements and actual recovery result instead of assuming portability.
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 one decision I now take seriously, 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 decided to sunset that business strategy because I believed its moat had weakened, rather than because the market disappeared.
And honestly? By the time we made that decision, I was relieved. We'd been drowning in the thing we built.
Author chronology clarification — October 11, 2026: The clarified Chapter 6 account says the decision to sunset SimpleDirect’s fintech business was made around December 2025, the official pivot happened around June 2026, customers were given two years to transition, and the app remains available and online. The strategic decision described here is not an immediate December service shutdown or an independently measured guarantee of operational health.
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 today’s coding assistants could help suggest fixes; a suggestion would still need testing in that environment.
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.
A YouTube channel depends on the platform’s rules. An exported email list and direct relationships reduce some dependence but still carry consent, delivery and provider obligations. If every platform disappeared tomorrow, I'd still have direct relationships with the people who matter.
I want to retain direct relationships and portable audience records, while recognizing that distribution can weaken or depend on providers.
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
I keep responsibility for the decisions and relationships that matter to me. That does not mean implementing every component myself.
For execution, processing, tooling and infrastructure, I compare buying with building and test the exit plan. A better option is useful only if the switch actually works for our workflow.
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. I regarded them as core in April, but their value and portability still needed regular review.
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.