Getting Started: “I’ll just use BMAD to move faster”
Over the last couple of weeks I’ve been working with the BMAD framework on a personal project, and I wanted to write this up while it’s still fresh.
Going in, my expectation was pretty simple: I’d plug in my idea, let the workflow guide me, and I’d be writing code quickly, with better direction and fewer dead ends.
That’s… partially true. But there’s a big caveat.
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.”
And if you’re used to hacking a prototype together first and figuring out the product later, this is going to feel slow. Sometimes painfully slow.
The First Reality Check: it takes a lot of time before you write anything
The first thing you notice with BMAD is that it pushes you into an extensive workflow before you’re allowed to feel productive in the way engineers usually define productivity (shipping code).
It takes you through a bunch of steps like:
- Defining the problem (and not just “I want to build X”, but “what pain exists and for who?”)
- Defining user personas
- Brainstorming approaches
- Researching the space
- Clarifying constraints (time, money, infra, team, target platform)
- Turning that into epics, stories, and execution plans
All of that is useful. But it’s not free.
For me, it took roughly 12 to 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.
And to be fair, I’ve done the opposite too many times:
- Build something fast
- Realize I built the wrong thing
- Rewrite it
- Lose motivation
- Abandon it
So yes, this up-front investment is real. It’s also kind of the point.
The Frameworks Are Actually Good (especially for business thinking)
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.
If you’re an engineer building a personal project, you usually start with:
- “What stack do I want to use?”
- “What architecture seems clean?”
- “What cloud services are cheapest?”
BMAD drags you back to questions like:
- 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 here 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” and how I burned through context and credits
Then I hit the fun (and painful) part: party mode.
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 tradeoffs
- different product angles
- risk lists
- architecture options
I made the mistake of telling it to run party mode with LangSearch and also run party mode with Gemini, and that combo absolutely exhausted my context window and usage credits.
What happened was predictable in hindsight: party mode wants to read, pull in sources, synthesize, then generate. That means:
- lots of tokens in
- lots of tokens out
- and depending on the tools, lots of paid calls
I tried to be clever and tell it something like: “don’t read everything, just put stuff into files and summarize.”
In practice, that didn’t really work the way I expected. Once you’ve instructed the workflow to do deep research, it tends to follow through. It wants to gather the material so it can justify conclusions. That’s good for quality, but bad for cost control if you’re not careful.
Still, I’ll say this: it was very useful. The output was genuinely better when it had multiple angles to compare. It just came at a price.
If you’re going to use party mode, my advice is simple:
- use it intentionally
- set boundaries (scope, sources, max depth)
- and assume it will be expensive if you let it run wild
12–16 hours later: the first line of code… and then I hit an architecture wall
After all the setup and the workflow, I finally got to the point where code started getting written.
And 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.
I had 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. 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 (for example, using @vendia/serverless-express or similar patterns) or you use 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
So what happened next is exactly what you’d expect: errors all over the place, and a system that kept trying to fix itself in a loop, without making real progress.
The 6-hour debugging spiral (and why it was so confusing)
I spent a huge amount of time trying to fix it, around six hours.
The frustrating part was that in the moment, I didn’t immediately know what was wrong. It wasn’t one clean error like “you used the wrong import.”
It was more like:
- something fails
- you fix the symptom
- something else fails
- the fix introduces another issue
- 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.
This is also where AI-assisted workflows can get weird. If the system is trying to be helpful, it can keep proposing changes that look plausible locally, but don’t address the root mismatch. You can burn a lot of time approving “reasonable” edits that never converge.
And that’s exactly what happened. It kept spinning, and I kept thinking, “why is this stuck?”
The turning point: I didn’t figure it out, the retrospective did
Here’s the interesting part: it wasn’t me that realized the core issue first.
What happened is I noticed it was spending too much time and not converging, and I decided to initiate the BMAD workflow for running a retrospective.
That retrospective step ended up being the breakthrough.
Because instead of continuing forward motion (which was fake progress), it forced a pause and asked:
- what are we trying to do?
- what’s blocking us?
- what assumptions did we make?
- what changed?
- what decision is causing repeated failure?
That’s when it became clear that the setup was not right. The architecture needed adjustment to match the runtime model.
Once that was identified, the next steps were obvious:
- either adjust the NestJS setup to run properly in a serverless handler model
- or change the compute model (for example, containerized service on something like ECS/Fargate, or a simple VM), depending on goals
- or pick a framework more naturally aligned with serverless
The main point is that the retrospective forced the system to stop patching and start diagnosing.
And honestly, this is one of the strongest arguments for structured workflows like BMAD. Most engineers don’t run retrospectives on a personal project when things go wrong. We just grind harder.
I’ve done that grind plenty of times. It rarely helps.
After the fix: everything went smoothly (and the “stories” became the superpower)
Once everything was set up correctly, the experience changed completely.
The biggest win for me was the fact that I had stories. Real stories. Not vague tasks like “build backend.”
With stories, I could tell it exactly what to implement, in a way that was scoped and testable. That meant I wasn’t doing a bunch of extra work translating ideas into engineering tasks. The translation was already done.
At that point my role became:
- supervise
- review decisions
- sanity check the code
- occasionally click yes/no for requests and changes
- keep it aligned with the goal
That’s a very different feeling than “I’m the one doing everything.”
And it’s genuinely cool when it works because it shifts the bottleneck. Instead of “how fast can I type,” it becomes “how well can I review and steer.”
If you’ve ever led a team, you’ll recognize that mode. You’re not writing every line. You’re making sure the work being done is the right work.
What BMAD gets right: patience in exchange for momentum
Overall, I think BMAD is really cool.
But I don’t want to oversell it. The trade is clear:
- You need patience to set it up
- You need to give good answers
- You need to review everything
- and you need to accept that the early phase feels slow
If you treat it like a magic code generator, you’re going to be annoyed.
If you treat it like a process that front-loads thinking, documentation, and execution structure, it starts to make sense.
And once you’re past that initial slope, it becomes pretty straightforward.
The underrated feature: you can resume anytime because everything is in documents
Another thing I didn’t appreciate until I was in it is how nice it is that you can resume at any time.
Because everything is written down, you’re not relying on your memory or on some fragile chat context. You have artifacts:
- personas
- problem statements
- architecture notes
- epics
- stories
- decisions and tradeoffs
So you can come back after a day or a week and say:
- “execute this epic”
- “continue this story”
- “implement the next task”
- “run a retrospective on the last change”
And it doesn’t feel like starting over.
For personal projects, that’s huge. Most of us lose momentum not because we can’t code, but because we return after a break and spend an hour reconstructing context.
BMAD reduces that tax.
What I’d tell another engineer before they try it
I’m not going to pretend this is the answer for every project. If you’re hacking a quick script or testing an API idea, BMAD is probably too heavy.
But if you’re building something that you actually want to ship, even as a solo developer, it’s worth considering.
A few practical lessons from my run:
- Budget time for setup. If you expect to write code in the first hour, you’ll fight the workflow.
- Be careful with party mode. It’s useful, but it can burn context and credits fast.
- Don’t treat architecture prompts casually. “Low cost” pushes you toward serverless patterns, which can be great, but it constrains framework choices and deployment shape.
- Use the retrospective when you’re stuck. The instinct is to push forward. The smarter move is to stop and diagnose.
- Stories are where the payoff happens. Once you have good stories, execution becomes much more mechanical.
Closing thoughts
BMAD ended up being one of those experiences where the first phase feels like friction, and then later you realize the friction was the whole point.
It forced me to slow down, define what I was doing, and make decisions explicit. I burned time (and credits) in a couple places, especially with party mode. I also lost six hours to an architecture mismatch that I should have caught earlier.
But once the workflow and docs were in place, it got surprisingly smooth. Being able to resume from epics and stories, and to steer implementation without constantly rewriting requirements, is a real productivity shift.
If you try BMAD, bring patience. Bring discipline. And assume you’ll spend more time thinking before you spend time coding.
If this resonates, what’s your experience been with structured AI-assisted workflows? I’m curious.
Word count: ~1,890
Top comments (0)