Pebellslearn by building
0%
RoadmapsMatrixCoursesSandboxSign in
Guided Build: Sprout, End to End  ›  Lesson

Plan the App on One Page

Checkpoint — Complete App 14 minA full-stack build starts from a one-page plan that turns user stories into tables, tables into REST routes and routes into screens, ordered by what depends on what.

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.

Planning "water a plant"Step 1 of 4
  1. The story

    "I mark a plant as watered, and I can see when I watered it before."

Drills

Answer fast — trust the rule.

quick drill

Which story most directly calls for a new table?

quick drill

Why does "log in" come before "add a plant" in the build order?

quick drill

A table in the plan is used by no story. What should you do?

quick drill

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.

Practice — level up

0/1 solved

Write your answer, then compare it with a rubric and a model answer.

ExplainPlan plant sharing

Plan one new Sprout feature on a single row: 'share a plant with a housemate so both of us can water it'. Give the story, the table changes, the routes and the screens, and explain how it changes the ownership rule in your queries.