My Experience Using the BMAD Framework on a Personal Project (Patience Required)

Source: Dev.to

My Initial Expectation

Going in, my expectation was pretty simple:

• I’d plug in my idea.
• Let the workflow guide me.
• I’d be writing code quickly, with better direction and fewer dead ends.

That’s… partially true. But there’s a big caveat.

The Real Deal

BMAD is not a “start coding in 20 minutes” setup. It’s closer to:

“Do the work up‑front so the coding part stops being the hardest part.”

If you’re used to hacking a prototype together first and figuring out the product later, this will feel slow—sometimes painfully slow.

What BMAD Forces You to Do First

Before you can feel “productive” in the usual engineering sense (shipping code), BMAD pushes you through an extensive workflow:

1. Define the problem – not just “I want to build X”, but “what pain exists and for who?”
2. Define user personas
3. Brainstorm approaches
4. Research the space
5. Clarify constraints (time, money, infra, team, target platform)
6. Turn that into epics, stories, and execution plans

All of that is useful, but it isn’t free.

Time Investment

For me, it took roughly 12–16 hours before the first line of code was written. That number sounds ridiculous if you’re thinking in “weekend project” mode, but the more I sat with it, the more it made sense:

• BMAD forces you to do the thinking you usually avoid until the project is already messy.
• I’ve done the opposite too many times:
  • Build something fast → realize it’s the wrong thing → rewrite → lose motivation → abandon.

So yes, this up‑front investment is real—and it’s kind of the point.

A Fresh Perspective on the Business Side

One of the things I genuinely liked is that the frameworks presented in BMAD give you a different perspective, especially around the business side of what you’re building.

Typical Engineer‑First Questions

• “What stack do I want to use?”
• “What architecture seems clean?”
• “What cloud services are cheapest?”

BMAD‑Driven Questions

• Who is this for, specifically?
• What are they trying to accomplish?
• What do they do today instead?
• Why would they switch?
• What’s the smallest thing that proves value?

Even if you think you already know those answers, writing them down forces clarity. The value isn’t that it tells you something magical; the value is that it makes you commit to decisions.

But again, you pay for that clarity with time—you’re not coding, you’re thinking and documenting.

Party Mode: Fun (and Painful)

If you haven’t used it, party mode is basically the “get multiple perspectives and generate a lot of material quickly” mode. It can be super useful when you want breadth:

• Different solutions
• Different trade‑offs
• Different product angles
• Risk lists
• Architecture options

My Mistake

I told it to run party mode with LangSearch and with Gemini. That combo absolutely exhausted my context window and usage credits.

What happened (predictable in hindsight):

• Party mode wants to read, pull in sources, synthesize, then generate.
• → Lots of tokens in
• → Lots of tokens out
• → Depending on the tools, lots of paid calls

I tried to be clever and said: “don’t read everything, just put stuff into files and summarize.” In practice, that didn’t work as expected. Once you instruct the workflow to do deep research, it tends to follow through—gathering material so it can justify conclusions. That’s great for quality, but bad for cost control if you’re not careful.

Advice for Using Party Mode

1. Use it intentionally.
2. Set boundaries (scope, sources, max depth).
3. Assume it will be expensive if you let it run wild.

The Architecture Mistake

After all the setup and workflow, I finally got to the point where code started being written. Almost immediately I realized I had made an architecture mistake.

This part is important because it’s the kind of mistake that’s easy to make when you’re letting an assistant drive, and you’re “supervising” instead of actively building.

What Went Wrong

• I told the architect to focus on low cost, so it leaned into a serverless setup—specifically AWS Lambda‑style compute.
• Then I told it to use NestJS.

On paper that sounds fine, but in reality it’s tricky:

• NestJS can run in a serverless environment, but it’s not “drop‑in NestJS and deploy to Lambda” unless you set it up correctly.
• You typically need an adapter layer (e.g., @vendia/serverless-express or similar patterns) or a framework that’s more directly aligned with serverless request handling.

Without that, you get a mess of mismatched assumptions:

• Long‑lived server patterns vs. cold starts
• Framework bootstrapping time vs. latency expectations
• Request lifecycle differences
• Deployment packaging and handler wiring

The Result

• Errors everywhere.
• A system that kept trying to fix itself in a loop, without making real progress.

I spent a huge amount of time (around six hours) trying to fix it.

The frustrating part was that, in the moment, I didn’t immediately know what was wrong. It wasn’t a clean error like “you used the wrong import.” It was more like:

1. Something fails.
2. You fix the symptom.
3. Something else fails.
4. The fix introduces another issue.
5. You end up in a loop.

If you’ve ever dealt with a misaligned architecture decision early in a project, you know the feeling. The code is “correct” in isolation, but the environment and assumptions are wrong.

Takeaway

AI‑assisted workflows can keep proposing changes that look plausible locally, but don’t address the root mismatch between framework and deployment model.

TL;DR

• BMAD forces a lot of up‑front thinking and documentation—expect 12‑16 h before the first line of code.
• The payoff is clearer decisions, better product‑market fit, and fewer dead‑ends later.
• Party mode is powerful but token‑hungry; use it with clear limits.
• Be careful when combining low‑cost serverless goals with heavy frameworks like NestJS—make sure you have the proper adapters or choose a more suitable stack.

If you’re willing to invest the time up front, BMAD can save you a lot of pain down the road. If you’re in a “just hack something” mindset, be prepared for a slower start.

The Situation

I was stuck in a loop where the AI kept “approving” reasonable edits that never converged. It spun forever and I kept wondering why it was stuck.

What Triggered the Breakthrough

1. I noticed the process was spending too much time without converging.
2. I launched the BMAD workflow and ran a retrospective.

The retrospective forced a pause and answers to these questions:

• What are we trying to do?
• What’s blocking us?
• What assumptions did we make?
• What changed?
• Which decision is causing repeated failure?

The Insight

The retrospective revealed that the setup was wrong – the architecture didn’t match the runtime model.

Options Identified

• Adjust the NestJS setup to run properly in a server‑less handler model.
• Change the compute model (e.g., containerized service on ECS/Fargate or a simple VM), depending on goals.
• Pick a framework that aligns more naturally with server‑less.

The key point: the retrospective stopped endless patching and started real diagnosis.

Why Structured Workflows Like BMAD Matter

Most engineers don’t run retrospectives on personal projects when things go wrong; we just grind harder.
Grinding rarely helps.

What Changed After the Fix

• Stories appeared – real, scoped, testable tasks instead of vague “build backend” items.
• I could tell the system exactly what to implement; the translation from idea to engineering task was already done.

My New Role

• Supervise
• Review decisions
• Sanity‑check the code
• Occasionally click yes/no for requests and changes
• Keep the work aligned with the goal

This feels very different from “I’m doing everything.” It shifts the bottleneck from “how fast can I type?” to “how well can I review and steer?”

If you’ve ever led a team, you’ll recognize this mode: you’re not writing every line; you’re ensuring the right work gets done.

The Trade‑offs

Treating BMAD as a magic code generator leads to frustration. Treating it as a process that front‑loads thinking makes sense, and after the initial slope it becomes straightforward.

Resume‑ability: A Big Win

Because everything is written down, you’re not relying on memory or fragile chat context. You have concrete artifacts:

• Personas
• Problem statements
• Architecture notes
• Epics
• Stories
• Decisions & trade‑offs

You can come back after a day or a week and simply say:

• “Execute this epic.”
• “Continue this story.”
• “Implement the next task.”
• “Run a retrospective on the last change.”

It doesn’t feel like starting over. For personal projects, this reduces the context‑reconstruction tax that kills momentum.

When BMAD Is (and Isn’t) Appropriate

• Not ideal for quick scripts or one‑off API tests – it’s too heavyweight.
• Ideal for anything you actually want to ship, even as a solo developer.

Practical Lessons From My Run

1. Budget time for setup.

   • Expecting to write code in the first hour will clash with the workflow.

2. Be careful with “party mode.”

   • Useful, but it can burn context and credits quickly.

3. Don’t treat architecture prompts casually.

   • “Low cost” nudges you toward server‑less patterns, which can be great but also constrain framework choices and deployment shape.

4. Use retrospectives when you’re stuck.

   • The instinct is to push forward; the smarter move is to stop and diagnose.

5. Stories are where the payoff happens.

   • Good stories turn execution into a mechanical, repeatable process.

6. Accept the early friction.

   • The first phase feels like friction, but that friction is the point: it forces you to slow down, define what you’re doing, and make decisions explicit.

7. Track time and credits.

   • I burned time (and credits) in a few places, especially with party mode, and lost six hours to an architecture mismatch that could have been caught earlier.

8. Once docs and workflow are in place, the process becomes smooth.

   • Resuming from epics and stories, steering implementation without constantly rewriting requirements, is a real productivity shift.

Final Thoughts

If you try BMAD, bring:

• Patience – the setup phase is intentional front‑loading.
• Discipline – keep the documentation and review loop tight.
• A mindset that you’ll spend more time thinking before you spend time coding.

Your Turn

If this resonates, what’s your experience been with structured AI‑assisted workflows? I’m curious to hear your thoughts.