An honest account of running a real product through the BMAD agent framework, from brainstorm to 30+ implemented stories.
The Project
Velo Hire is a privacy-first staffing platform built on a “mutual consent” model. Clients browse an anonymised talent gallery – skills and certifications visible, names and photos structurally absent. Freelancers review the client’s project brief and choose to accept or decline silently. Only when both sides agree does any identity unlock.
This isn’t a to-do app. It has three portals (freelancer, client, agency admin), RBAC, GDPR-compliant PII segregation enforced at the database layer, SSE notifications, AI-assisted CV parsing, evidence-based timesheets, and an earnings engine. Built on Next.js 15, Prisma 7, and AuthJS 5 beta. Real complexity, not a playground project designed to make AI look good.
What is BMAD?
BMAD (Breakthrough Method for Agile AI-Driven Development) installs directly into Claude Code as a set of skills, each mapped to a role in a software team: Analyst, PM, Architect, UX Designer, Developer, Tech Writer, and QA. You get slash commands – /bmad-brainstorming, /bmad-agent-pm, /bmad-dev-story, /bmad-code-review – that guide an AI agent through a structured workflow for each role. The output of each stage feeds the next. The promise: a complete pipeline from idea to shipped feature.
The Pipeline I Followed
Step 1 – Project summary. I had an existing Velo Hire prototype. I used Claude to generate a structured summary of what it did and what problems it solved. As a result, this became the seed. The quality of this summary determined the quality of everything that followed.
Step 2 – Brainstorming (/bmad-brainstorming). The agent ran Values Archaeology and Role Playing techniques, generating 12 ideas across 4 product vision questions. The framing that emerged – “the Tinder model for hiring,” freelancers as active participants not passive listings, “The Monday Morning Exhale” as the admin delight moment – became the language of the PRD. Notably, that coherence was the first sign this was different from one-off prompting.
Step 3 – PRD (/bmad-agent-pm). A 12-step workflow produced a full Product Requirements Document: executive summary, measurable success criteria, user journeys, and 45 functional requirements. The one that mattered most: FR45 – “anonymisation enforced in the database, not only in the UI.” That requirement came from the brainstorm, survived into the PRD, and the architect agent turned it into a concrete FreelancerIdentity / FreelancerProfile schema split. Without the document chain, that decision would have lived in my head and probably gotten cut.
Step 4 – Architecture (/bmad-agent-architect). From there, the architect agent read the PRD and produced the technical architecture doc – stack decisions, data model patterns, multi-tenancy approach, and auth strategy. This became the ground truth all dev stories referenced.
Step 5 – Epics and stories (/bmad-dev-story). Next, the PM agent decomposed the PRD into 9 Epics and 30+ stories. Each story file had acceptance criteria, technical context pulled from the architecture doc, and notes on what the previous story had already built. Sprint status was tracked in a sprint-status.yaml – a real audit trail, not a vibes-based sense of progress.
Step 6 – Code review (/bmad-code-review). After each story, the review agent ran three lenses: Auditor (correctness and security), Blind Hunter (things that look fine but aren’t), and Edge Case Hunter. It produced a triage document – findings classified as CRITICAL, HIGH, MEDIUM, or PATCH – and generated actual .patch files. Story 7-3 had 14 patches. Story 7-5 had 18. Story 8-1 had 9 fixes for precision errors, integer overflow, and race conditions.
What Actually Got Built
In roughly six weeks: Epics 1-7 done (authentication, profiles, gallery, mutual consent, placements, messaging, timesheets), Epic 8 in review, Epic 9 partially complete. The platform handles registration, RBAC, dual-role switching, CV parsing, gallery browse with filtering, introduction requests with consent unlock, placements, daily timesheet submission with screenshot evidence, and automatic earnings calculation. All reviewed, patched, and tracked.
Where It Got Hard
The deferred work file
Every code review produced a deferred work log. By the end, that file covered: no rate limiting on login or upload endpoints, expired password reset tokens accumulating forever, stale JWT sessions for soft-deleted users, a timing side-channel in the login flow, race conditions on concurrent uploads. In practice, most developers have this list. The agents externalised it every time. That honesty alone was worth the process.
Context is not automatic
The harder problem was context loss. Agents don’t have memory between sessions – they read your documents, not your codebase. When the architecture doc was accurate, the stories were excellent. When it was stale, the agent produced confident-sounding work based on outdated information. Story 7-4 generated a critical finding because a migration was written to make a column non-nullable without a backfill – it would have blocked deployment on any live database. The Edge Case Hunter caught it. The fix was two lines of SQL. But the root cause was a doc that hadn’t been updated when the schema changed.
The pipeline is only as good as the documents you maintain. That’s a discipline tax nobody warns you about.
The Honest Verdict
I said I “failed following the AI software development lifecycle.” What I mean is: I started expecting the pipeline to mostly run itself and discovered quickly that it doesn’t. It’s not about automation. The real value is structure.
BMAD forces you to produce the artefacts – PRD, architecture, epics, stories, review patches -that a solo developer would never write alone. Those artefacts compound. The brainstorm makes the PRD better. The PRD makes the architecture more principled. The architecture makes the stories implementable. The code review makes the stories safer.
The failure mode is treating any stage as autonomous. In reality, you are the integration layer. You read the review output, decide which patches to apply, update the docs when the implementation diverges, and brief the next agent with what actually exists – not what the plan said would exist.
What you get is not an AI that builds software for you. You get a structured process that makes you better at building software -with an AI that holds the structure so you can focus on the decisions that actually require a human.For a solo developer, however, that turns out to be quite a lot.
Velo Hire is currently in active development. Epics 1–7 complete, Epic 8 in review, Epic 9 in progress.
Resources:
BMAD Method — GitHub
BMAD for Claude Code (community port)
Claude Code
Next.js
Prisma
Auth.js