Best Practices for Continuing from MVP?

[Shoot2Skoot]

Hi,

First of all, thanks so much for this. Seriously game-changing results.

I’m now on my third “phase” of my project. I created an initial MVP, drafted a phase 2 PRD and implemented those epics.

As I continue with my third feature expansion, the agents are starting to lose connection to the initial plan.

for instance, my architecture agent just attempted to recreate testing_strategy and coding_standards, making significant suggested changes.

It seems to be stuck in the mindset that I’m starting a new project rather than building off an existing one.

Should I be instructing certain agents to modify existing docs rather than creating new ones? Should I be organizing phases into subfolders? What has worked best in your case for moving from MVP to defining what the next MVP is and taking their project there?

[DanielFerreiraJorge]

I second that! This is the problem I run with most "frameworks" for AI aided coding. I'm a developer with 30 years of experience in systems architecture, event driven architecture, web development, microservices, etc, and I'm just now incorporating AI agents in my dev workflow.

The most important thing in software dev is the ability to evolve the software by extending it. No meaningful piece of software is planned perfectly from the start.

So far, everything I saw in various methods of agentic coding (like BMAD), is a very good way to produce somewhat working MVPs. But there is no clear path to incorporate new requirements when the coding agents started the coding process. After the initial plan is finished, there is no easy way to evolve the software by adding new requirements to the original project.

Maybe we need agents specifically to produce new feature requirements, architecture, etc, for an already existing plan. These agents should be aware of what is currently implemented. Maybe, we could add the current project documentation to a RAG system and instruct these "aditional features planner" to retrieve the current project status at the moment the are creating the new plans. Than, the new plan should be incorporated into the master plan as if it was originally planned in the first iteration. I don't know.

And please, don't take me wrong. I think BMAD is remarkable and I've had very good results using it. I'm just trying to suggest possible improvements.

[Shoot2Skoot]

Yea. I love the system, and it's been amazing as someone with limited agile experience. This has already introduced an entirely new workflow and way of documenting projects I wouldn't have come up with on my own.

As I grow my project, I'm noticing that the agents fail more and more. Maybe it's a problem with my Cursor setup or the way I'm defining context in the chat, but the agents now seem to be failing to follow even their core instructions. (I am starting new chats at each agent handoff to reset the context.) I've had agents:

• Create docs without using the templates.
• When my project already has Epics 1-8, it decided to just start over with Epic 1 and add a suffix to all of them.
• It no longer saves docs in the correct folders.
  • I've had it save stories in the epics folder, make new top level folders instead of docs.
• It frequently rewrites docs and ignores the previous content.

It worked AMAZINGLY for the first 2 iterations. (4 Epics each) Then towards the very end of my last epic in iteration #2, it seemed to totally lose it. I had to abandon BMAD for my 3rd iteration, which is a shame because it truly was the most successful project I've done so far. It's amazing how little time I spent debugging and fixing errors.

Hope others have some good ideas and maybe I'm just missing some things.

[bmadcode]

Yeah - this really is the next big thing to solve - not just related to this method - but something we are also trying to figure out in the day to day of large brownfield enterprise codebases. Cursor actually just posted a decent write up on this very challenge: https://docs.cursor.com/guides/advanced/large-codebases

It all comes down to prompting and providing context at the end of the day - thats really what any of this is, greenfield or brownfield. When there is less code, the LLM has more of a chance of not it not losing stuff in its context and finding where it should put things from documents and seeing other code that exists.

I think as projects grow what I have seen work is the need for a lot more guidance - which means documentation and also a decent understanding of the project.

Architecture of the project can really start to matter also. Small microservice, smaller files, different patterns.

In reality day to day, not everything in real world requires new PRDs and epics - generally for example if you have an MVP and then some ideas to follow on, I will have a pretty good idea of the project at that point and be a lot more prescriptive in the feature.

Not sure if any saw the news of AlphaEvolve today - https://deepmind.google/discover/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/ - but it highlights what I think we all feel - and why the ideas of BMAD resonate - its not hands off process -its iterative working with the AI to come up with something better than it would come up with on its own. Interactive mode always will be better than just allowing it to yolo and come up with a plan - and as you learn more on your own journey and start to learn what works and what doesn't, you get better at guiding it.

Hmm - I am kinda rambling on, but really all to say - I think its solvable but its not gonna be 1 size fits all - and over time also context windows and models will continue to evolve...

[Shoot2Skoot]

These are all really good points and insights. I think it’s a fair point that as I got further into my project I started to trust the agents more and give them less context with each ask. I suppose I was also asking them to do a bit more on their own.

Maybe I might just need to cleanup the docs, refocus, and be a little more deliberate in my context management.

A few question I have that might help.

• As your projects get larger, do you clean/reorganize docs at all to make context easier to manage? Remove certain files?
• Are there certain docs you always include?
• I know the agents are supposed to allow us to break away from rules, but do you still create some rules when coding?

Thanks again for all your work on this @bmadcode. I have been singing praises and sharing with everyone I know. Even non-coders could benefit heavily in having an AI assisted product development process and this is the best one I’ve found.

[bmadcode]

Good questions and those are easier to answer - probably about to ramble on less LOL.

1 - yes 100% - and in the new video I am working on showing the actual coding of the app - I actively refactor as I go also. No matter how well planed and organized, the ai (at least the current cursor relatively cost efficient models) will still do dumb things.

I am starting to feel like the janitor cleaning up after the ai dev LOL

2 - coding standards (which the dev should be loading) and the source tree are the biggest. There is one other thing that I have found extremely effective but have not tried it enough to see if its confirmation bias - but if you get a good organization of code going - having the ai put and maintain readme's in folders I have found the agent will read them on its own when it finds the folder it thinks its should add code too - but again, I am not sure or convinced 100% this is super reliable but when I did it for 1 project, it seemed to help.

3 - in cursor - yes - for a few reasons, editing the custom modes in the cursor UI is TRASH. plus with rules, its much faster and easier to add quick 1 off things to see if it helps. and also...

Also - depending on the rule and stage of the project, rules can be removed as the codebase grows and it has enough surrounding context of patterns for the agent to follow.

Another nice thing with rules - they generally do not contribute to vendor lock it - yes all of the products have a different file location or file naming, but the content is generally 100% transferable (as opposed to say the format of mcp tool config or custom modes)

Thank you so much again @Shoot2Skoot :)

[clarsen]

FWIW, I'm starting on phase 2 planning (2 epics) after finishing the first MVP (5 epics plus 1 "post-MVP" adhoc-epic without the full planning process) and asked /bmad in the IDE to:

The project MVP is now implemented and I want to archive all the non-essential documents in docs/archive so that they do not clutter the IDE context. E.g. epics, stories. I want to prepare the docs directory for the next phase of development.

it moved epics, stories, project-brief.prd.md, key-references.md into a docs/archive/{epics,planning,stories} directory structure with a summary README.md

When then asked

will this docs/archive organization work as I iterate adding more sets of plans, epics and stories over time?

it moved/created a docs/archive/{_phase_template,mvp-phase-2025-06}/{epics,planning,stories} structure with README.md on how future planning/implementation artifacts should be organized.

I'm not adding docs/archive to .cursorignore or .cursorindexingignore yet. I'll feed in the other assets like architecture.md, data-models.md, etc. to inform the later stages of planning when I get there.