The Architecture Trap: Why We Rebuilt Our Client’s System Three Times

What kept going wrong - and the planning approach that would have prevented it

There’s a particular kind of project failure that doesn’t look like failure while it’s happening. The team is working hard, the client is engaged, progress is being made. And yet somehow, months in, you find yourself rebuilding something you thought was already built.

We fell into this trap on a recent project. Not once, but three times.

The first version of the system was built on a reasonable platform for the brief as we understood it. Then two things happened simultaneously - and it’s important to distinguish between them, because they’re different problems with different implications.

The first was that seeing the system work gave the client better clarity on their existing process. Gaps in their workflow documentation surfaced. Stakeholders who had described the same process differently had to reconcile those descriptions into something the system could actually follow. That kind of requirement evolution is about understanding catching up with reality.

The second was something more interesting, and frankly more exciting: the working system revealed what was now possible. Processes the client had never considered automating suddenly became obvious candidates. Volumes they had never thought feasible became achievable. The brief they had given us at the start wasn’t wrong or poorly thought through - it was simply written before they knew what AI could actually do for their business. Once they saw it running, the ambition expanded considerably, and reasonably so. You can’t spec for possibilities you haven’t yet imagined.

Both forces were pulling the requirements outward at the same time, and the platform we’d chosen for the original brief couldn’t contain what the project was becoming. So we moved to something more capable. Then the scope expanded again, as real users interacting with a real system surfaced new requirements that no amount of upfront planning could have anticipated. By the third build, we were on infrastructure robust enough to handle what the project had grown into - which was considerably more ambitious than anything discussed at the outset.

Each rebuild was the right decision. The cumulative cost in time and stress was significant.

Here’s what I’ve come to understand about why this pattern is so common in AI projects specifically. When a business implements a new piece of software, they broadly know what software can do. AI is different. For most organisations, the first working implementation is genuinely the first time they understand what the technology makes possible for their specific business. That moment of realisation almost always expands what they want to do with it.

This isn’t a planning failure. It’s an inherent feature of implementing a technology whose full implications only become visible through use. But it does have real consequences for how projects should be structured.

The approach that would have served us better is one we’ve since adopted: treat the first build explicitly as a learning and discovery exercise, not a production system. Choose a platform that prioritises flexibility and speed of iteration. Build enough to generate real insight - both about process gaps and about the new possibilities the technology opens up - and then make architecture decisions informed by that insight rather than by the original brief.

For any CEO starting an AI implementation: if your requirements don’t expand once you see the first working system, you probably haven’t built something ambitious enough. The question isn’t whether your architecture will need to evolve - it will, and that’s a sign of success as much as anything else. The question is whether your project is structured to absorb that evolution without starting from scratch every time.

Have you experienced the architecture trap in your own technology projects - and how did you navigate it?