Module 3: Initial UI Mockup
Once the product direction is stable enough, the next question is architectural: what parts of the UI are common, and what parts belong to individual screens? This lesson starts answering that by defining the form hierarchy for the initial app-maker mockup.
That hierarchy matters because the app maker already has a recognizable shell: a navigation structure, shared editing affordances, and a preview-oriented top-level experience. If every screen were built independently, that shell would quickly drift. A shared base form is the right tool for keeping navigation and common editing patterns consistent.
The lesson also makes a pragmatic point about reuse that is easy to miss. Copying an existing model or structure is often the right first move if it gets you to a working baseline quickly. Generalization should come from repeated need, not from the fear of duplication on day one. That is especially true in builder-style products where the real shape of the domain is still being discovered.
The result is a simple but useful structure: one shared navigation-oriented base, a small number of top-level forms that inherit from it, and one-off forms like dish editing that are allowed to stand on their own because their responsibilities are different. That split keeps the code honest about which UI concerns are shared and which are truly local.
So the architectural lesson here is not complicated, but it is important. Establish a common shell for the parts of the product that behave alike, and do not force unrelated screens into that same abstraction just to look tidy.