The BMAD Method: A Structured Approach to AI-Assisted Development

I run 17 active software projects. They range from a Laravel personal website with a Filament admin panel to a cross-platform PyQt6 desktop app for OCR receipt extraction, a Flutter health-export tool, a trading dashboard, a Telegram-first grocery pipeline, and several internal automation tools.

For two years, I worked with AI coding assistants on all of them. The experience was useful but frustrating. Every session was a fresh start. The AI had no memory of the project's architecture, no context on past decisions, and no framework for prioritizing work. I would say "add a health dashboard" and get working code — but the wrong architecture, wrong data model, wrong API routes. The AI was fast, but directionless.

Then I adopted the BMAD Method, and everything changed.

What BMAD Is

BMAD stands for the Breakthrough Method for Agile AI-Driven Development. It is an open-source methodology — the repository lives at github.com/bmad-code-org/BMAD-METHOD — that provides a structured workflow for building software with AI agents.

The core insight is simple: AI coding assistants are excellent at implementation but terrible at planning. They do not know what you do not tell them. They do not understand your domain conventions. They do not remember last session's decisions. BMAD formalizes the before and between of coding — the thinking, documenting, and decision-making that turns a prompt into a well-architected feature.

The Four Phases

BMAD breaks development into four phases, two of which happen entirely before a single line of code is written.

Phase 1: Analysis (Optional)

Research, brainstorming, and product briefs. For new projects, this phase answers the question "should we build this at all?" For feature additions, it is a quick domain check: what data sources exist, what are the constraints, who is the user.

I use this phase sparingly — typically only for features that touch external systems or regulated data. When I added Health Connect export to my Flutter app, Phase 1 involved reading the Android Health Connect API docs, checking the health package compatibility, and writing a one-page brief on the data types and permissions model. The brief caught two permission issues before I wrote a single Dart line.

Phase 2: Planning (Required)

Every feature starts here. The AI writes a PRD (Product Requirements Document) to _bmad-output/planning-artifacts/prd.md. Not a corporate novel — a focused 1-3 page spec that covers:

• Problem statement and vision
• Data sources and integration points
• User stories (what success looks like)
• Technical constraints (stack, deployment, authentication)
• Open questions for the product owner (me)

I review the PRD, answer the questions, and either approve it or send it back with changes. This is the single most valuable step in the entire methodology. It costs me 5 minutes of reading and forces the AI to clarify scope before either of us commits to a direction.

A real example: when I asked for a meal planner feature on my website, the AI's first draft proposed a drag-and-drop calendar with recipe recommendations and nutritional tracking. A 3-day feature. The PRD surfaced that I only needed a weekly grid with text fields and a generated grocery list. Two hours, not three days.

Phase 3: Solutioning (Required for Larger Features)

Architecture design and work breakdown. The AI writes two documents:

• Architecture (architecture.md): data flow diagrams (text-based, no UML nonsense), database schema with typed columns and indexes, API routes, frontend component tree, and dependencies to install.
• Epics and Stories (epics-and-stories.md): the feature is decomposed into independent deliverable increments, ordered by foundation first (database, parsers, API) then surface (frontend, notifications).

Across 17 projects, BMAD has generated 37 planning artifacts. Every one of them saved me at least one mid-implementation pivot.

Phase 4: Implementation

Finally, code. The AI builds epic by epic, story by story, following the work breakdown from Phase 3. Each story starts a fresh AI session — no context bleed between unrelated pieces of work.

After each epic, a lightweight retrospective captures what went wrong and what to do differently next time. The lessons accumulate. The AI gets better at working in my project specifically.

The Real Difference

Before BMAD, working with an AI assistant felt like pairing with a brilliant junior developer who had never seen my codebase before. Every session started with explanation. Every conversation rehashed the same architectural decisions. The AI was fast but required constant steering.

After BMAD, the AI knows the project. It reads the PRD, the architecture doc, the AGENT.md (a compact project overview I keep at every project root), and the accumulated retrospectives. When I say "add a grocery list export feature," the AI already knows the data model (it designed it in Phase 3), the API conventions, the deployment target (DreamHost shared hosting), and the CSS framework (Tailwind v4 with OKLCH colors and specific design rules).

This is not theoretical. The BMAD artifacts grow with the project. The same AI session that writes the PRD for a new feature also reads the architecture decisions from the last three features. Consistency compounds.

The Numbers

17 projects. 37 planning artifacts. Hundreds of saved hours.

But the metric I care about is simpler: the number of times I have to say "no, that is the wrong architecture" dropped from multiple times per feature to nearly zero. The PRD and architecture review catch the mistakes before they are embedded in code. Re-reading a one-page spec takes five minutes. Rewriting a misarchitected feature takes an afternoon.

When It Works and When It Does Not

BMAD shines on features with clear scope and multiple independent parts — exactly the kind of work that benefits from a structured plan before execution.

It is overkill for one-line bug fixes. For those, BMAD defines a fast track: skip the architecture, write a mini-spec directly in the PRD, implement immediately.

It also depends on the AI agent respecting the methodology. This is not automatic — you need an AI agent configured to read BMAD artifacts, write new ones to the correct directories, and follow the phase sequence. I enforce this through skill files that load the BMAD workflow at the start of every session. The AI does not get to skip steps.

What I Would Do Differently

Start sooner. For the first six months of AI-assisted development, I treated the assistant as a faster Stack Overflow — ask a question, get code, paste it in. The result was a collection of features that worked in isolation but accumulated technical debt in their interfaces. A structured methodology from day one would have saved significant refactoring.

Also: version control the planning artifacts. The _bmad-output/ directory lives in every project's git repository. When I revisit a project after three months, the thinking behind every architectural decision is documented and committed alongside the code. No more "why did we do it this way?" conversations.

Conclusion

AI coding assistants are extraordinary tools for implementation. They write correct, idiomatic code faster than any human. But without structure, they produce fast wrong code instead of fast right code.

BMAD provides the structure. It formalizes what good teams already do — think before building, document before coding, review before committing — and makes it work in the context of AI-assisted solo development. The methodology costs minutes per feature and saves hours. The compound effect across 17 projects is the difference between a pile of working scripts and a coherent software ecosystem.

Full methodology and tooling: github.com/bmad-code-org/BMAD-METHOD

Written by Martin Fournier — software developer, solo founder, and the product owner of 17 BMAD-enabled projects.