What a capstone is and what it is not
Artifact: A clear frame for the next two to four weeks of work
1. The promise
You'll know what the capstone is for, what it isn't for, what "good enough to ship" looks like, and why the next two to four weeks of your life go into one project rather than three.
2. The mental model
A capstone is the single shipped project you take to interviews. End-to-end. Public. Defensible. It's like the one dish a cook brings to a job interview at a restaurant. The dish doesn't have to be the most complicated dish in the world. It has to be cooked end-to-end, plated honestly, and the cook has to talk about every decision they made.
(DIAGRAM: capstone vs startup vs side project — Venn-style annotated SVG — three overlapping circles, "capstone" labelled inside the small intersection that is "shipped, defensible, finite")
What a capstone is, in three lines:
- A small, real, end-to-end app.
- Shipped to a public URL a stranger can reach.
- Backed by a Git history and a written post-mortem.
What a capstone is not:
- A venture-funded startup.
- A "platform" with twelve services.
- A Kubernetes cluster.
- An idea that has to be original.
The honest size sits between "blog with comments" and "habit tracker with auth and a payment page". Big enough to need a database, auth, deploys, and tests. Small enough to ship in two to four full-time weeks.
A walking skeleton is the smallest end-to-end version of the app that runs in production. Often ugly. Always real. You build it in sprint one.
A post-mortem is a short written reflection on a finished piece of work. What worked. What didn't. What you'd do differently. You write it after the app ships.
3. You do it, with me
Open a browser. Look at a real junior-developer portfolio page on a personal site.
(SCREENSHOT: a real junior-developer portfolio page on a personal site — full window — one project card highlighted)
Look at the project card. One title. One screenshot. One link to a live URL. One link to a GitHub repo. That's the surface a hiring manager sees first.
Click through to the repo. Read the top of the README.
(SCREENSHOT: a GitHub repo README at the top of the page — full window — the badges, the one-line description, and the live URL link highlighted)
Notice what's there: a badge or two, a one-line description, a live URL link, a screenshot. Notice what's not there: a roadmap to "version 2.0", a list of investors, a pitch deck. Capstones don't have those.
Now look at the kind of message a hiring manager sends when a portfolio works.
(SCREENSHOT: a hiring manager's LinkedIn message asking about a portfolio project — anonymised — message text highlighted)
The hiring manager isn't asking about the framework. They're asking about a decision. That's the interview the capstone earns.
Write down, in your notes app or on paper, the answer to one question: what would you build if you had to convince a hiring manager you can ship?
You don't have to commit to the answer yet. 29.1 picks the project properly. This is the framing question.
4. What you should be seeing
Three pictures in your head:
- The capstone is one shipped app. Not three half-built ones.
- The size is small-to-medium. Auth, a database, deploys, tests. Not Kubernetes.
- The output is a portfolio piece. Live URL, repo, README, post-mortem, demo video. All four.
If you can list those three from memory, you're done with this unit.
5. Common stumbles
- You pick a startup idea and try to build it. Two months later there's no app. Pre-empt: this is a portfolio piece, not a company.
- You pick a clone of a famous app. Hiring managers have seen hundreds of to-do lists and Twitter clones. Push for something with one specific user in mind.
- You treat the capstone as homework to finish once and forget. The capstone is the artefact for the next six months of interviews. Treat it like that.
- You assume "no AI" is honesty. It isn't. Use Claude Code and local models throughout. The work is still yours because you made the decisions. You'll disclose the use in the README in 29.12.