Solo founders don't fail because their code is slow. They fail because they can't stop switching modes.
Dario Amodei said publicly he gives 70-80% odds that 2026 produces the first solo unicorn — a single-person company hitting a billion-dollar valuation. The evidence is coming in fast. Matthew Gallagher launched Medvi, a GLP-1 telehealth startup, from his LA home in September 2024 with $20,000 and no employees. In its first full year, it generated $401 million in revenue across 250,000 customers. He used Claude and ChatGPT to write most of the code. He used Midjourney and Runway for ad creative. Two people built a company doing the revenue of a mid-size healthcare firm.
This gets reported as an AI story, which it is. But the productivity insight that made it work is subtler than "AI makes you code faster," and it matters enormously for the thousands of solo developers who will try to build something like this and won't make it.
What Gallagher Actually Did
Medvi didn't succeed because Gallagher wrote code at 10x speed. It succeeded because he collapsed the number of domains he personally operated in.
The telehealth industry's hard problems — medical compliance, prescribing oversight, pharmacy logistics, shipping — are not coding problems. They are regulatory and operational problems that take years and millions of dollars to solve from scratch. Gallagher didn't solve them. He outsourced them entirely to CareValidate and OpenLoop Health, which handle the doctors, pharmacies, and compliance infrastructure as third-party services.
What remained was a domain he could actually own: the product surface (software, UX, checkout flow), the marketing (ads, creative, copy), and the customer experience layer. AI meaningfully accelerated all three of those. But the reason AI could accelerate them is that those were the only three domains on his plate.
That's the actual insight. Not faster code. Fewer domains.
The Trap Most Solo Builders Fall Into
The way the solo unicorn narrative gets absorbed: "AI makes every task faster, so I can do everything."
That's the wrong lesson. Doing everything faster is not the same as doing fewer things. And the gap between them is where most solo founders get destroyed.
Here's what "doing everything" looks like on a Tuesday for a solo developer building a B2B SaaS:
Write a feature (engineering mode). Answer three support tickets (empathy mode). Make a call to a prospective user (sales mode). Update the pricing page based on what you learned (marketing mode). Fix a bug from last week that surfaced in prod (debugging mode). Write a changelog post (writing mode).
AI compresses each of those individually. You can draft a support reply faster. You can push a bug fix faster. You can iterate on ad copy faster.
What AI does not compress is the switching cost between them. Engineering mode requires working memory loaded with data flows, edge cases, and architectural constraints. Support mode requires empathy and user context. Sales mode requires a different kind of listening. Each mode takes meaningful time to enter, and leaving it before you've done deep work is a waste of the entry cost.
A developer on a team rarely operates in more than one or two modes in a given day. A solo founder operates in all of them, often in the same two hours.
The Compounding Problem
There's a dynamic here that compounds in a direction most people don't see until it's already happened.
When AI makes each individual task faster, the natural response is to expand scope. If you can write support replies 3x faster, you can handle 3x more user conversations. If you ship features faster, you can promise users more. The surface area of your work expands to fill the capacity AI creates.
This is identical to the workload creep dynamic documented in team environments — faster throughput creates more demand rather than more slack — but it's worse for solo founders because there's no team to absorb the expansion. Every new domain you take on is another mode you personally have to switch into. The raw output metrics look great as this happens. Features shipped, conversations handled, tasks closed. The underneath signal — how often you're entering and exiting different cognitive registers in a single day — drifts quietly in the wrong direction.
The founders who sustain this for years don't do it by getting faster at all the modes. They do it by cutting the number of modes they personally inhabit.
What to Track If You're Building Alone
If you're a solo founder and you're measuring your own work, the most useful signal isn't coding hours or commits or tasks closed. It's how often your engineering blocks are contaminated by non-engineering work.
How many times in a four-hour coding block did you switch to support, marketing, or ops mode? If the answer is more than two or three, the block probably produced a fraction of what it looked like in your task manager. The entry cost for deep engineering work is 20 to 30 minutes. Every mode switch resets that counter.
The second signal is engineering hours as a fraction of total work hours. Most solo founders think they're spending a lot of time coding. When they track it explicitly, the support, ops, and marketing work fills more of the week than expected — because it's always-on, always urgent, and doesn't feel like "work" in the same way that a feature branch does. Knowing the actual ratio helps you make a real decision about whether to outsource a domain (like Gallagher outsourced the medical compliance layer) rather than treating every task as equally worth your time.
The Constraint Didn't Change
The solo founder moment is real. Medvi is real. The evidence for Amodei's prediction is piling up.
But the founders who are actually making it aren't succeeding because AI removed the productivity constraints of building alone. They're succeeding because they understood the constraint clearly and designed around it. The constraint was never coding speed. It's always been attention — specifically, how many cognitive modes you have to inhabit personally versus how many you can collapse, outsource, or eliminate.
AI is an extraordinary tool for compressing work inside a domain. It is not a solution for operating across too many domains at once. That distinction is the whole game.