Session 7 of 8
Session 7: Build Two: The Web App & the Shared Backend
A stretch of solo building behind you; Shelf Life runs on your phone. But the spec promised more: the whole household able to see the amber list from any browser. In this session the other two roadmaps come off the shelf, the backend goes up, the web page goes live, and then the moment the whole capstone exists for: you add a yoghurt on your phone and watch it appear in a browser. Three platforms, one product, exactly as sequenced two weeks ago.
Part 1: The backend (~30 min)
Re-fence first, new stretch, same discipline: /freeze to the project folder, and the baseline still rules.
Now the sequencing decision's first step: the database goes up before anything depends on it. The spec already decided the table, this session is implementation, not design. The tool is Supabase, a hosted database your other platforms talk to. Sign up with GitHub (same move as Netlify), then:
Set up Supabase for this project, create the table the spec decided, and put the keys in the
.env.
That last clause should feel familiar: it's the secrets pattern from
Session 2, re-run for this repo, keys in .env, .env in .gitignore,
nothing secret in a prompt or a commit, ever.
Notice what just happened to your architecture: your software now has a backend, data living somewhere that isn't the user's machine, which is the line between an app and a service. It also quietly armed one of the next session's security rules: a database on the internet takes input from anyone, so "never trust input from strangers" stops being theoretical in this session. The full security review comes at the gate; in this session, just notice the door you opened.
Two rules while Claude drives: the schema is one table, the one the spec decided, no improvements, and the keys are the anonymous public ones (your tutor will say why).
Part 2: The web page (~35 min)
Backend up. Now the web roadmap's first stage: the household view, a page that reads the shared table and shows the green/amber/red list, plus whatever the spec said it does (and nothing it said it doesn't).
Brief the agent from the spec and plans/roadmap-web.md, let it build,
then check it with /qa, and ship it with the machinery you already
own:
/setup-deploy → /land-and-deploy → /canary
Pause on how unremarkable that felt. The deploy chain you learned inside
agile works identically inside waterfall, the tools don't belong to a
lifecycle; the cadence does. What's different is upstream: this page's
scope was decided two weeks ago, reviewed by four gates, and sequenced on
a roadmap. (One waterfall formality stands: /qa fixing things on the
spot is fine mid-build, but the next session's test gate will want a recorded
pass, findings written down, /qa-only style, because gates take
evidence.)
Part 3: The wiring (~30 min)
Two platforms believe in the same table; time for the third. The iOS roadmap's final stage has been waiting for in this session: point the app at the shared database, its local store syncs to Supabase, per the spec.
Then the demo you've been building toward for two weeks. Phone in one hand, browser open next to it:
Add a yoghurt on the phone. Watch it appear in the browser.
That half-second is a real production stack working, native app + web front end + shared database, the architecture most of the software you use every day is built on. Three things you already knew how to build; the connecting is what you learned in this session, and it's the skill the industry runs on. Run /ios-qa once over the synced app, evidence, as always, and commit.
Part 4: Project memory (~15 min)
Your capstone now spans three tech stacks, and it has outgrown what a lean CLAUDE.md should hold. One-time setup:
/setup-gbrain
It builds the project a long-term memory, a knowledge base the agent queries instead of re-reading the whole codebase into its window every session. It's the CLAUDE.md principle, industrialised: index, not archive, at codebase scale. Each build session now ends with /sync-gbrain to keep it current; it's in the homework rhythm from this session on.
/context-save. One stretch of building left; next session, the gates.
What you just learned without noticing
Client–server architecture, the app and the page are clients, the database is the server, and the line between they are where most real engineering lives. Plus integration: the discipline of connecting separately-built pieces, each verified before the next depends on it, which is why the sequencing decision existed, and why big projects have integration phases with their own names and their own budgets.