Projects
Work you keep, not exercises you throw away.
Two kinds of project. The first are built with you, growing lesson by lesson through a course. The second hand you requirements and nothing else, which is where a student becomes a developer.
Portfolio Projects
One per course, built across every module rather than bolted on at the end. Each one carries forward, so the site you build in the first course becomes the application you deploy in the last.
Course Capstones
Five briefs that run alongside the JavaScript & Python course, rising in difficulty with it. No tutorial: you get requirements and acceptance criteria, then decide the structure yourself. Each has one graded core function, so you get an objective signal that the hardest piece works before you build outward.
Capstone Projects
Four strands, three briefs each. These are harder than the course projects and far less guided, and every one was chosen to be worth showing somebody. A reviewer has seen a hundred todo lists. None of these is one.
Frontend
Interface work where the hard part is not the layout. A game with a real opponent, audio that stays in time, and a visualization that works for somebody who cannot see it.
Backend
No interface to hide behind. Money under concurrency, delivery that survives failure, and an API somebody else can use without asking you a question.
Full-Stack
Both halves, and the join between them. Moderation and trust, real-time state shared across devices, and an application that works with no signal at all.
Independent
No brief. You write the specification, and the specification is the part being assessed.
What portfolio-ready actually means
It is a measurable state, not a phrase. A project does not earn the label until every one of these is true, and that applies to a course project exactly as much as a capstone.