Think Before You Build
How BMAD structures the work that happens before developers write code, and why it matters
BMAD stands for Build More Architect Dreams. It’s a comprehensive, AI-assisted methodology for turning rough ideas into production-ready code. Rather than jumping straight to implementation, BMAD invests upfront in specification and design, using a suite of specialized AI agents to handle the heavy lifting across product, design, architecture, and planning disciplines.
The core premise is simple: structured thinking beats ad-hoc coding. By clarifying requirements, designing user experiences, planning architecture, and breaking work into detailed stories before developers write code, you reduce rework, align teams, and ship higher-quality features.
BMAD tries to formalize what successful teams already do informally: think carefully before building, use specialized expertise (product, design, architecture), document decisions, and iterate based on what you learn.
The Core Philosophy
BMAD rests on a few key ideas:
Artifacts over intuition. Write down your decisions. A PRD, a UX spec, an architecture diagram aren’t bureaucracy, they’re shared understanding. When everyone reads the same document, you surface disagreements before they become expensive rewrites.
Specialization with integration. Product managers, designers, and architects have different expertise. BMAD acknowledges this by having specialized agents (or people) handle each discipline. But these disciplines work in parallel and feed each other, not in isolation.
Validation before execution. Explore the problem space. Research competitors, technical approaches, domain constraints. Validate that you’re solving the right problem before you spend engineering time building it.
Specification-driven development. Developers work from detailed stories with acceptance criteria and architecture guidance. No ambiguity, no guessing. This means faster, higher-quality code and clearer code reviews.
Learning embedded. Retrospectives and reviews aren’t afterthoughts, they’re part of the process. What worked? What surprised you? What should you do differently next time?
What BMAD Actually Provides
BMAD comes by default with nine specialized agents, each handling a distinct role in the development process. Think of them as expert consultants you can summon when you need help. You can of course extend BMAD by bringing your own specialized agents.
The Analyst (bmad-analyst), named Mary, handles project brainstorming, research, and creating the initial product brief. She’s your starting point when you have a rough idea and need to understand the problem space before committing to a direction.
The Product Manager (bmad-pm), named John, manages PRD creation and validation, epic and story generation, and implementation readiness. He turns validated direction into the requirements document that drives everything else.
The UX Designer (bmad-ux-designer), named Sally, creates user experience specifications: user flows, interaction patterns, and interface details. She works alongside the architect to make sure design and technical constraints stay aligned.
The Architect (bmad-architect), named Winston, designs the technical system. Components, data models, API contracts, technology choices, architecture decision records. This is the roadmap that keeps implementation consistent.
The Scrum Master (bmad-sm), named Bob, handles sprint planning, story creation, retrospectives, and course corrections. Once architecture is settled, Bob breaks the work into implementable stories with clear acceptance criteria.
The Developer (bmad-dev), named Amelia, implements stories and handles code review tasks. The QA Engineer (bmad-qa), named Quinn, generates tests for existing features.
The Technical Writer (bmad-tech-writer), named Paige, produces documentation, updates standards, generates diagrams, and explains concepts for the rest of the team.
The Quick Flow Solo Dev (bmad-master), named Barry, is a special-purpose agent for rapid development. When the work is small and well-understood, Barry runs a compressed flow: clarify intent, plan, implement, review, and ship, without the full specification pipeline.
These agents work in parallel where possible. While John is drafting a PRD, Sally is designing UX. While Winston is finishing the architecture, Bob is preparing the first stories. This parallelization compresses what would be sequential work into a single timeline.
The Process: Four Phases
BMAD organizes work into four phases:
Analysis. Start with a rough problem or idea. Mary (the Analyst) runs brainstorming sessions, market or technical research, and produces a product brief. This phase is optional: if you already have a validated direction, you can skip it. Exit with a clear problem statement and chosen approach.
Planning. John (the Product Manager) drafts the PRD. Sally (the UX Designer) creates the UX spec. These happen in parallel and inform each other. You exit this phase with documented requirements and a designed user experience.
Solutioning. Winston (the Architect) designs the technical system and documents decisions as architecture decision records. Bob (the Scrum Master) breaks the work into epics and stories with acceptance criteria. Before implementation begins, there’s an implementation readiness check: a gate that returns PASS, CONCERNS, or FAIL. This is where most of the design work happens and where coordination problems get resolved before they become expensive.
Implementation. Amelia (the Developer) picks up stories and builds them. Quinn (the QA Engineer) generates tests. Code review happens on every story. The sprint closes with a retrospective where Bob captures what worked, what didn’t, and what to do differently next time.
For a moderate feature, if you compress it, you’re looking you’re looking at 8-10 hours total. The first three phases are 1-2 weeks, but they happen before development, so you’re not compressing a timeline, you’re shifting work earlier where it’s cheaper to change.
When to Use BMAD
BMAD isn’t a universal solution, it’s optimized for specific kinds of problems. And it also doesn’t fit all organizations, as the complexity of the overall process induces a high consumption of tokens.
Use it for: New products or major features, complex cross-team initiatives, strategic business work, and anything where building the wrong thing has a high cost. If alignment across teams is a real source of friction, BMAD is designed for that.
Skip the full pipeline for: Simple bug fixes, one-off tweaks, internal tools with loose scope, and well-understood small features. For this kind of work, BMAD has a Quick Flow track: Barry (bmad-master) runs a compressed single-agent flow that clarifies intent, plans, implements, and reviews without the full specification pipeline.
The overhead of the full BMAD workflow is worth it when the cost of rework is high or when coordination across product, design, and engineering is a real source of friction. For simple work, Quick Flow is the right tool.
The Trade-off
BMAD’s strength is turning ideas into well-designed, well-specified implementations. Its weakness is speed. You’re spending 1-2 weeks upfront in planning before a single line of code is written. For some teams and projects, that’s valuable. For others, it’s overhead.
There’s also a discipline requirement. BMAD only works if teams actually follow it. If stakeholders bypass specs to dictate requirements, or developers ignore stories and build what they think is right, the methodology breaks. Cultural buy-in matters.
And the outputs are only as good as the agents and the people reviewing them. A weak PRD creates weak specs. A poorly thought-out architecture guides poor implementation.
Using BMAD Selectively
One pattern worth knowing, especially for solo and indie developers: BMAD’s planning phases are where most of the value is. Running nine specialized agents through a full sprint cycle, with structured story loops, sprint tracking, and retrospectives, consumes a significant number of tokens. For a single developer building something on their own, the full implementation pipeline can be more overhead than it’s worth.
A practical alternative is to use BMAD for project initiation only. Let Mary, John, Sally, and Winston do the heavy lifting upfront: brainstorming, research, a solid PRD, a UX spec, a well-reasoned architecture, and an initial set of epics. That foundation is genuinely hard to produce well without the structured agent process. Once you have it, switch to a lighter framework for implementation.
OpenSpec or SpecKit are both valid candidates for the implementation phase. Use either of them: OpenSpec works well for documenting incremental changes as you build, whether Spec Kit gives you structured specs without the full agent pipeline. Both are lighter on tokens and less demanding on process discipline, which suits solo development well.
This gives you BMAD’s strongest benefit, clear and well-reasoned upfront design, without committing to the full process for every story you implement.
In The Next Article…
In the next part, we’ll walk through the BMAD workflow in detail. What actually happens in each phase? What decisions get made? How do the agents work together? If you’re trying to figure out whether BMAD makes sense for your work, the details matter.
Resources
The BMAD project
Official BMAD documentation covers installation, all nine agents in detail, the full workflow map, and advanced concepts like Adversarial Review and Party Mode.
BMAD on GitHub is where the project lives. Install via npx bmad-method@next install. Works with Claude Code, Cursor, GitHub Copilot, Codex, Gemini, Windsurf, and Cline.