Capstone: Ship Something
Take a research need to a deployed artifact that runs while you sleep.
Before this:05 · Compute, Models, and Cost06 · Trust, Verification, and Research Integrity07 · Two Pipelines
A notebook succeeds when you run it; a deployed thing has to succeed while you are asleep, which is an entirely different relationship with your own work. Deployment forces every question a notebook lets you defer: what happens on failure, what it costs per month, how you would even know it is down. The capstone is a deployed thing because the point of this track is leaving with something that runs, not something that ran once while you watched.
Learning outcomes
- Take a real research need from spec to a deployed, reachable artifact.
- Keep something running unattended and know what happens when it fails.
- Produce a walkthrough a peer reviewer could follow without you present.
- Contribute a template or correction back to the curriculum.
What you already have
Everything from Units 00 through 07, plus the credits to host it. Vertex AI gives you real API endpoints; GPU VMs give you instances with no session timeout; the $120/year in recurring credits is real money across the twelve months, and the $300 trial is a separate starting balance on top of it. It's time-limited, so verify the expiry window before you plan a deployment around it.
Concept
§6.6 calls it the deployment cliff because the drop is real: works-on-my-laptop and works-in-production are separated by exactly the skills this track has been stacking. §0.17's final boss is the same test in interview form, and "functional" at the end of this track means a URL, a repo, and a straight answer about how it was built.
§6.6 (The deployment cliff: making it run while you sleep) is the technical content. §0.17 (Projects and the final boss) is the shape of the exercise. Part 9 is what comes after: §9.1 (The community), §9.2 (Contributing templates back), §9.3 (What "functional" looks like now).
/stacks/quick-startup is the fastest honest path to a live URL. /stacks/aws-production is what it becomes if it outlives the term.
Paired instantiation
| Portable idea | Google (what you have) | Internet Menace (the method) |
|---|---|---|
| A real endpoint, not a notebook | Vertex AI endpoints, GPU VMs | §6.6: the deployment cliff |
| It runs without you | Pro+ background execution, Cloud Run | §6.6; /stacks/aws-production |
| A record a reviewer can follow | Antigravity Walkthrough | §6.2; §9.2 (contributing back) |
| Ship something you would show someone | — | §0.17, §9.3 |
Lab
- Pick a tool your research actually needs and that does not exist. Not a demo. Something you will use next month.
- Write the spec with
/templates/prd. Write the context file with/templates/claude-md. - Build it with the agent workflow from Unit 04, reviewing plans before approving them.
- Deploy it. It must have a URL and it must survive you closing your laptop.
- Instrument the failure case: what happens when it errors at 3am, and how do you find out?
- Write the walkthrough: what it does, how it was built, what it costs to run, what you verified.
- Write the disclosure statement using /academic/disclosure.
- Contribute something back: a template, a correction, or a section that was wrong for your field. See /contribute.
Deliverable
A live URL, a public repository, a disclosure statement, and a walkthrough document: the four artifacts a reviewer, a supervisor, or an interviewer would each ask for.
Self-check
- Your service has been up for three weeks. How would you know if it stopped working?
- What does it cost per month, and what is the first thing you would cut?
- A reviewer reads your walkthrough without talking to you. What can they still not verify?
- What did you learn building this that the curriculum got wrong for your field?