The familiar MVP trap is to build quickly for a demonstration, then discover that everything must be rewritten when real users arrive. We avoid it by deciding early which parts are temporary and which parts must survive growth.
Weeks 1–2 focus on critical user journeys rather than screens. Every journey is tied to a commercial or technical risk. Anything that does not serve one of those journeys is documented and removed from the first release.
Weeks 3–6 establish the durable skeleton: data model, API, authentication and deployment. These elements may still be running in three years, so they are built cleanly with tests and monitoring. The interface remains deliberately simple.
Weeks 7–10 end with a usable version every week. Feedback arrives while change is still inexpensive. Weeks 11–12 are reserved for load testing, security review, logging and recovery planning.
The result is not a throwaway prototype. It is the first operating version of a real product, built on foundations that can absorb the next release.
