Capstone: Build and Ship Your Own Agentic Product End-to-End

Summary

This is where it all becomes one workflow. Not five separate skill sets, but a single loop from idea to live product: scope a real problem, write the spec, build it with your agent, run the quality gate, harden the security, make it discoverable and agent-first, deploy it, and put it in front of people. The deliverable is a shipped thing, however small, plus the proof - to yourself - that you can take any idea through this loop again. This lesson is a guided build with a concrete acceptance checklist, not a reading.

What you will learn

You will run the full end-to-end loop once, deliberately: scope ruthlessly to something finishable, spec it the way Course 1 taught, build it with Claude Code on a real stack, protect it with the tests and security from this course, make it discoverable with SEO and an llms.txt, give it an agent-first API surface, deploy it, and share it. The output is a live product and a repeatable process.

Prerequisites

All five courses. The capstone draws on every skill: model choice and prompting (Course 1), agent mastery (Course 2), the modern stack of auth, data and payments (Course 3), automation and agentic systems (Course 4), and the quality, security, legal, SEO and agent-first lessons of this course. If any of those feels shaky, do a quick pass before you start - the capstone assumes them.

The problem

The single most common way a capstone dies is scope. People pick something huge and inspiring, build forty percent of it, hit the messy middle, and quietly abandon it. An unfinished ambitious project teaches far less than a finished tiny one, because shipping is where you meet every problem the tutorials skipped. The whole discipline of this lesson is choosing something small enough to finish and real enough to matter, then carrying it all the way to live.

Step one: scope to something you can finish

Pick one small, real problem - ideally one you actually have, or one that ties into an opportunity from the previous lesson. Cut it down until you are slightly embarrassed by how small it is, then cut once more. A tool that does one useful thing well and is live beats a platform that does ten things and never ships. Write the scope as a single sentence you could explain to a stranger.

• One problem, one user, one clear outcome. If you cannot say it in a sentence, it is too big.
• Prefer a real itch of your own - you will know when it is good and you will actually use it.
• Ruthlessly defer everything that is not the core loop. A second feature is a second project.
• Define done before you start, so you ship instead of polishing forever.

Step two: spec it and build it with your agent

Turn the scope into a real spec sheet - goal, context, constraints, acceptance criteria - the way Course 1 taught, with your axioms baked in. Pick the right model tier for each task, choose a stack you can deploy, and drive Claude Code with project rules in your CLAUDE.md so it follows your conventions automatically. Build the core loop first and get it running locally before you add anything around it. Ask the agent to push back on your plan before it starts - some of the best decisions in a build come from the agent catching a flaw early.

## Goal
A tool that takes a business address and returns its opening hours as clean JSON.

## Context
- Stack: this TanStack Start app, Convex for data, deploy on Vercel.
- Follow the API patterns from the agent-first lesson.

## Constraints
- TypeScript only. Every endpoint rate-limited. Secrets in env vars.
- Publish an OpenAPI spec and an llms.txt. Self-serve API keys.
- Add a Vitest test for the parser and a Playwright test for the happy path.

## Acceptance criteria
- [ ] GET /v1/hours?address=... returns structured JSON or a clear error.
- [ ] Rate limit returns 429 when exceeded. Errors are structured.
- [ ] OpenAPI spec and llms.txt are live and accurate.
- [ ] Quality gate (tsc, lint, vitest, playwright) is green in CI.
- [ ] Deployed to a public URL over HTTPS.

Step three: gate, secure and comply

Before this goes anywhere near a real user, run everything from this course. Put the four-layer quality gate in place and make CI required. Apply the security essentials - rate limit every public endpoint, set a CSP, encrypt any stored secret, and run the pre-public history audit if the repo will be public. If it collects any personal data, do the privacy pass: lawful basis, a working consent flow, a privacy policy. This is the part beginners skip and professionals never do. It is also what separates a demo from a product.

• Quality: tsc, lint, Vitest and Playwright all green, enforced by a pre-push hook and required CI.
• Security: rate limits, CSP header, encrypted secrets, and a clean gitleaks scan before any public repo.
• Legal: if it touches personal data, a lawful basis, a compliant consent flow and a privacy policy.
• Agent-first: published OpenAPI spec, predictable structured errors, self-serve keys.

Step four: ship it and make it discoverable

Deploy to Vercel, connect a domain if you have one, and confirm it loads over HTTPS with secrets set as environment variables, not in the repo. Then make it findable through both channels from the SEO lesson: real titles and descriptions, a sitemap, Search Console, a crisp favicon, structured data, and an llms.txt plus clean docs so AI assistants can discover and recommend it. A shipped product nobody can find is only half done - give it a way to be discovered by humans and by agents.

Step five: share it in the community

The last step is not optional fluff, it is how you close the loop. Post your shipped product in the community: what it does, what you learned, where it was harder than expected, and the live link. Sharing forces you to actually finish, invites the feedback that makes version two better, and connects you to other builders going through the same loop. The founder of this school shipped imperfect things publicly long before they were ready, and that habit - ship, share, learn, repeat - compounds faster than any amount of private polishing.

Typical mistakes

The capstone killers: scope so large it never ships; skipping the quality gate so it breaks the moment you change it; skipping security so the first bot abuses it; treating the API and discoverability as afterthoughts so neither humans nor agents can find it; and never sharing it, so you lose the feedback and the accountability that finishing demands. Small, gated, secure, discoverable, shared - in that order.

Business ROI

A single shipped product teaches more than a year of tutorials, because shipping surfaces every real problem at once and forces a decision on each. It is also your proof of capability - to yourself, to customers, and to anyone you want to work with. And the loop you just ran is the asset, not only the product: once you can take an idea from scope to a live, tested, secure, discoverable, agent-first thing, you can do it again and again, faster each time. That repeatable loop is the entire return on this programme.

Checklist

Your capstone is complete - genuinely, not nearly - when every one of these is true. This is the acceptance criteria for the whole programme.

• The product solves one real problem and is live at a public URL over HTTPS.
• The four-layer quality gate is green and required in CI.
• Every public endpoint is rate-limited, secrets are encrypted, and a public repo passed a history scan.
• If it collects personal data, it has a lawful basis, working consent and a privacy policy.
• It has an OpenAPI spec, predictable errors, self-serve keys and an llms.txt.
• It has real titles, a sitemap, a favicon and is verified in Search Console.
• You posted it in the community with the live link and what you learned.

Resources

Every prior lesson is a resource for this build - keep the spec-sheet template, the quality-gate workflow, the security checklist, the privacy checklist and the agent-first checklist open as you go. The Builds section shows finished projects end to end if you want a reference for scope and shape. The community is where you share the result and where the next round of feedback comes from.

Your task

Build and ship it. Pick the small problem, write the spec, build it with your agent, pass the quality gate, secure and comply, deploy it, make it discoverable and agent-first, then post it in the community with the live link. Tick every box on the checklist above. When the last box is ticked, you have not just finished a course - you have proven you can ship an agentic product end to end, on your own, again and again.

What comes next

You have completed the programme, but the field will not hold still and neither should you. Keep shipping small things, fold new tools in as they appear, and use the changelog as your daily tool-news hub to stay current. Bring your builds, your wins and your stuck moments to the community - that is where learning keeps compounding after the courses end. The loop you now own is the whole point: idea, build, gate, secure, ship, share, repeat. Go run it again.