Good question! It serves as a bootstrap for each module design file (effectively a deeper expansion of what is defined in the PRD). Once you have (at least) design files for each module, PRD is no longer necessary. It usually ends up being inaccurate after the brainstorming phases, which change fundamental bits of the wiring that the initial brainstorm wouldn't cover.
This article makes me want to finally start the dashboard project that's been living in my procrastination backlog for years.
One of the main blockers has been the cost of larger, high-resolution e-paper displays. I was considering using an ESP32 to drive one, but the display pricing always felt like the convenient excuse.
Reading through the helpful comments here, I'm starting to think there might be more viable options than I assumed, especially in terms of display size trade-offs and keeping the overall cost reasonable.
I’ve been procrastinating on one as well, but I can recommend the Inkplate devices, which come with a ESP32, battery, and a case (optionally); handy platform to hack on. (If only it were so easy to finish the project…)
In your workflow, what happens to the `PRD.md` after the initial module planning phase?
Is it mainly used to guide the decomposition into modules, or does it continue to play a role during implementation?
I might have missed it, but I'm curious wether it's just a planning artifact or an active part of the coding loop.