PRD lifecycle after MVP — new PRD or edit the existing one?

[AxelBriche]

Hey! First off, great work on BMAD, been using it with Claude Code on a restaurant SaaS and the planning phase has been really solid.

Now I'm hitting a crossroads. My MVP is shipped (site builder, digital menu, dashboard) and I'm about to tackle the next big chunk, CRM, loyalty, reservations. But I'm not sure how the PRD is supposed to evolve at this point.

Do I use Edit PRD to keep growing the same document? That feels clean for things like the domain model and success criteria that naturally build on each other. But I'm worried about context bloat down the line (the issues raised in #46 and #1471 resonate a lot).

Or do I create a fresh PRD for each major milestone and archive the previous one?
Leaner context for agents, but then the architecture and domain model get scattered across multiple docs.

A few specific things I'd love your take on:

• What's the intended split between Edit PRD and Create PRD after the first delivery?
• When a PRD gets big (500+ lines), is sharding enough or is it better to split by milestone?
• For architectural decisions that carry over — is project-context.md the right home for those?

Thanks!

[mcharouk]

i don't know the answer on that. I'll appreciate too that BMAD team clarifies their point of view on the post mvp next iterations.
My thoughts is that the prd in essence is a consolidated spec.
We should have the possibility to append to it light prds, that refers to the base one.
At some point, we also should have the possibility to consolidate these light prds into the base one, something similar that what openspec does i think.

Also i was questioning my self on user stories. I think once they are done, they should be deleted or archived.
Probably its better to archive them on a tool like JIRA that have much better search capabilities. In fact, a markdown file is not a database :-). Only ready to dev user stories should remain until they are done.

I think epics may stay because usually there are only a few, it's good to reuse them.

On the long run, i think that prd and architecture boundaries should be kept contained, because if you are building a monolithic application with a monolithic prd and architecture, you we will end up with very big documents, and the agents will get lost.
Probably micro service architecture is more suited to that, or monolithic that are clearly separated with different modules.

I didn't see anything on the roadmap on that topic so i hope there at least some debates, because to me, that's clearly what is missing the most in that method.

[danicatalan00]

My guess would be to archive the MVP PRD.md (PRD-archived-YYYY-MM-DD.md) and create new PRDs for big milestones as you go along. And yes persist relevant info about arquitecture in project-context or the docs themselfs.

Keep in mind that I haven't grown any geenfield project passed MVP so I don't claim to have a definitive awnser as to what results in best performance. I mostly use BMAD in my company as brownfield only throght quick-spec/quick-dev flow

[bmadcode]

PRD, Epics and stories are all meant to be ephemeral point in time documents. After an MVP is completed @AxelBriche its best to run the document project process after removing or archiving the legacy planning/implementation documents. the document project process will populate good docs that can then be evolved over time as future efforts are taken on. additionally, when you do your new PRD pr product brief - or just individual feature with quick dev - the generated docs will help with the ground truth for new efforts.

Best of luck!