Cleo is built by one person. I say that not as a badge of honour but as a fact that shapes every decision. There is no backend team. No design team. No DevOps. No QA. One person, a code editor, and AI tools that have fundamentally changed what "one person" means.
I want to be specific about what this looks like in practice, because most of the discourse around AI-assisted development is either breathless hype or dismissive scepticism. The reality is more interesting than either.
What Changed
Before AI coding tools, a solo developer building a full marketing platform would be a multi-year project. Not because any single piece is hard, but because the surface area is enormous. Authentication, billing, real-time streaming, email sending, ad platform integrations, content generation, document editing, analytics dashboards, onboarding flows, notification systems. Each of these is a week of work minimum. Together they are a year.
With AI assistance, the bottleneck moved. Writing code is no longer the slow part. Deciding what to write is.
I spend most of my time on architecture and product decisions. Which integration to build next. How the data model should work. What the user experience should feel like. The implementation, once decided, happens fast. A new service class that would have taken a day takes an hour. A new UI component that would have taken half a day takes twenty minutes. Not because the code is worse. Because the patterns are established and the AI follows them consistently.
What Did Not Change
Debugging is still hard. The AI can write a service class that follows every pattern in the codebase, but when that service interacts with a third-party API that returns unexpected data at 2am, you are still the one reading logs and tracing the problem.
Architecture decisions still require taste. The AI can implement any pattern you describe. It cannot tell you which pattern is right for your situation. It does not understand your users, your constraints, or the subtle reasons why one approach will create maintenance problems six months from now.
Shipping still requires discipline. Having the ability to build features fast creates its own trap. You can build everything, so you want to build everything. The hardest skill is not building faster. It is choosing what not to build. That discipline is harder when building is cheap, not easier.
The Development Model
Here is how a typical feature ships.
I start with a clear specification. Not a ticket in a project management tool. A mental model of what the feature does, how it fits into the existing system, and what the edges look like. This is the part that takes the most time, and it happens before any code is written.
Then I describe the implementation. I have accumulated a significant set of rules, patterns, and conventions that the AI follows. Naming conventions. Error handling patterns. Security requirements. Design system tokens. Database query patterns. These are not suggestions. They are constraints. The AI works within them, and the result is code that looks like it came from a single author with strong opinions. Because it did.
I review everything. This is non-negotiable. The AI writes code that is usually correct. "Usually" is not good enough for authentication flows or billing logic. I read every line of every service class. I trace the data flow. I check the edge cases. The AI accelerated the writing. I still own the thinking.
Then I test in production with real data. Not because I skip testing, but because the interesting bugs are never the ones unit tests catch. They are the ones that emerge from real user behaviour, real API responses, and real data shapes that the development environment never produces.
The Honest Assessment
This model has real advantages. Speed is obvious. I shipped 73 sprints in three months. The codebase has roughly 300,000 lines of production code. TypeScript strict mode, no any types, structured error handling throughout. A traditional team of five could have produced similar output in a similar timeframe. I did it alone.
But there are disadvantages too. There is no second opinion in the room. When I make an architectural mistake, nobody catches it until it surfaces in production. I have no QA engineer finding the edge case I did not think of. I have no designer pushing back on a layout that works but does not feel right. The AI can fill some of these gaps, but not all of them. It is excellent at following patterns. It is not excellent at questioning premises.
The other disadvantage is knowledge concentration. If I step away from this project for a month, there is no team that continues shipping. The documentation is thorough and the codebase is clean, but the context lives in one person's head. This is a risk I manage by writing everything down, but it is still a risk.
What I Would Tell Other Solo Builders
First, invest in your rules early. The AI is as good as the constraints you give it. If your codebase has no conventions, the AI will write inconsistent code. If your codebase has strong conventions, the AI will follow them and the output will be remarkably consistent. The time you spend writing rules pays for itself within the first week.
Second, do not skip the review. The speed advantage of AI-assisted development disappears if you ship bugs that take three days to debug. Read the code. Trace the logic. Check the security boundaries. The AI did the typing. You are still the engineer.
Third, choose your architecture for one. Multi-service microarchitectures, complex CI/CD pipelines, elaborate branching strategies: these are coordination tools for teams. If you are alone, optimise for simplicity. One repo. One deployment target. One branch that matters. The overhead you save on coordination goes directly into building features.
Fourth, know when to stop. The ability to build fast does not mean you should build everything. A product with ten polished features beats a product with fifty half-finished ones. Shipping fast is a tool. Taste is the thing that makes the tool useful.
The Part Nobody Talks About
Building alone is quiet. There is no standup. No Slack channel buzzing with activity. No pull request reviews that turn into design discussions. Just you, the code, and the thing you are trying to make.
Some days that silence is productive. You can hold the entire system in your head, make a decision, and execute it in a single sitting without waiting for consensus or approval. That flow state is where the best work happens.
Other days the silence is the problem. You second-guess a decision because there is nobody to confirm it. You wonder if the approach you chose is the right one. You ship something and the feedback loop is just you, refreshing logs.
This is not a complaint. It is the reality of building something alone, and I think anyone considering this path should know what it actually feels like. The AI makes you faster. It does not make you less alone.
The work is worth it. But it is work.