We Built a Production-Ready Product in Five Weeks With One Developer and AI Agents.

We Built a Production-Ready Product in Five Weeks With One Developer and AI Agents. Then We Paused It. Here’s What We Learned.

An honest account of what happens when an ambitious AI-native approach meets real-world domain complexity.

We almost didn’t publish this.

Not because the story is embarrassing but because most companies don’t talk about projects that pause. They publish case studies about things that shipped, clients that stayed, metrics that moved in the right direction.

We decided to write this anyway. Because we learned more from this project than from most of our successful ones. And because the lesson is specific enough to be actually useful — not just “failure teaches you things” but “here is exactly what we got wrong and what we’d do differently.”

The Project

The German Battery Energy Storage Systems market has a specific problem: investment decisions are made with Excel spreadsheets and emailed models. Teams modeling NPV/IRR scenarios across multiple projects, comparing energy market forecasts, tracking capacity prices by TSO — all of it fragmented, manual, and slow.

Our client needed a B2B SaaS platform to replace this. Live market data from German TSO and ENTSO-E sources. Multi-tenant architecture with org-level isolation. Investment modeling workflows with scenario comparison. A regulatory differentiator built on per-TSO capacity distribution calculations that no competitor currently offers.

And they needed it built by a single developer working with AI agents.

We were genuinely excited about this. It was exactly the kind of project we’d been building toward a real domain problem, a client willing to try a non-standard approach, and a chance to see how far AI-native development could actually go in a complex B2B context.

What We Actually Built

Five weeks. One Senior developer. AI agents as the execution partner.

167 commits. Zero architectural drift.

The foundation of the build was a file we call CLAUDE.md — an architectural rulebook that captured every decision, constraint, and rule governing how agents operated within the codebase. Before an agent touched the project in any session, it read this file. Architectural intent was locked before generation began.

The result was a production-ready multi-tenant SaaS: six years of ingested German market data, full investment workflows, regulatory computation pipeline with auditor-ready documentation, and a dark-theme design system built for the specific visual language of energy market data.

This part worked. The architecture held. The speed was real. One developer with AI agents delivered what would previously have required a team and delivered it coherently, without the rework that typically follows fast development without oversight.

We were confident. And then we hit the part of the project we hadn’t fully scoped.

Where It Got Hard

The platform’s core value proposition wasn’t just displaying market data. It was forecasting — giving BESS investment teams accurate multi-year projections of energy prices, capacity revenues, and NPV/IRR outcomes under different market scenarios.

This is where we hit a wall.

Accurate energy market forecasting for the German BESS market requires a specific type of domain expertise: understanding how weather conditions, industrial demand patterns, regulatory frameworks per TSO, and grid dynamics interact to produce the numbers that matter. Getting the formula right isn’t a software problem. It’s a domain knowledge problem that people spend years at university learning.

Our business analyst was excellent. But the forecasting methodology required more domain depth than one BA could close in the project timeline the client had planned for. We had partial data — some from AI, some from industry expert consultations but not the complete dataset the model required.

The agents got stuck in loops trying to fix calculation logic that was fundamentally constrained by the data available. We spent more time diagnosing why the numbers didn’t match reality than building forward.

The project is currently paused.

What This Experience Changed for Us

When we look at new projects now, we ask questions we didn’t ask with the same rigor before this one.

The first is about data. Not “do you have data” but “do you have the specific data the forecasting model requires, and do you know what that data is.” These are different questions. A client can have access to six years of market history and still be missing the input variables that make a prediction model reliable.

The second is about domain methodology. Before this project, we treated domain expertise and software expertise as parallel tracks that could run simultaneously. We now know they’re sequential in certain contexts. If the methodology isn’t correctly specified before development starts — and correctly specified means validated by someone who has built similar models before — then fast, well-structured development gets you to the wrong answer efficiently.

The third is about what AI agents can and can’t do. An agent amplifies a person who knows what they’re doing. It cannot substitute for knowledge the team doesn’t have. When the human side of the equation is operating with incomplete domain knowledge, the agent executes that incomplete knowledge efficiently — arriving at the wrong answer faster and more consistently than a confused human would.

We now treat these as three separate readiness checks before we start any project involving complex domain logic: data readiness, methodology readiness, and team expertise readiness. All three have to pass before development begins.

What We’d Do Differently

The development approach was right. The architecture was right. What we underestimated was the depth of specialized knowledge required to define the forecasting model correctly before code started.

For a project at this intersection of finance, energy markets, and regulation, the discovery phase needed a domain expert alongside the BA — not a developer who could research the domain, not an AI that could approximate it, but someone who has built these models before and knows where the edge cases live.

The two problems were separable. We treated them as one. The platform architecture and the forecasting methodology are different problems requiring different expertise. We staffed correctly for one and not the other.

Our developer’s conclusion: the model of one or two developers with AI agents remains valid for projects where the data is structured and the domain logic is definable. For projects where the methodology itself is contested territory where experts disagree on inputs, where the derivation requires years of specialized experience — you need that expertise on the team before agents touch the codebase.

What This Confirms

The CLAUDE.md approach kept architecture consistent across 167 commits. That’s validated.

What it couldn’t do and what no architectural rulebook can do — is compensate for a forecasting methodology that wasn’t correctly specified to begin with. Consistency is a problem AI-native development solves well. Domain methodology is a problem it cannot solve. Those are different problems and they need to be treated as such.

We built something real. The platform exists, the architecture is sound, the data pipeline works, and the investment workflows function. The forecasting model — the part that required domain expertise we didn’t have at the depth required — is what paused the project.

The Broader Point

Every company that works seriously with AI agents will eventually run a project like this one. A project where the technical execution went well and the domain knowledge gap was the limiting factor. Where the agents did exactly what they were asked and the result still didn’t match reality, because what they were asked to do was built on an incomplete foundation.

The lesson isn’t that AI-native development fails in complex domains. It’s that AI-native development succeeds in complex domains when the domain knowledge is on the team — not approximated, not researched in parallel with development, but genuinely present before the first architectural decision is made.

We’ll do this kind of project again. We know more about how to staff it now.

Wamisoftware has been building software products since 2014. We work with senior engineers and AI agents on projects where the quality of what gets built matters as much as the speed at which it gets built.