CLIENT CASE STUDY

No, definitely not. Throughout the process I was always working alongside the Technical Delivery Manager and the designer. We filled in the documents together - the screen map, the backend architecture, all of it. So it was still a human-driven process, just with BMAD agents helping at each stage.

After the first round of brainstorming, we stopped following the BMAD flow strictly and started calling specific agents when we needed them - the PRD agent, the user story agent, the architecture agent. We picked what we needed instead of running the full sequence every time.

We were using BMAD version 4 on ONYA. They’re up to version 6 now. But with version 4 we had to review everything carefully, give instructions to adjust when something wasn't relevant, and guide the agent back on track with the right information.

There was also a loop problem. You'd generate, review, generate, review - and along the way the agent would run out of tokens. So we had to keep tweaking the prompts to reduce token usage, and upgrading the models to get better quality output.

There was a real saving, but not 46%. The client added new features during development, and that pushed us over the original schedule and budget. The timeline grew from three to about five months, and the final cost ended up being higher. It still came in below a traditional development process estimate, just not by as much as we'd hoped going in.

The biggest issue was scope changes. Whenever the client added a new feature outside the original scope, we couldn't just drop it in. With BMAD, you have to go back and adjust several layers first - update the PRD, create new user stories, check the data relationships, and make sure the new user story doesn't overlap with existing ones. If there was overlap, we had to revise the related user stories too.

Once all of that was done, the developers still had to run the updated user stories back through BMAD and adjust any related features. We didn't track the cost of these scope changes separately during reconciliation, so I can't give you an exact figure - but this rework was one of the main reasons the final cost went above the original BMAD estimate.

It depends a lot on the client. With ONYA, the client had a really clear vision of what they wanted to build. And as Dito said, with BMAD you've got to lock in the PRD up front, because everything filters through from there.

If new requirements come in later, it's not a small change - you go back to the top and the whole thing has to flow through again. That works fine when the scope is stable. When the client is iterating in real time, it's painful. With Figma, a developer can look at a few screens and a couple of buttons and just build it. With AI, you can't give it a rough PowerPoint and say "build that." It will build something - and it'll look impressive - but it probably won't be what you actually wanted.

When the client locks in the scope during the scoping phase, the rest is straightforward with BMAD. People describe BMAD as a waterfall approach for AI development, and that's accurate -  it emphasises thorough upfront planning, documentation, and structured phases. If the client gives you that clarity at the start, BMAD rewards you for it. If they don't, it punishes you for it.

Most of them changed, except QA. BMAD does have a QA agent, but at the time we built ONYA we were still relying on human QA for visual checks. The biggest shifts were in the earlier phases - spec, design, and development all looked quite different from how we'd normally run them.

Yes - I think the scale of what BMAD can generate is the biggest thing I learned. It can produce so much. We even instructed agents to create things that aren't in the standard BMAD setup, like custom spec documents, and it handled them. That really changed how I think about what's possible.

It was challenging for the team. The graphic designer, for example - in our traditional process the designer’s main output is the wireframes. With BMAD they also have to produce a design system document, a UI guideline, and hand that to the project manager, who then passes it to the Technical Delivery Manager for the architecture step. So it changed who does what, and when. Everyone felt that pressure on the process.

But people also understood why we were doing it. AI is going to be big in the future, so we have to adapt.

Yes, we're on BMAD 6 for new projects now. For the moment, BMAD is still the strongest option we've found. But we'll keep looking - if a better framework appears we'll try it. The space is moving quickly.