Plan the App on One Page
You now know every layer. The hardest part of a first full-stack build is often knowing where to start: open the editor with a vague idea and you end up with half a schema, three unconnected screens and no working feature. A one-page plan, made before any code, turns the idea into tables, routes and screens you can build in order.
The rule
Stories become tables, tables become routes, routes feed screens.
1. Stories. Write what a person can do, in plain words, one line each. Sprout's first version:
- Log in and out.
- See my plants, thirstiest first.
- Add, rename, reschedule or remove a plant.
- Water a plant, and see when I watered it before.
2. Tables. Underline the nouns: user, plant, watering. Each becomes a table, and the details in the stories become columns. "How often" gives plants.water_every_days; "when I watered it before" needs a history, so waterings gets one row per watering with plant_id and watered_on. Every plant also carries an owner_id, because "my plants" appears in the stories.
3. Routes. Each story's verb on each noun becomes a REST route. 4. Screens. Each route is called from somewhere a person can see. Put it all in one table:
| Story | Table | Routes | Screen |
|---|---|---|---|
| Log in and out | users |
POST /api/login, POST /api/logout, GET /api/me |
Login page |
| See my plants | plants |
GET /api/plants |
Dashboard |
| Add, change, remove | plants |
POST /api/plants, PATCH and DELETE /api/plants/:id |
Plant form |
| Water, see history | waterings |
POST and GET /api/plants/:id/waterings |
Water button, plant page |
5. Build order. Order the rows by what depends on what. Every plant route needs to know the owner, so login comes first. You cannot water a plant you cannot add, so adding comes before watering. Extras such as reminder emails and plant photos wait until the core rows work.
That page is the whole plan. It fits on one screen, a teammate can check it in five minutes, and each row becomes one slice of work in the next two lessons.
The shortcut
Every story must fill a row, and every table must appear in a row. A story you cannot turn into a table, a route and a screen is too vague, so rewrite it. A table that no story uses is guesswork, so delete it until a story needs it.
The story
"I mark a plant as watered, and I can see when I watered it before."
Drills
Answer fast — trust the rule.
Which story most directly calls for a new table?
Why does "log in" come before "add a plant" in the build order?
A table in the plan is used by no story. What should you do?
Which is the right route for "see the watering history of plant 7"?
Remember
- Stories become tables, tables become routes, routes feed screens.
- Shortcut: every story fills a row; every table appears in a row.
- Trap: starting with code, or designing tables no story needs. Order the rows by dependency.
