The first results were absolutely stunning. With Claude Code, I got a container-based web portal running in Azure with several environments, and I did almost nothing myself. Just a specification and a few prompts, and a little bit later it was live.
But that wasn’t the point of the exercise; the web is full of stories like this. I wanted to know how agentic coding works for large, complex enterprise applications. So I decided to take one of my personal pet projects and turn it into a full-blown SaaS application.
In this article, I want to share my Claude Code journey, from a naïve approach to a one-person-built enterprise application, and its impact on development results, architecture, and token consumption.
What I was Building
My personal pet project is rather simple. It’s a tool to use AI for deep technology research and comparison. I decided to turn it into a pretend SaaS offering. I added features that typically come in larger enterprise applications, so that my project became a web application with enough complexity to go beyond a convincing demo.
So, I added:
Sign-in, sign-up, subscription management, and an admin portal.
Billing and invoicing.
Business logic and data structures for the generation of technology assets.
Asynchronous background tasks and batch processing.
A container-based application hosted in Azure.
Multiple environments, continuous integration and deployment through GitHub Actions.
I wanted to explore what worked, where Claude’s subscription and context window limits became relevant, and what happened as both the codebase and the conversations grew.
My approach: give Claude room, then ask Claude to review
I used a naïve conversational approach with Claude Code. With the most expensive and capable model Fable 5.1 for convincing results, of course. I wanted to use it for both planning and coding. Just to see what comes out. Hey, money is not everything; results matter!
First, I asked Claude to write the specification. This worked smoothly – Fable broke the specification down into phases and slices for the implementation. The specification also defined business terms and entities so Claude would know how things relate to each other.
I gave Claude considerable freedom to choose the architecture and implementation.
Fresh Claude sessions reviewed the work done by other sessions. That separation was deliberate. A fresh session could examine the result without carrying the whole implementation conversation. However, it still depended on the code and documentation available to explain the system.
With my limited bandwidth, I concentrated on AI reviews rather than detailed human code reviews. This made the experiment useful for exploring a management question: how much confidence should we place in a development process where AI performs both activities?
The honeymoon was real
The results of the first slices and phases were really convincing. In no time, there was a feature-rich portal with automatic testing that would have taken weeks to build before AI. For UI design, Fable asked me to provide 3 websites that I liked and one that I didn’t like and made an awesome proposal.
The cloud provisioning worked smoothly. Fable set up the CI/CD pipelines with Bicep in GitHub Actions. It also anticipated advanced requirements and features upfront, like proper monitoring, auditing, and usage reporting, and built the infrastructure to support them.
When runtime errors occurred in the cloud, Claude was particularly impressive at investigating them. It was strong at finding root causes in cloud setup issues. It gave me clear instructions when I had to create external dependencies manually, like some DNS entries.
That success made it easy to keep extending the portal. Each additional feature looked like a manageable next step.
The difficulties emerged through accumulation.
What changed as the project grew
I noticed a few things as the codebase grew larger and larger.
First, Claude has a tendency to become very verbose. It produced a lot of text in chat responses and specifications. The more features I built into the portal, the more this became a challenge. At some point, it just was really overwhelming to follow the chat responses and understand the changes that Fable was proposing to build. With mental overload, there is also a risk that you accept what Fable proposes too quickly; everything sounded very convincing, after all.
Second, I noticed that Fable did not produce the most efficient code. And especially not the most maintainable code. Don’t get me wrong, the quality was still good. I would have created more separate modules and used different naming. The code worked.
But for mission-critical applications, code quality, proper architecture, and testability are essential in the long run. People say AI made code cheap. But for essential systems, the core parts need to be built with high quality in mind to meet future requirements. Cheap code comes back to bite you.
Parts of this might have been caused by inconsistencies in the specification. While the spec seemed crystal clear to me initially, every inconsistency I missed came back to haunt me later. Which is perfectly natural and, one might say, exactly like the past. But Fable’s convincing proposals make it easy to miss things. Suddenly, a feature refactoring leaves remnants across the application. You end up with input elements that are not needed and data that is not used.
Which brings me to the next issue: Because of verbose text and code, and an unclear architecture and module cut, the context window was quickly exhausted for features that affected larger parts of the system. Claude sliced the features in a way that each slice should run in a fresh session, retrieving the current state and tasks from the specification. With all the verbosity built into the application, the context window filled to more than 70 percent in no time, and Claude started recommending a fresh session. Therefore, the weekly Fable limits in the subscription kicked in quite early in the week (which might not be a bad thing to make you pause and think about what you are doing…). Conversations with Claude when you hit the session window limit remind me a lot of the Groundhog Day movie, where Claude says it will soon forget what we talked about today.
What I would take into a larger project
For engineering leaders, I see a few practical lessons.
1) You cannot “agentify” your system out of bad requirements. Continuously work on the quality of the specification. Invest time to get definitions, business terms, and entities right. This will make conversations with the AI much clearer and much more efficient. Consider domain-driven design approaches with the ubiquitous language approach to make sure everyone involved understands what is to be built.
2) Get the application architecture and the modules right. Agentic AI will be much more efficient when modules have clear purpose and interfaces. AI will be able to take care of the implementation inside them, with much more clarity and less verbosity.
3) Move forward in small steps. Tasks too big have a tendency to clutter your codebase or your specification. Do not rely only on AI-driven reviews and testing without control. These can help, but for the critical parts of a system, a human must be in the loop. Consider test-driven development. AI made code cheap, but human reviews are more expensive. Therefore, you’d better make sure pull requests are easy to digest.
My experiment taught me how quickly Claude Code could help build a substantial application. It also exposed how hard it is to maintain consistency and coherence while delegating both development and review.
So, what’s the gist of it? Use agentic development for critical systems, or rather, just rely on AI generating code snippets? Definitely agentic development. But to create high-quality software that lasts, a lot of human dedication on the outcome is still important.