Three Ways Software Gets Built

One page, three lifecycles, the spine of this course. You built one project with each; the examples below are yours.

	One-shot	Agile	Waterfall
Your project	The Session-1 page	The same product, grown in sprints (sessions 2 and 3)	Shelf Life multi-platform, iOS app + web page + shared database (weeks 2–4)
When it's right	Small, cheap to redo, one sitting	The product is small enough to steer as you go; requirements can't all be known up front, the product teaches you (most modern software lives here)	Requirements fully knowable up front; change is expensive; multiple platforms or teams must agree before anyone builds; gates matter (regulated industries live here)
How you plan	One good prompt	One slice at a time: backlog, sprint, /spec the slice, /autoplan	Everything first: business case, /spec the whole system, four gates, design, a roadmap per platform, baseline, then never quietly change it
How you test	Break it yourself + /qa-only once	Continuously: /qa inside every slice; the Definition of Done is the gate, run every sprint	A formal test gate at the end, on evidence (/ios-qa, /qa-only, /cso), signed off
How you ship	Once, at the end of the session	Every slice: /land-and-deploy + /canary, as often as every session	Once, at the end, after the gates, then handover pack and closure
What it buys you	Speed. Nothing is faster	Learning: every slice is feedback; what the live product teaches you reorders next sprint's backlog	Certainty: everyone knows what's coming, and there's a paper trail proving what was promised and delivered
What it costs you	Everything past one page, the complexity cliff	Certainty: you genuinely don't know at the start exactly what ships at the end, that's the deal	Speed, and every lesson you could only learn by living with the product arrives too late to change it
When it fails	The moment the project can't fit in one head-sized prompt	When discipline slips: no DoD, no real slices, "agile" becomes "no plan" with a standup	When the spec was wrong and the process ploughs on anyway

The professional's answer to "which one?"

All three. Prototype with one-shots. Sprint with agile while the product is small enough to steer, which is most of it. Reach for waterfall when the requirements are truly knowable and the stakes make wrong guesses expensive: multiple platforms, multiple teams, or a regulator in the room. The skill isn't loyalty to a methodology; it's matching the process to the certainty you actually have. You've now run all three, in order of size, so nobody gets to hand you a methodology as a religion, you've seen what each one trades away.

A PM footnote from your tutor: in industry these have formal names and whole certifications, waterfall's gates come from worlds like PRINCE2 and PMBOK; agile's sprints from Scrum. The vocabulary changes; the trade-offs on this page don't.