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.

FunctionalityResponsive designAccessibility reviewError handlingTestingGit historyREADMEDocumentationDeploymentScreenshotsTechnical explanationA working live URL