C7 · Week 8: Build the ANU system you wish existed
The first full-stack crit, and the week the database gets real.
pick an ANU system you actually deal with — enrolment, timetabling, room booking, course selection, the one that reliably ruins your week — and build the full-stack replacement you wish existed
A university system is all data and state (courses, sessions, bookings, people, and the relationships between them), so it’s the natural vehicle for the week’s material: schemas as ground truth, SQLite, migrations. Don’t rebuild the whole thing; model the slice that annoys you, wire it end to end, and ship it to fly.
The suggested stack is the course scaffold — Astro with a backend, Drizzle and SQLite — the same default the whole full-stack half assumes, so the starter’s spec harness and your tutor’s help are aimed at it. Going off piste works exactly as it did in the static half: reach for another framework (Phoenix, Rails, Django, Go, whatever you fancy) if you’d rather, and carry the extra burden yourself. The spec checks the running app, not how you built it.
The spec
The brief on this page poses the problem and leaves room for your response. The spec is the fixed contract: what your tutor considers when judging whether that response meets the requirements. Some lines can be checked mechanically; the rest call for human judgement.
- the app loads at its *.fly.dev URL by the cutoff
- it models a slice of a real ANU system you actually deal with, wired end to end
- the core flow persists across a reload — create something, and it's still there
- the repo shows the process — commits that grew with the work, a process overview in PROCESS.md, and the week's reflection in reflections/crit-7.md
- you can account for how you directed, grounded and corrected the work