There's a version of the "AI changes everything for solo founders" story that's mostly hype. AI writes your code so fast you ship in days. AI does your marketing. AI is your cofounder. This version is exaggerated in ways that will get you burned if you take it literally.
There's also a real version. The leverage is real. The limits are real. The discipline required to use it well is real and largely underdiscussed. This is what I've actually learned building Shoofly as a solo founder with Claude as a core tool in the stack.
What actually changed
The headline claim — that one person can now build what used to require a team — is partially true and needs qualification.
What changed: the execution cost of known tasks dropped dramatically. Implementing a feature you understand clearly, writing tests for code that exists, refactoring a module, building out documentation — these tasks are faster with a capable agent. Not 10× faster on every task, but meaningfully faster on the right tasks, compounding over time.
What didn't change: the thinking. Deciding what to build, figuring out why something is broken in a way that requires understanding your specific system, making calls about product direction, talking to customers — the parts of the job that require judgment about your specific context are not significantly accelerated by AI. They require your full attention and they still take the time they take.
The leverage is real. It's just not equally distributed across all the work.
The tools worth betting on
I'm going to give you the honest version of this rather than a comprehensive survey.
Claude Code is the core of my development workflow. Not because it's perfect, but because the hook system, MCP integration, and terminal-native design make it programmable in ways other tools aren't. I can build security policies, logging, notifications, and automation on top of it. It's a platform, not just an assistant.
Claude for thinking and drafting. Research, writing, working through problems — the conversational interface is genuinely better than the API for work that requires back-and-forth. I have a Claude Max subscription and use it heavily.
The Anthropic API for anything that runs automatically — the parts of the product that call Claude without me watching. The question of when to use the API versus a Claude subscription is worth thinking through carefully; the breakdown of API vs subscription covers when each model makes sense.
What I don't use: a dozen different AI tools for different tasks. The context fragmentation of switching between many tools erodes the leverage you gain. Pick a smaller set of tools you understand deeply.
The hidden cost: context management
This is the thing nobody talks about enough. The most expensive resource in a heavy AI workflow isn't money — it's managing your own understanding of what the AI has done.
AI makes it easy to accumulate a large, messy codebase faster than you can fully understand it. You can ship features quickly. You can also create a situation where you have production code that you don't deeply understand, that the AI wrote in a session you can't fully remember, with architectural decisions that made sense at the time but that you can't now reconstruct.
The discipline I've developed: nothing goes to production that I haven't read and understood at the level of understanding I'd need to debug it at 2am. This sounds obvious. It's surprisingly hard to maintain when the AI is producing plausible, functional code faster than you can absorb it.
Practical tactics: short sessions with clear scope, output files that accumulate decisions not just code, a personal log of the architectural choices made in each session.
What breaks when you're solo
No PR review. When you're solo, the AI writes the code and the AI reviews the code, which is less scrutiny than it sounds like. The AI's review is better than no review and worse than a thoughtful human reviewer. The gaps: anything that requires understanding business context, security implications specific to your domain, or edge cases the AI didn't think to check.
Build other review mechanisms. Tests are the obvious one. A structured checklist you run before merging is another. A forcing function that requires you to write a one-paragraph explanation of what changed and why.
No rubber duck. A lot of problem-solving happens by explaining a problem to someone else. The AI can play this role, and does it reasonably well for technical problems. It's less useful for problems that require someone to push back on your framing or ask questions you didn't know to consider.
Build the habit of writing down your problem before talking to the AI about it. The act of writing it out often surfaces the issue. When it doesn't, you have a cleaner problem statement to work with.
Scope drift. Without another person to sanity-check scope, it's easy to build in directions that feel productive but aren't. The AI is highly agreeable — it will enthusiastically help you build the wrong thing.
Maintain a list of what you're not building this week. Review it before each AI work session.
The production discipline that matters most
The single most important discipline I've developed: make every AI work session produce a written output beyond the code itself.
A one-paragraph summary of what was done and why. The decisions that were made. The things that were explicitly not done. This record is for future-you — the person who will be debugging something three months from now and needs to understand why the system is shaped the way it is.
The AI writes fast. Writing fast means decisions accumulate fast. Without a record, you're left with a codebase that represents a series of choices you can't fully reconstruct.
What I'd tell someone starting today
The highest-leverage thing you can do as a solo founder using AI: build clear working boundaries between what you'll let the AI do autonomously and what requires your active attention.
The autonomous zone: implementing clearly specified features, writing tests, refactoring code you've reviewed and understood, generating documentation, building routine infrastructure.
The attentive zone: architectural decisions, anything that touches auth or payments or sensitive data, decisions that close off future options, anything you'd be embarrassed not to understand deeply.
The mistake most people make is letting the autonomous zone expand gradually until important decisions are being made without sufficient scrutiny. The leverage is real and worth having. So is the discipline to keep the boundaries clear.
I build with Claude every day and write about what it's actually like to ship AI-powered products. Subscribe at shoofly.dev/newsletter — building AI products in the real world, not what the press releases say.