BMAD Method (Part 2): Building MemoIt, From a Vague Idea to a Working App

In the first article I stayed on concepts and commands. I promised a more concrete example, and this is it. I took a real project, a small web app called MemoIt, and ran the BMAD workflow on it from the first vague idea to the last retrospective, step by step, one command at a time. The code is on my GitHub: MemoIt. Every document I mention is in the repository, under _bmad-output/. As in the first article, what follows is a personal view, not a verdict. The Example: MemoIt MemoIt is a web app for notes, todo lists and wish lists. Angular on the frontend, Firebase (Auth and Firestore) as the only backend. Mobile first, responsive on tablet and desktop. Each user has an account created by hand in the Firebase console, with data isolated from the others. No sign-up, no sharing. I started with a sentence, not with a spec: /bmad-brainstorming I have a vague idea for an Angular web app with a Firestore backend to manage notes, todo lists and wish lists. I still have to focus the idea. That is the whole input. Everything else in this article came out of the workflow. One note on the tooling. I ran the whole workflow with Claude Code, so the commands you see are the slash commands of Claude Code. BMAD itself is not tied to it: it also works with other harnesses, GitHub Copilot among them. The method lives in the skills and in the documents, not in the tool that runs them. BMAD Looks Like a Company Before the steps, one observation. When I laid the skills side by side, I noticed they copy the structure of a company that takes software seriously. There is an analyst who asks what and why. A product manager who owns the PRD. A UX designer, an architect, a product owner who cuts the work into epics and stories, a scrum master who plans the sprint, a developer, a reviewer, and a retrospective at the end of every epic. Each role has one skill, and each skill owns one document. Nobody downstream reinterprets the document of someone upstream. If the PRD has a gap, the gap goes back into the PRD and the derived documents are regenerated. Mental Model: BMAD is not a code generator with a few prompts. It is an SDLC where the roles are played by agents and the handoffs are files. This is the whole point. If you have worked in a structured company, the vocabulary is familiar: PRD, epics, sprint, readiness check, retrospective. What changes is that the handoffs are explicit and written on disk, so a fresh chat can resume from the files. The Workflow I Ran I used one fresh chat for every planning step (/clear first). The files are the memory, not the conversation. The orange box is not part of the standard path: the prototype is a step I added myself, after architecture and before epics and stories. I describe it in its own section below. The build part has two nested loops. The inner one is the story loop: /bmad-build runs once per story, 22 times in total, and the review by the three reviewers is part of that command. The outer one is the epic loop. When all the stories of an epic are done, I run /bmad-code-review on the diff of the whole epic. Only if the review finds something to fix, I run /bmad-build with the findings as intent. Then I run /bmad-retrospective. The retrospective is per epic, not per story: 7 in total. Let me go through the steps. Step 1: Brainstorming (what and why, no technology): /bmad-brainstorming I have a vague idea for an Angular web app with a Firestore backend to manage notes, todo lists and wish lists. I still have to focus the idea. The skill behaves like a creative coach. I chose the Creative Partner stance, and it kept a .memlog.md on disk with one line per idea, decision and question. I worked with four techniques: Job to Be Done, Assumption Reversal, Crazy 8s, and One Feature Only, which I refused. The coach took note and moved on. It is a small example of the human staying in control. The most useful result came from Assumption Reversal. I realised MemoIt is not mostly for writing: it is for consulting what I wrote. That moved the "done" state to the center of the design, and rare actions (clear done items, rename) away from the list. Then the convergence, with MoSCoW. The coach put "sharing with family" in Must. One check question showed there was no sharing: every family member has a separate account. The real Must was multi-user with isolated data. A quick answer had hidden a misunderstanding, and one question brought it out. Later I also promoted language and colors, reminders and charts to Must. The coach proposes, the decision stays with me, and the intent document follows. Step 2: PRD (the source of product definition): /bmad-prd The PRD gave the functional requirements (FR-1 to FR-14), the nine non-functional ones, and the glossary. Before moving on I changed it with one sentence: /bmad-prd remove push, put push and offline as deferred nice-to-have The change propagated to the user journey, the glossary, the success metric and the addendum. It also changed the architecture before I wrote it: without push, there is no server. Step 3: UX (look and behavior in two documents): /bmad-ux I need a nice UI mainly for mobile that also looks good on tablet and desktop. All the screens as HTML files and an MD that explains how to navigate. Material 3, but configurable multicolor. The skill produces DESIGN.md (how it looks) and EXPERIENCE.md (how it behaves). I added the HTML mockups and a navigation file. Two short requests changed a lot: "some screens are too poor, make them fuller" and "I want a logout from every screen, not only in Settings". The PRD had not made the second one emerge. Requests like these are already specifications, and the method works because mockups and documents change together. Looking at the mockups in a real browser found defects that reading the code never showed: fields outside the border on phone, a button that should be hidden and was not, sample data that did not add up. Step 4: Architecture (the spine): /bmad-architecture let's go fast, Angular 21 or 22, backend only persistence on Firebase /bmad-architecture reference the mockups of the UX section /bmad-architecture approve The output is one short document: the architecture spine. It does not describe the system. It fixes only the invariants, the decisions where two parts built separately could choose in an incompatible way. Each one has an id (AD-n), what it binds, which divergence it prevents, and a rule. MemoIt ended with 18 of them. A sentence I said aloud, "backend only persistence", became AD-3: only Auth, Firestore and Hosting. A project check now fails if a functions/ folder appears. The constraint no longer depends on anyone's memory. The skill also verified the versions on the package registry instead of trusting memory. TypeScript 7 exists, but Angular 22 accepts only 6.0, so the version is pinned to 6.0.3. The Prototype Before the Plan Here I did something that is not in the standard path, and I think it was the most useful decision of the project. After brainstorming, PRD, UX and architecture, and before epics, stories and any real code, I asked for a prototype. A single HTML file under doc/, with real logic and persistence in memory only: /bmad-build create a clickable prototype of MemoIt in one HTML file, using the mockups of the UX section, with login, categories, items, report and settings. Data in memory only, no backend. I used /bmad-build for it, the same skill I use for code. Why was it useful? Because until then I had only read documents and looked at static mockups. The prototype let me, the human, check whether the behavior was the one I expected: tap to mark as done, undo, filters, sort, deadlines, the in-app alert, the report, the accent that recolors the whole app. The sample data lives in memory, so a reload gives a clean state. I found a few things I would not have found by reading the PRD. Some I adopted, some I cut, and the documents were updated before the stories were written. It is cheaper to change a misunderstanding in a single HTML file than in 22 stories. I want to stress this point, because I think it is the part with the most value. A prototype made before the development lets the people who own the decisions check the solution when changing it is still cheap. The product owner can click through the real flows and say "this is not what I asked for", and the architect can see the behavior that the architecture has to support. Both can do it before a single story is built. In a real team, this is the difference between finding a wrong assumption in the first week and finding it at the demo of the last sprint. I cannot give you a number of hours saved, because I did not run the project twice. But every misunderstanding the prototype caught was one that would otherwise have gone through the epics, the stories, the code, the tests and the reviews, and would have been paid for in every one of those steps. For me, this is the whole lesson: validate the solution early, with something people can touch, and keep the agents for after the intent is confirmed. The prototype is also cheap in the way that matters here. It is one HTML file, with the data in memory, and it was produced with the same /bmad-build I use for everything else. It needs no backend and no Firebase project. Epics, Stories, Readiness, Sprint Step 5: Epics and stories: /bmad-create-epics-and-stories The result: 7 epics and 22 stories, in dependency order, with every functional requirement covered by at least one story. Story 1.1 is the scaffold with Firestore rules tested on the emulator. The PWA (a Could) is the last one, and it can be skipped. Step 6: Readiness check and sprint planning: /bmad-sprint-planning check implementation readiness /bmad-sprint-planning run sprint planning The gate returned PASS. Then it generated sprint-status.yaml: 7 epics, 22 stories and 7 retrospectives, all in backlog. This is the Scrum Master step, and it is the one that makes the next phase mechanical. The Build Loop For every story I ran the same thing: /bmad-build 3-3-mark-done-with-undo It writes a spec for the story, implements it, and launches three reviewers in a fresh context: a blind one that sees only the diff, one that hunts edge cases, one that looks for verification gaps. Then the triage decides: patch, defer to deferred-work.md, or void. Here is what the loop did on story 3.3, as an example. The agent implemented an optimistic toggle with rollback and an Undo action in the snackbar. The reviewers found that Undo should act only if the item still has the value just set, and that an item deleted elsewhere must disappear from the list. Both were fixed. One finding, "snackbar buttons are not clickable", was false, and the triage voided it. The rest went to deferred-work.md. At the end of every epic: /bmad-code-review (on the diff of the whole epic) /bmad-build (once, with the findings as intent) /bmad-retrospective The review of the whole epic finds what the per-story review cannot see. In epic 4 it found that the summary counted items of categories not yet loaded and showed 0 while loading. In epic 5, that a deadline in the year 9999 made the chart create hundreds of thousands of buckets. The retrospective then judges the epic against its own criteria and every finding needs a source. One lesson from the first retrospective I would copy anywhere: reviewers read well only the first third of a 3000-line diff. For big epics, split the diff. What the Process Left Me The final numbers, taken from the last run and not from memory: 7 epics, 22 stories, 7 retrospectives, all done. 365 unit tests and 68 tests of the Firestore rules on the emulator. 12 end-to-end tests with Playwright, with axe on every screen, in light and dark. 9 accent colors checked for contrast, all above the AA threshold. A deferred-work.md with everything that was found and consciously postponed. The count of tests matters less than the traces. For every story I can read what was asked, what was decided and why, and what was left out. Quick Corrections: Only /bmad-build At the end, when the app was running, I made some small corrections: align the settings screen to the prototype, compact the categories, move the sign-out out of the user card, keep accent and language after a sign-out. For these I did not go through the whole workflow. I ran only /bmad-build with the intent in one sentence. This is what I explained in the first article: BMAD has several workflows and the size of the work decides which one to use. A typo or a small visual fix does not need a PRD. A new epic does. One session of about 500 lines goes through /bmad-build, and the skill itself checks whether the intent has gaps or irreversible actions before going further. What the Method Gave Me A trace for every decision. The .memlog.md of each step, the spec of each story, the retrospective of each epic. I can answer "why is it like this" from the files. Consistency across sessions. I ran dozens of fresh chats. The result is coherent because each one reads the same documents. A vocabulary I already knew. Epics, stories, sprint, retrospective. A team can adopt it without learning a new language. Bounded autonomy. The agents decide inside a frame I approved. What the Method Did Not Give Me The other side, with the same sincerity as before: It did not guarantee correctness. The reviewers found real defects after the implementation. They also made false positives. Triage is still a human job. It has a cost. Many documents, many fresh chats. For a project this small, it is more process than strictly needed. I accepted it because I wanted to learn the method, not only to ship the app. It does not decide the product. The PRD says what I decide. When I asked a skill to decide for me, I gave it one criterion first: keep the product small. Five features of the mockups were cut with that sentence. final does not mean reviewed. For several documents the status meant "decided and aligned", not "checked by a reviewer". The summaries said it, and I think this distinction is worth keeping. Some things were not verified in a browser. The story builds passed ng build and the tests, and the end-to-end suite came at the end. Between those, the prototype was my only visual check. The Cost in Tokens This deserves its own section, because it is the biggest limit I found. I think BMAD is a valid and complete framework. But compared with GitHub Spec Kit, it looked much heavier in the development phase, and the weight is in the tokens. The reason is easy to see. After every story, /bmad-build launches three reviewers in a fresh context, each one reading the diff and the spec. Over 22 stories, plus the review of each of the 7 epics, the reviewers alone are a large part of the bill. The planning steps are also not light, but they happen once. The development loop is repeated, and every repetition pays for the reviewers again. Here is the practical side. The whole project took me about two days. That time includes the moments when I ran out of tokens: with my Claude subscription the usage is limited in windows of 5 hours, and more than once I had to stop and wait for the next window before the run could continue. With a small app like MemoIt, I did not expect to hit the limit this way. To be fair, the reviewers are not wasted. They do a lot of functional checking, and they found real defects: wrong counts while data was loading, a date in the year 9999 that created hundreds of thousands of buckets, an Undo that acted on the wrong value. A cheaper process would probably have missed some of them. The other side is in the UX. The reviewers are strong on functional correctness and weaker on how the screens look and feel. A few visual and usability details slipped through, and I saw them only in the prototype and in the browser, not in a review report. That is one more reason for the prototype: it covers a part of the quality that the reviewers do not. So whether the price is worth it depends on the project. For MemoIt I would not call it a waste, because I wanted to learn the method and the checks were real. But I would not run three reviewers on a typo, and this is exactly why the first article insists on choosing the workflow by the size of the work. If you work on a subscription with usage windows, plan for the breaks. The Role of the Human In this run, I made the calls that matter: Moment What I decided Brainstorming Which features are Must, and what to refuse PRD What to cut (push, offline) UX and prototype Whether the behavior is what I expected Architecture Approve the spine Readiness check Go to the sprint Triage and retrospectives What to fix, defer or void Bounded autonomy, not full automation. This is the sentence from the first article, and after MemoIt I would write it again. Takeaways BMAD is an SDLC with agents in the roles. Analyst, PM, UX, architect, PO, scrum master, developer, reviewer: one skill and one document each. Build a prototype before the plan. A clickable file made after UX and architecture let me check the behavior before 22 stories depended on it. Size decides the workflow. The full path for the epics, only /bmad-build for the quick corrections. Files are the memory. Fresh chats, same documents, same decisions. The human approves the intent and judges the result. The agents propose, review and report their own gaps. Thoroughness has a price in tokens. The three reviewers after every story caught real defects, but they made a small app take about two days, with pauses for the usage windows. UX details can still slip through. What Comes Next I have not decided what the next article should be, so I would like to ask you. These are the options I am considering: BMAD against GitHub Spec Kit, looking at process, cost in tokens and results. Other SDLC frameworks for agents, such as OpenSpec, agent-skills and Matt Pocock's skills. More aspects of BMAD that I did not cover here. A mixed setup: BMAD as the end-to-end framework, with the implementation done by another framework. Which one would you read first? Or is there something else you would like to see? Where do you keep your specs: repo, tracker, or chat? I would love to read your experience in the comments.