BMad Method, not magic
Vention, a global software engineering company, is a founding partner of the BMad Method, an open-source framework maintained by BMad Code, Brian Madison’s organization. We use the method in software delivery, adapt it to each project, and share what we learn to help guide its development.
Published: 23.10.2026
Last updated: 23.10.2026
What is the BMad Method?
The BMad Method is an open-source, AI-assisted software development methodology that gives teams a structured way to work through product planning, requirements, architecture, implementation, testing, and documentation.
It organizes AI-assisted work around defined roles, workflows, and shared project documents. Product, architecture, development, and QA work from the same project context, with decisions and requirements available at each stage.
For the current workflow, roles, and terminology, see the official BMad Method documentation.
Vention as a founding partner of the BMad Method
Vention has been a founding partner of the BMad Method since October 2026, working with BMad Code, the organization that maintains it.
As a founding partner, Vention applies the method in software delivery across product, architecture, development, and QA, and shares practical experience with BMad Code to help shape its development.
In practice, engineers and product stakeholders work from shared requirements, architecture decisions, development stories, and other project artifacts. Everyone has access to the same context as work moves from planning through implementation and validation.
For clients, the method is adapted to the project’s standards, existing codebase, and tooling. Vention engineers adjust workflows to fit how the project runs and what it needs.
We also bring our practical delivery experience to the partnership, sharing where the method helps most, where a lighter approach works better, and where challenges remain. BMad Code uses that feedback to develop the method further.
How Vention applies the BMad Method
The BMad Method organizes AI-assisted development around defined workflows, specialized roles, and shared project artifacts that carry context from one stage to the next. At Vention, product managers, architects, developers, and QA engineers work from shared requirements, architectural decisions, and development stories throughout the delivery process.
On an enterprise HR-tech project built with the BMad Method from day one, we use approximately 70 BMad skills, including 12-15 custom skills adapted to the project’s architecture, development standards, and recurring workflows. The skills support each role and connect the work through a shared project context.
Each role builds on the work completed earlier in the workflow:
Role | How the role contributes to the workflow |
|---|---|
Product manager | Shapes and structures requirements and development stories, creating a product context for the work that follows |
Architect | Translates requirements into solution designs and technical decisions that guide implementation |
Developer | Implements development stories using the requirements, architecture, and other project context produced earlier in the workflow |
QA engineer | Reviews requirements and prepares testing scenarios, bringing validation into the workflow before and alongside implementation |
The outputs created across these roles become shared project artifacts, such as requirements, development stories, solution and architecture documents, testing scenarios, and technical documentation. Rather than remaining within individual AI conversations, these artifacts preserve decisions and project context, allowing them to be reused by other team members and in later stages of the workflow.
Everyone involved in the project can see:
- The current stage of the work
- What has already been decided
- Which requirements and stories are ready
- How the proposed solution should work
- What still needs validation or documentation
- What happens next
Where the BMad Method works best for Vention
The right level of BMad Method adoption varies by project.
We’ve found the strongest fit where defining requirements, architecture, and project context helps guide implementation. On existing systems with extensive undocumented context, applying the full workflow to every task can add more overhead than value.
Where Vention sees the most value in BMad | Where our teams have found less return |
|---|---|
New product development where requirements, architecture, and implementation can be structured together from the start | Immediate wholesale transformation of very large legacy systems, where assembling sufficient project context can become expensive |
MVP development, where teams need to move from an idea to a buildable product without losing decisions between stages | Brownfield day‑to‑day changes that may not justify a full methodology workflow for every task |
Feature and service rewrites that require substantial exploration before implementation | Design consistency, where a separate source of design truth needs to be established and maintained |
Modular modernization, where a bounded area of an existing system can be given enough context | Large teams working simultaneously in one repository, where coordination requires additional practices and controls |
Complex discovery where product, functional, non-functional, architecture, and technology decisions need to connect | Contexts where AI‑generated implementation can weaken engineers' familiarity with the codebase if knowledge retention is not managed deliberately |
Prototypes intended to become real products, rather than isolated demos | AI-intensive workflows where token consumption becomes material enough to require active cost management |
We’ve seen these patterns in Vention’s delivery work. The right level of adoption can also change as a project progresses.
For example, on the Kafene project, Vention used the BMad Method during discovery and requirements planning for a major service rewrite. We brought together two previous rewrite attempts, design discussions, incident history, and existing implementation documentation, then organized that context into a product requirements document (PRD) covering success criteria, user journeys, phases, and scope.
With that foundation in place, implementation moved to a lighter approach. The BMad Method supported the deeper exploration and requirements work; OpenSpec supported day-to-day development with more focused design, specification, and task artifacts.
When evaluating the BMad Method, we consider where in the delivery process its added structure is worth the effort.
How Vention adapts BMad to your environment
Vention teams adapt the BMad Method to each project’s needs. Depending on the work, we can use it within your existing AI environment, combine it with lighter approaches at selected stages, or customize workflows and skills to fit your engineering practices.
On one engagement, Vention works within the client’s existing Kiro-based environment. A Vention engineer uses the BMad Method to organize development work, then adapts the resulting artifacts and workflows to the client’s tools and terminology. The client keeps its established setup.
For an enterprise HR-tech project, we customized the method around the product’s architecture, development standards, and recurring workflows. The project uses approximately 70 BMad skills, including 12-15 custom skills. Product, architecture, development, and QA follow a shared workflow adapted to the project’s engineering requirements.
You can keep your existing tools and processes. We integrate the BMad Method into your delivery environment and use it where the added structure helps most.
How the BMad Method fits into Vention’s AI SDLC approach
The BMad Method supports Vention’s broader approach to AI SDLC transformation, which integrates AI throughout the software development lifecycle. We use the method to organize AI-assisted work around:
- Shared requirements and specifications
- Project context available across development stages
- Coordination across product, architecture, development, and QA
- Defined workflows for planning, implementation, and validation
- Human review and quality controls
BMad provides structure for AI-assisted development. Vention’s engineers review the work, validate the results, and remain accountable for quality throughout delivery.
How Vention uses the BMad Method in product design
At Vention, beyond just development, we also use the BMad Method earlier in the product lifecycle. Designers can work through requirements, explore ideas, and build prototypes with the broader product context available throughout.
Viyaleta Apalaika, UI/UX Designer at Vention, uses the method on a project that brings two HR assessment products into a single platform, including one built on legacy technology. Alongside faster design work, she sees a clearer connection between requirements, design decisions, and implementation, with room to explore alternatives and question the initial product direction.
“There isn’t one perfect workflow for design yet. Sometimes I start with the design and use AI to visualize an idea, which can reveal requirements we hadn’t considered. Other times, I start with the requirements and use AI to generate HTML prototypes from the PRD.
AI reduces execution work, but it makes judgment more important. AI is very good at generating HTML, following an existing style, and recreating established flows. But creating something new still depends on a deep understanding of the product and the decisions behind it.”
AI can help move work from requirements through design and implementation faster. Designers and engineers remain responsible for understanding the product, questioning assumptions, and deciding what to build.
The BMad Method across Vention projects
We adapt how much of the BMad Method we use and where we use it to the product, existing codebase, delivery environment, and the structure the work requires.
Across Vention projects, BMad supports development from start to finish or specific stages such as discovery. It also helps people work from a shared project context, fits within a client’s existing AI environment, and can be used alongside lighter approaches.
Enterprise HR-tech: Building with BMad from the start
Project context
Vention began with a new product and built the development process around the BMad Method. Product management, architecture, development, and QA needed to coordinate their work and keep the project context available at every stage.
How Vention applied BMad
The project uses approximately 70 BMad skills, including 12-15 custom skills adapted to the product’s architecture, development standards, and recurring workflows.
Product managers define requirements and development stories. Architects use that information to design and assess solutions. Developers implement the stories using the agreed requirements and architecture, while QA engineers review requirements and prepare test scenarios.
Planning, architecture, implementation, testing, and documentation follow a connected workflow. Requirements are defined early, solution designs are documented before implementation, and everyone works from the same project context.
Outcome
According to the project team, a substantial set of new features that previously could take approximately one quarter to release can now be delivered in around three weeks.
The Vention team attributes the acceleration to more than faster coding. Earlier requirements definition, documented solution decisions, automation of repetitive planning and documentation, shared context between roles, earlier QA involvement, and custom skills for recurring project tasks all reduce time spent on preparation, coordination, clarification, and rework.
Kafene: Using the BMad Method for a critical service rewrite
Project context
Kafene is a largely brownfield project with limited existing documentation, making full BMad adoption less practical for routine development. At the same time, larger initiatives can require substantial exploration before engineers have enough reliable context to make implementation decisions.
How Vention applied BMad
Vention used the BMad Method during discovery and requirements planning. We prepared five input documents covering two previous rewrite attempts, summaries of design discussions, service incident history, and the existing implementation design. Those documents provided the project context needed to explore different approaches to the rewrite.
We then used the BMad Method to organize that material into a product requirements document (PRD) covering success criteria, user journeys, delivery phases, and the scope of each phase. A technical design document followed, with diagrams and implementation phases.
Once discovery was complete, developers moved to OpenSpec to create design, specification, and task artifacts for implementation. The project kept its existing flexible development process.
Outcome
The technical design went through engineering review and several revisions before multiple developers adopted it as their primary guide for the rewrite.
For Vention, the project showed the value of selective BMad Method adoption. The method gave us the structure we needed to consolidate fragmented context and establish a direction for the complex rewrite, while lighter tooling supported day-to-day implementation.
Healthcare claims: Connecting requirements to technology decisions
For a healthcare technology company developing a claims management platform, Vention applies BMad early in the development lifecycle, particularly during requirements gathering and technology selection. The workflow helps the team move from business goals to functional and non-functional requirements, then to architecture and technology recommendations, creating a traceable connection between what the product needs and why a particular technical approach is proposed.
BMad adoption is still developing on the project, so Vention is not attributing quantitative delivery outcomes to the method at this stage.
Wealth-management infrastructure: Coordinating AI-assisted delivery
For a wealth-management infrastructure client, Vention uses the BMad Method across brainstorming, planning, documentation, and implementation. We incorporate development stories, solution documents, technical documentation, planning materials, and structured brainstorming outputs into the delivery process.
Product stakeholders, architects, developers, and QA engineers can see which decisions have been made, which stories are ready for implementation, how the solution should behave, what needs documenting, and what comes next.
Working within a client’s existing AI environment
On another engagement, Vention uses the BMad Method internally to organize development work within the client’s existing Kiro-based environment. A Vention engineer adapts the method’s outputs to the client’s preferred tools and terminology.
The BMad Method gives us structure for development while the client keeps its established AI environment and workflows.
BMad Method insights from Vention
The BMad Method changes quickly, and a single page cannot usefully cover every implementation question. These guides go deeper into the areas Vention teams encounter in delivery.
Running the BMad Method beyond small teams
BMad can be relatively straightforward when one developer controls most of the context. For Vention teams, applying it across multidisciplinary delivery introduces a different set of challenges. Requirements, architectural decisions, development stories, and testing context need to move consistently across roles, while the team needs to maintain a shared project context and integrate BMad workflows into existing engineering processes.
This guide examines how Vention scales BMad from individual AI-assisted work to team-level delivery. It explores how Vention teams structure shared context, coordinate work across specialized roles, and adapt BMad workflows to support collaboration throughout the development lifecycle.
BMad Method vs. Spec Kit, OpenSpec, Kiro, and other approaches
The BMad Method can sit alongside other approaches to AI-assisted development. Different methods and tools offer different levels of structure, context management, planning, and flexibility, making some better suited to particular stages or types of work.
This comparison looks at the BMad Method, Spec Kit, OpenSpec, Kiro, and other approaches: where their workflows overlap, where they differ, and why Vention may combine them on a project.
BMad Method and enterprise governance
As AI-assisted development expands across larger teams, developers need a consistent way to share project context, review decisions, and check AI-generated outputs against engineering controls.
This article explains how Vention uses the BMad Method to structure multidisciplinary delivery. It covers how shared context and defined workflows help coordinate product, architecture, development, and QA; preserve traceability as decisions move into implementation; and establish points where specialists review and approve outputs.
From vibe-coded prototypes to production
AI-assisted development can quickly turn an idea into a prototype. Preparing it for production requires further work. Once real users, data, and traffic are involved, requirements such as authentication, authorization, security, scalability, error handling, testing, monitoring, and operational ownership need closer attention.
Drawing on Vention’s experience with AI-built products, this guide explains how we use the BMad Method to assess an existing prototype, reconstruct its original product and technical context, and define production requirements. It then shows how we evaluate each component to decide what can stay, what needs refactoring, and what needs rebuilding, before turning those decisions into architecture updates, implementation stories, testing, and release preparation.
BMad Method costs, overheads, and ROI
Built on Vention’s experience with AI-assisted delivery, this guide examines costs that are easy to overlook: documentation maintenance, handoffs between roles, context re-injection, API usage, model tiering, and context indexing. It also covers ways to reduce overhead by choosing lighter workflows and models where the full BMad Method process adds little value.
The article explores when the method’s added structure can justify the investment and when a lighter approach may offer better returns. It compares costs and potential ROI across complex, long-running projects, prototypes, and smaller development tasks to help readers decide where and how extensively to use the method.
Using the BMad Method with an existing codebase
Brownfield development presents different challenges from applying the BMad Method to a greenfield product. Missing requirements, undocumented architecture decisions, fragmented project knowledge, and unfamiliar codebases can make it difficult to assemble enough context for AI workflows.
We’ve worked through these challenges on existing products. In this article, we explore when deeper discovery, requirements planning, and architecture work justify the effort, and where lighter approaches may be more efficient.
We also explain how we use the BMad Method selectively alongside other AI-assisted development approaches, adding structure where it helps while working within the established codebase.
FAQ
What changes for a client when a Vention team uses BMad?
The main difference for clients is greater structure and traceability behind delivery. Requirements can be defined earlier, technical recommendations can be more clearly tied to product needs, and decisions made during planning and architecture can provide clearer input for implementation and validation.
Depending on the project, we can adapt the BMad Method to your existing tools, terminology, engineering standards, and delivery processes.
The impact varies by project. For a healthcare claims client, Vention uses the method to connect business goals and functional and non-functional requirements with architecture and technology recommendations. Each recommendation has a clearer rationale tied to what the product needs.
Does Vention require clients to use BMad?
No. We assess whether the method’s added structure is useful for each project.
On some projects, we use it throughout the delivery process, from requirements and architecture through development and QA. On others, we use selected workflows for discovery, planning, or complex work, then take a lighter approach to routine implementation.
Kafene is one example of this selective model. Vention used BMad to structure the exploration and requirements work for a major service rewrite, then moved to OpenSpec for more granular design, specification, and implementation activities.
The decision is therefore based on the project’s needs, the existing codebase, the delivery environment, and the level of structure the work requires. Vention fits the method to the engagement rather than requiring the engagement to fit the method.
How is the BMad Method different from giving developers AI coding assistants?
An AI coding assistant typically helps a developer with tasks such as generating code, explaining an implementation, or debugging an issue. When that work happens in separate prompts or chats, the context can stay with the individual developer.
The BMad Method organizes AI-assisted work across the development lifecycle through defined workflows, specialized roles, and shared project artifacts. Requirements guide architecture decisions, which provide direction for implementation. QA uses the same requirements and technical context to validate the work.
Product, architecture, development, and QA can build on decisions already made at earlier stages.
Can the BMad Method be introduced to an existing project?
Yes. Vention can introduce the BMad Method at any stage of a project. We first gather reliable context about the existing system, including its requirements, architecture, codebase, previous decisions, and known constraints.
Our engineers then apply relevant workflows where more structure would help, such as clarifying requirements, planning a major rewrite, reviewing architecture, or preparing for implementation. Depending on the project, we can use selected workflows alongside your existing engineering practices and lighter AI-assisted tools.
Can Vention use only part of the BMad Method?
Yes. We can use selected workflows at specific stages of the delivery process. How much of the method we use depends on the project, the existing codebase, and the structure of the work.
Ready to give AI-assisted development some structure?
Vention is a founding partner of the BMad Method. We'll help you apply it where it pays off and fit it into the tools, codebase, and delivery process you already have.