Post-Mortem: Building a Personal Website Using the BMAD Method

Using BMAD feels like playing one of those life simulator games. Only this one is text-based, and you play as a Software Architect or Product Owner. That’s the experience I had building my personal website with the BMAD Method.

During the design and specification phases, I acted as the lead architect. Once development began, I shifted to a Product Owner role and weighed in only when the process asked for a decision. What follows is what I learned.

The BMAD Method provides real guardrails that keep a project aligned with its specs, architecture, and design documents. Those guardrails come at a price, both in time and money. At the small scale of a basic personal website, the costs were already substantial. Based on my experience, there’s no reason to expect they shrink at larger scale.

What Is the BMAD Method

BMAD stands for Build More Architecture Dreams. It’s a harness for agentic coding that structures development around a spec-driven process. You define functional requirements as Product Requirement Documents, optionally go through a UX Design phase, and then break the work into epics and stories. The system cross-checks generated code against those documents throughout the process.

A key mechanic is the course correction. When the agent detects divergence from the specs, it asks you how to resolve it. You can update the documentation to reflect a new direction, or ask the code to align with the existing docs.

The BMAD Method has a website with more detail on the process. This article focuses on my experience using it, not on the method itself.

Building a Website with BMAD

I used BMAD 6.8, updating to 6.9 halfway through epic 2. The project is a basic Astro.js application rendering a static personal website with a blog, an about page, and a list of recommended reads from other authors.

It took me two weekends and at least eight hours before the first line of code was generated. That’s just the setup and specification work: defining requirements, architecture, and design, all before implementation began.

Once development started, subagents spawned by default. Telling BMAD not to use subagents when invoking the dev-story command did nothing in my testing. The consequence is a much higher bill if you prefer an expensive model for planning and design but want to switch to a cheaper model for implementation tasks. BMAD doesn’t make that easy.

Course corrections sometimes went into small implementation details. The agent’s questions had little context for someone who hardly reads code, which left two paths: approve and hope the outcome is correct, or invest time in understanding the codebase to make an informed decision.

Later, I created a new epic with five stories to overhaul the design based on an existing reference design. The result still didn’t resemble the reference. Telling the agent about everything that looked off became tedious, and it didn’t produce the result I wanted.

What BMAD Does Well

The spec cross-checking is the strongest part of the method. The system flags divergence between code and specs and asks how to resolve it. This gives the project guardrails that keep it on track. When decisions change mid-development, the process supports re-aligning documentation with reality.

I felt these advantages while working. For a complex project with multiple contributors or long development cycles, this kind of discipline could prevent significant drift.

The Costs

Token usage is extremely high. The dev-story command starts with approximately 95,000 tokens of context, and the context sometimes exceeds 200,000 tokens multiple times during a single story. All the specs consume input tokens, and keeping them updated after course corrections consumes costly output tokens.

Course-correcting the UX design, creating a new epic, and developing three stories cost $120 in tokens alone. That was using Claude Opus for planning and review, and Claude Sonnet for coding. Total token spend for the project was in the hundreds of dollars.

The process itself is time-consuming, independent of the monetary cost. Between specification, course corrections, and the subagent workflow, the timeline adds up.

There’s also the subagent problem. Because BMAD spawns subagents by default and doesn’t make it easy to assign them cheaper models, a planning-heavy flow locks you into expensive models for implementation as well.

I Was Too Hands-Off

My hands-off approach was probably to blame for some of the friction. I was mostly interested in outcomes and only looked at code when the agent asked for a decision. Even then, I often stated a desired outcome rather than an implementation preference.

I learned that some level of understanding of your codebase is necessary for successful spec-driven development. Just how little is enough to get by is unclear. But this time, I definitely knew too little about what was being generated.

Had I spent more time understanding the code, the results would likely have been better. But that time investment would have made an already heavy process even heavier. With BMAD, the total time spent on understanding the code plus managing the process didn’t yield enough benefit to justify the framework for this project.

For a basic personal website, a lighter framework or no spec-driven framework at all would likely have been the better choice.

Does This Get Better at Scale?

The core trade-off is guardrails versus cost. BMAD provides guardrails that keep the project aligned with its specifications, and it checks throughout every step whether the project is still within those guardrails. The cost is both monetary and temporal.

At small scale, the costs are already substantial. What’s less clear is what happens at larger scale. More features mean more specs, more stories, more course corrections, more context, and more tokens. The guardrails are arguably more valuable for complex projects, but they cost more there too.

Nothing in this experience suggests that BMAD becomes more efficient at scale, only more expensive.

I can’t rule out that I was simply using BMAD wrong. Maybe I held it to expectations it was never built to meet. After spending this much time on a project, it’s hard to judge your own setup fairly.

Conclusion

I took two things away from this experience.

First, BMAD’s guardrails are valuable, but their cost is structural to the method and likely to grow with project scope. There’s no reason to expect the method becomes more efficient at larger scale.

Second, understanding your codebase is necessary for successful spec-driven development, but the time that requires adds to an already heavy process. For this project, the total investment didn’t earn enough back. A lighter framework would probably have served me better, and for something this small, no spec-driven framework at all would have been faster.