BMAD vs MASTERPLAN

The Same Problem, Two Schools of Thought

Every developer who has used an AI coding assistant for more than a week has run into the same wall. The tool is brilliant in the moment. But it has no memory of last Tuesday. It doesn't know that you scrapped the Redis approach in session 12, or that the payment module is already built, or that you're three features away from a v1 release. Every session starts with a blank slate, and somewhere around session 20, you start spending more time re-orienting the AI than actually building things.

Two open frameworks have emerged to solve this: BMAD (Breakthrough Method for Agile AI Driven Development) and the MASTERPLAN system, which I described in detail in Beyond the Context Window. Both work. Both are free. Both have been used on real projects. But they solve the problem from completely different angles, and conflating them will lead you to pick the wrong tool, or worse, dismiss one entirely because it doesn't do the thing the other one does.

This essay is a direct comparison. What each one is, what each one does well, where each one breaks down, and, critically, how they fit together when neither is enough on its own.

What BMAD Actually Is

BMAD is a development methodology packaged as an installable framework. At its core, it's an answer to the question: how should a developer and an AI collaborate, from the very first idea to the final deploy?

The framework ships with twelve or more specialized agents (a Project Manager, an Architect, a Developer, a UX Specialist, a Scrum Master, and others), each carrying deep domain knowledge for their phase of the project. There are over thirty structured workflows covering the full development lifecycle, from brainstorming and requirements gathering through architecture, implementation, and testing. It also includes a "Party Mode" that lets multiple agents collaborate in a single session, and a scale-adaptive planner that adjusts the depth of its planning to match the complexity of what you're building.

The philosophy behind BMAD is precise: AI should act as an expert collaborator that guides your thinking, not as a shortcut that replaces it. The framework is deliberately structured to force a human-AI partnership at every stage, rather than letting the AI autonomously define the scope, make architectural choices, and implement them without structured checkpoints.

Installing it takes thirty seconds and a Node.js v20+ runtime:

npx bmad-method install

From there, you invoke agents by context (bmad-help for guidance on what agent to use next) and work through the facilitated workflows sequentially. BMAD is opinionated about the order of development: brainstorm before architect, architect before build, build before test. It enforces a discipline that experienced teams have internalized but solo developers often skip.

What MASTERPLAN Actually Is

MASTERPLAN is a persistence system, not a methodology. It doesn't tell you how to develop software; it keeps track of what you've built so that your AI assistant never loses the thread.

The system is two files and four rules. MASTERPLAN.md is a hierarchical status table: every epic, feature, and sub-feature in the project, with impact/effort ratings and a status emoji (✅ Complete, 🚧 In Progress, 🔲 Planned, ⏸ Deferred). Each feature has a linked plan file in plans/ containing the full spec: dependencies, approach, scope checklist, verification steps, and Human Steps that gate AI execution at checkpoints requiring human action. The four rules live in CLAUDE.md and instruct Claude to read the dashboard before doing anything, treat plan files as the spec, surface Human Steps before writing code, and keep the table current after any status change.

The design principle is deliberately minimal: context windows get summarized, but the filesystem doesn't. Anything written to disk survives session compression. So the solution is to write project state to disk in a format the AI reads instantly, every single session, without manual re-briefing.

There is nothing to install. It works in any IDE on any machine, for any domain (code, content, infrastructure, marketing campaigns) wherever CLAUDE.md is read.

The Core Difference: Process vs State

Here is the distinction that matters most, and the one most people miss when comparing the two:

BMAD structures how you work. MASTERPLAN tracks what you've done, and what you're going to do.

BMAD is a process framework. It answers questions like: Which agent should I be talking to right now? What phase of development am I in? What inputs does my architect need before my developer can start? It's opinionated about the sequence and structure of AI-assisted development. Used well, it produces better architectures, catches gaps in requirements earlier, and enforces the kind of structured thinking that experienced engineers do naturally but junior developers often skip.

MASTERPLAN is both a memory system and a planning surface. It answers questions like: What features are already done? What was the decision we made about authentication two weeks ago? What's the next highest-priority item in the backlog? But it's equally useful looking forward. The 🔲 Planned rows in MASTERPLAN.md are your roadmap, and the plan files in plans/ are the specs that haven't been built yet. It doesn't care how you got here; it just makes sure the AI knows where "here" is, and where "next" is, every single session, without you having to explain it again.

Critically, MASTERPLAN doesn't dictate how those future plans get made. You can invoke a brainstorming skill to explore a new feature before writing the plan file. You can use a frontend-design or ui-ux skill to generate and evaluate UI options before committing to an approach. You can spin up specialized agents (an architect, a UX reviewer, a security auditor) to pressure-test a planned feature before a line of code is written. Whatever process you use to think through the work, the output gets captured in a plan file and tracked in MASTERPLAN.md. The system is process-agnostic by design: any skill, any agent, any workflow feeds into it.

This distinction isn't academic. If your problem is "the AI keeps proposing approaches we already tried" or "I have to re-explain the project every session," MASTERPLAN solves that. If your problem is "I need a structured plan for where this project is going," MASTERPLAN solves that too; it's as much a forward-looking roadmap as it is a history. If your problem is "I'm starting a new project and I don't have a structured way to go from idea to architecture to implementation," BMAD solves that. They're not competing for the same job.

Side-by-Side: Benefits and Drawbacks

Dimension BMAD MASTERPLAN
Primary purpose Structure the development process Persist project state across sessions
Setup npx bmad-method install + Node.js v20+ 3 files, zero dependencies
Learning curve High: 12+ agents, 34+ workflows to understand Low: 1 table, 4 rules, standard markdown
Solves context loss? Partially, only within a structured session flow Yes, filesystem-native, survives compression
Multi-agent support Yes (built-in Party Mode) Yes, plan files are readable by any agent
Best project phase New projects starting from scratch Any phase, bootstraps in minutes
Domain coverage Software development (deep, specialized) Any domain (code, content, infra, marketing)
Human checkpoints Built into agent workflows Explicit Human Steps section per plan file
Overhead for small projects High, most workflows designed for larger scope Low, a 3-feature project needs 3 plan files
Team vs solo Team-oriented by design Scales from solo to multi-agent worktrees
IDE portability Works best where the framework is installed Works wherever CLAUDE.md is read
Audit trail Workflow logs, agent-generated artifacts Plan files serve as both spec and decision record

When BMAD Wins

Greenfield projects with complex architecture

BMAD shines hardest when there's nothing yet. If you're starting a new product from a rough idea and you want structured guidance on requirements, architecture, and tradeoffs before you write a single line of code, BMAD's agent hierarchy is built for exactly this. The Architect agent can stress-test assumptions you didn't know you were making. The PM agent will surface missing requirements before they become tech debt.

Teams where multiple people use AI tools

Party Mode and the shared agent vocabulary give cross-functional teams a common language for AI-assisted collaboration. When a developer and a UX specialist are both using BMAD, they're working within the same framework for handoffs, reviews, and decision gates. That coordination is hard to replicate with a pure markdown system.

Projects that need expert-level planning discipline

Solo developers, especially earlier in their careers, often skip the architecture and requirements phases and go straight to implementation. BMAD makes skipping those phases structurally awkward, because the agents are ordered sequentially. That friction is a feature: it encodes engineering discipline that might otherwise only exist in the heads of senior engineers.

When the AI as guide is more valuable than the AI as executor

If you want an AI that asks you the right questions and helps you think through a problem, BMAD is designed for that mode. The agents are explicitly built to enhance human decision-making rather than automate it away.

When MASTERPLAN Wins

Projects already in flight

MASTERPLAN can be bootstrapped into any project in under ten minutes, regardless of where it is in the development cycle. If you're on session 40 and losing context constantly, you don't need to restart with a new methodology; you need a state file. MASTERPLAN gives you that without requiring any change to how you work.

When session continuity is the primary pain

The most common failure mode in long-running AI-assisted projects isn't bad architecture; it's the AI not knowing what already exists. Every session where you re-explain what's done and what's next is overhead that compounds over months. MASTERPLAN eliminates that overhead completely. The AI reads the dashboard, knows the state, and picks up exactly where the last session ended.

Non-software projects

BMAD is deeply specialized for software development. Its agents and workflows assume a codebase, a build process, and a deployment target. MASTERPLAN doesn't care. The same two-file system that tracks a web application also tracks a content calendar, an infrastructure migration, a marketing campaign, or a research project. The plan files contain whatever the domain demands.

Solo developers who want minimal overhead

BMAD's twelve agents and thirty-plus workflows are calibrated for projects and teams with the bandwidth to use them. For a solo developer building a side project, that overhead can be more friction than help. MASTERPLAN scales down cleanly; a five-feature project needs five plan files and one table. The cognitive load is proportional to the project.

The core asymmetry:

BMAD's value is highest at the start of a project, when there's the most ambiguity to structure. MASTERPLAN's value grows over time, as more sessions accumulate and the cost of re-briefing increases. A project that uses both gets the best of each phase.

The Real Drawbacks of Each

BMAD's drawbacks

The learning curve is real. Twelve agents is a lot of surface area to internalize, and using the wrong agent for the wrong phase produces worse results than using no framework at all. The thirty-plus workflows are comprehensive, but they're also a commitment: you need to spend time understanding which workflow applies before you can use any of them effectively.

BMAD also has a session-statefulness problem of its own. Unless you're disciplined about writing BMAD-generated artifacts to disk (architecture docs, requirements specs, ADRs), a new session that doesn't have access to previous outputs still starts cold. The framework provides excellent structure for a single project arc, but without a persistence layer underneath, the session boundary problem doesn't go away.

Finally, BMAD requires Node.js v20+ and the npx bmad-method install setup. That's a trivial requirement on a personal machine, but it's a friction point in environments where you can't install tools, or when you want the same workflow to work identically in a corporate IDE, a cloud dev environment, and your laptop.

MASTERPLAN's drawbacks

MASTERPLAN doesn't tell you how to build anything. It tells you what state you're in. If you come to it with no architectural clarity, no requirements discipline, and no structured approach to development, a MASTERPLAN.md file full of 🔲 Planned rows won't save you; it will just give you a tidy record of what you didn't build correctly.

The plan-before-code discipline that makes the system work is also the thing most developers skip. Writing the plan file before touching a feature, populating the Human Steps section honestly, keeping the table current after every status change: these habits compound into enormous value, but they require genuine upfront investment. Teams that treat MASTERPLAN as a retrospective documentation system get much less out of it than teams that treat it as a spec-first workflow.

It's also worth noting that MASTERPLAN is most effective with Claude Code specifically. The system is built around CLAUDE.md and Claude's instruction-following behavior. While the files are readable by any AI, the four-rule snippet and the Human Steps gates are tuned to how Claude operates.

The Combination That Actually Works

The most pragmatic takeaway from this comparison is that BMAD and MASTERPLAN aren't competing. They operate at different layers of the same problem.

Think of it as a stack:

  • BMAD (top layer): guides the development process, covering which agent to use, what phase you're in, and what questions to answer before writing code
  • MASTERPLAN (foundation layer): persists what was decided, built, and what's going to be built, a filesystem-native record that any session can read back instantly

A project that uses BMAD for its architecture phase generates artifacts (ADRs, requirements specs, component designs). Those artifacts can feed directly into MASTERPLAN plan files. The BMAD Architect agent's output becomes the "Approach" section of a plans/feature-01-auth.md file. The BMAD PM agent's requirements list becomes the Scope table. The Human Steps section captures the BMAD checkpoints that require human sign-off.

From that point forward, even when you're not in an active BMAD workflow, every Claude session reads MASTERPLAN.md and knows exactly what the Architect decided, what's been built, and what comes next. BMAD gave the project a rigorous starting shape. MASTERPLAN ensures that shape survives across the months of sessions it takes to build the thing. At any point, the entire state of the project, past and future, is a single file open in your editor. One glance at the table tells you what's done, what's in progress, and what's queued. No context switching, no digging through notes or chat history, no re-briefing required.

BMAD is the project kickoff meeting. MASTERPLAN is the written record that means the next developer, human or AI, can actually pick up where you left off.

The Decision Framework

If you're unsure which to use, these questions will point you in the right direction:

Your situation Use this
Starting a new software project with complex architecture BMAD first, then add MASTERPLAN as persistence
Existing project losing context across sessions MASTERPLAN (bootstrap it this week)
Solo developer, minimal overhead preferred MASTERPLAN
Team with mixed AI tool usage and coordination needs BMAD (Party Mode), with MASTERPLAN for session continuity
Non-software project (content, infra, ops, research) MASTERPLAN
You want the AI to guide your process, not just execute it BMAD
You want the AI to know what you built last Tuesday MASTERPLAN
Long-running project, maximum AI productivity Both (they stack cleanly)

The failure mode to avoid is treating these as alternatives and picking one. Teams that use BMAD without a persistence layer re-brief their AI at the start of every session. Teams that use MASTERPLAN without any methodology discipline end up with a well-organized plan for code that was never properly architected. The two systems cover different failure modes. If you're serious about AI-assisted development over the long term, you want both layers.

Start with whichever one solves your most immediate problem. If you can't finish a session without re-explaining the project, start with MASTERPLAN today; it takes ten minutes to bootstrap. If you're starting something new and want to get the architecture right before you write a line, start with BMAD. Then add the other layer when you feel the absence of what it provides. You will feel it.