The Grand Capstone: A Full-Stack Production App
Stage 3 · The Grand Capstone · Where it all comes together
You've learned every layer of the stack. Now build one thing that uses all of them — and prove you are a developer, not just someone who can make things work.
🎓 What this is
This is your graduation project. One real application — taken from idea (or rescued from an old vibe-coded prototype) and brought to production-grade standards across every discipline you've studied in Stage 3. You'll design it, build it, secure it, test it, deploy it, monitor it, document it, and then present a before-and-after audit that shows exactly how far you've traveled.
This is not another track assignment. It is not a tutorial clone, a demo that works on your laptop, or a project you abandon after pushing to GitHub once. It is a real, live, running service — one that would hold up in front of a hiring manager, survive a real user, defend itself against a real attacker, and keep running when you're asleep. When someone asks "can you actually build software?", this is what you show them.
The six track capstones you completed — Backend & APIs, Data & Databases, Auth & Security, Architecture & System Design, Testing & Craft, and DevOps & Operations — each built one layer of expertise. The Grand Capstone is the moment all six layers run together inside one coherent system. It is the whole building, not just the floors.
🎯 The mission
Pick a real app — something you care about, something you've already vibe-coded, or something you'd genuinely use yourself. Then rebuild it the right way, with every layer meeting the standard the Institute teaches. A clean normalized schema with migrations in git. A proper REST API with validation, service separation, and correct error handling. Real authentication with hashed passwords and ownership-based authorization. A system design document written before the first line of application code. A test suite that covers the critical path. A CI/CD pipeline that gates on green. A production deployment with structured logging, error tracking, and a runbook.
Then write the audit. Take a snapshot of what the app looked like before — or what a naive first version would have looked like — and compare it to what it looks like now. Show the schema before normalization and after. Show the auth before real password hashing and after. Show the deployment before CI and after. The delta between before and after is your proof of growth. It is the most honest portfolio artifact you will ever create.
🧱 What it must include (by discipline)
These requirements map directly to the six track capstones you completed on the way here. Each track capstone built expertise in one layer. The Grand Capstone is where all six layers run together inside one real system. Meet every requirement below — not most of them, all of them.
🗄️ Data & Databases
- A fully normalized relational schema — 3NF minimum — designed on paper before the first migration is written
- Every schema change tracked as a versioned, named migration file committed to git — no manual ALTER TABLE runs against production, ever
- Indexes chosen deliberately: pull the query execution plan for at least your two most-read queries and document why each index exists (or why none is needed)
- At least one multi-step operation wrapped in a database transaction, with rollback behavior explicitly tested — if step two fails, step one must be undone
- A documented backup and restore procedure with proof that you actually ran a full restore drill against real backup data — not just a note that says "pg_dump exists"
- Seed data or fixture data managed in a repeatable, committed script so any developer can spin up a working database from scratch with one command
⚙️ Backend & APIs
- A real REST API (or GraphQL if you choose and can defend the choice) with full CRUD on at least two distinct resources, each with its own business logic
- Input validation on every single endpoint — nothing raw from the request body reaches the database or the business layer without being validated and sanitized first
- A service layer that cleanly separates business logic from route handlers and from the data access layer — your route handler should not contain a SQL query, and your database query should not contain a business rule
- Correct HTTP status codes throughout, every time — no 200 OK on an error response, no 500 where a 400 belongs, no silent swallowing of failures
- Pagination on every endpoint that can return more than a small fixed number of rows — cursor-based or offset-based, documented and consistent
- At least one background job or asynchronous task that runs outside the request/response cycle: sending a transactional email, processing an uploaded file, running a nightly data aggregation, or anything else that would otherwise block a user-facing request
- Rate limiting on public and authenticated endpoints — your app should not be trivially abusable by a script hitting it in a loop
- API documentation that a new developer could use to integrate against your API without asking you a single question — at minimum an OpenAPI/Swagger spec, or a README API section with every endpoint, every request shape, every response shape, and every error code documented
🔐 Auth, Identity & Security
- Real authentication: passwords hashed with bcrypt or argon2 (never MD5, never SHA-1, never plaintext), or OAuth via a trusted provider — documented with the algorithm and cost factor chosen and why
- Authorization enforced at the service layer on every resource operation: ownership checks and role checks must happen in code, not just in the database, and they must fire on every access path — not just the obvious ones
- Every secret — database connection string, JWT signing key, API keys, SMTP credentials, everything — stored in environment variables and never committed to git in any branch at any point in history
- The app passes your own Security Audit Checklist from the Auth & Security track capstone — work through every item against the live production app, document each result, and for any item you cannot fully fix, write a mitigation and an accepted-risk rationale
- A written threat model: who are your realistic attackers, what do they want from your app, what are your three highest-risk attack surfaces, and how does the current implementation defend against each one — not in the abstract, in the specific
📐 Architecture & System Design
- A clean, enforced separation of concerns across every layer: data access, domain logic, API/presentation, and infrastructure configuration each live in their own layer with no leakage between them — no database calls in the router, no HTTP response logic in the service, no business rules in the migration
- A written System Design Document, produced using the template from the Architecture & System Design track, covering: the data model and why it is shaped this way, the full API contract, the deployment topology (what runs where and how the pieces connect), the identified failure modes, and the recovery strategy for each
- At least two identified bottlenecks with a written scaling plan for each: which resource exhausts first under 10x traffic (CPU, database connections, disk I/O, memory), what the observable symptom would be, and what the mitigation or re-architecture would be
- The system is designed to fail gracefully in the presence of dependency failures — a third-party API being down, a database connection pool being exhausted, or a background worker crashing should degrade the user experience in a controlled way, not cascade into a full service outage
🧪 Testing, Quality & Craft
- A real, meaningful test suite that covers the critical path end to end: unit tests for domain logic and business rules, integration tests for API endpoints run against a real test database (not mocks of the database), and at least one end-to-end test that exercises the single most important user flow in the application from the browser or client perspective
- Clean, readable code throughout: functions have a single responsibility, names accurately describe what things are and do, there are no commented-out code blocks left in the final submission, no magic numbers without named constants, no files exceeding a reasonable length without clear structural justification
- A proper README that a stranger could use: what the app does, how to run it locally from a clean machine, how to run the test suite, how the app is deployed, and where the important configuration lives
- At least one Architecture Decision Record (ADR) documenting a real technical tradeoff you made during the project — a decision where there were real alternatives with real tradeoffs, and where the choice you made had real consequences you can explain
- A clean, readable git history: commits that tell the story of what was built and why, using the discipline you developed in the Testing & Craft track — no wall of "fix stuff" or "wip" commits, no single commit that contains three unrelated changes, no commits that existed only to reverse a previous commit
🚀 DevOps, Deployment & Operations
- A CI/CD pipeline that automatically runs the test suite on every push and blocks merges to main when tests fail — no code reaches production without passing the suite
- Deployed to a real production environment with environment configuration managed correctly: environment variables injected at deploy time, not hardcoded, not committed, not pasted into a cloud dashboard by hand with no record of what was set
- Structured application logging: every request logged with enough contextual information (timestamp, request ID, user ID if authenticated, route, status, latency) that you could diagnose a specific user-reported bug from the logs alone, without needing SSH access to the server
- Error tracking integrated and active in production — Sentry, Honeybadger, or equivalent — so you receive a notification when the app throws an unhandled exception before a user has to report it to you
- At least one operational alert configured: something that notifies you when the app is returning errors above a threshold, when a key endpoint's latency degrades, or when the app stops responding entirely — you should know before your users do
- A load test run against the production environment before submission — use k6, Locust, Artillery, or equivalent, document the setup and the results, and know your actual throughput numbers and where the first bottleneck appears
- A runbook: a short, plain-English operational document that tells a developer who has never seen this app exactly what to do when it goes down at 2am — what to check first, what the common failure modes are, what the recovery steps are, and who to contact if recovery fails
- A tested rollback procedure: you have run a deployment, noticed a critical bug, and successfully rolled back to the previous version — and you have documented exactly how to do it, and you have timed it, and it takes under five minutes
🗺️ The whole B.U.I.L.D. method, for real
Every project in TOVCDI follows the B.U.I.L.D. method. In the earlier stages, you practiced individual letters — often one at a time, in isolation. The Grand Capstone is the first time you run all five letters, in sequence, on one serious project that actually ships to production.
B — Build the draft. Start with something real. Either take an existing vibe-coded project from earlier in your journey — something you made fast, that you're proud of but know has rough edges — or start fresh from a problem you genuinely want to solve. Write the System Design Document first: schema, API contracts, deployment topology. Then build a working first version. Ship it. It does not have to be good yet. It has to exist and run. The draft is the foundation everything else is built on.
U — Understand every line. Go back through everything you just built. Can you explain every function, every query, every middleware, every piece of configuration? If you wrote something with AI assistance and you cannot explain what it does and precisely why it is there, that is both technical debt and a security risk. The Grand Capstone has a zero-mystery-code policy. If you cannot explain it, you rewrite it until you can. This is not about distrusting AI assistance — it is about owning what you ship.
I — Interface: custom UI + clean API. Your API is a contract with anyone who integrates against it. Design it like one — consistent naming conventions, predictable and documented error behavior, versioned where the contract might need to change. Your UI, if the application has one, should be something you are genuinely proud to show another person. Intentional, clean, purposeful. No lorem ipsum in a corner. No unstyled error states. No UI flows that dead-end without explanation.
L — Lock it down. Run the Security Audit Checklist against the live production application. Write the threat model. Fix what you find. This step is not a box to check at the end — security is something you build into every layer from the database schema up. Authorization checks in the service layer. Input validation at every entry point. Secrets in environment variables. HTTP security headers hardened. Dependencies audited for known vulnerabilities. The "L" happens throughout the build, and then again as a final sweep before you call it done.
D — Document, Test, and Deploy. Write the README. Write the ADR. Write the runbook. Wire up the tests and make sure CI runs them on every push. Deploy to production with environment configuration done correctly. Set up error tracking. Set up the alert. Run the load test. Then write the Before/After Audit — the document that proves this is not just a project that works, but a project you understand end to end, from the data model up through the deployment pipeline.
🧪 Deliverables
When you submit the Grand Capstone, you deliver all of the following — every item, not most of them:
- A live deployed URL — the application is running in production, accessible to real users, right now, as you submit
- The repository — clean git history that tells the story of what you built, a proper README, at least one ADR, a CI configuration that runs on every push, a meaningful test suite, all database migrations committed in order, zero secrets in any commit at any point in history
- The System Design Document — written using the Architecture track template, covering schema design rationale, full API contract, deployment topology, identified failure modes and their recovery strategies, and the scaling plan
- The Security & Threat Model document — your written threat model plus the completed Security Audit Checklist with every item either signed off as resolved or explicitly accepted as a known risk with a documented mitigation
- The Before/After Audit — a written, specific comparison of what the project looked like before you applied Stage 3 standards versus what it looks like now, with concrete examples from each of the six disciplines: what changed in the schema, what changed in the API, what changed in the auth model, what changed in the architecture, what changed in the test coverage, what changed in the deployment
- A walkthrough presentation — five to ten minutes, live or recorded, in which you demo the running application and then walk through one architectural decision, one security decision, and one operational decision you made — what the alternatives were and why you chose what you chose
🏆 What earns the title
The bar is not "does it work." Working is the floor. The bar is: would this application survive a real user, a real attacker, real scale, and a real 2am outage?
A real user means the API validates their input and returns useful error messages. It handles their errors gracefully instead of returning a 500 with a stack trace. It never leaks data that belongs to another user. It stays up while they're using it. It responds fast enough that they don't abandon it.
A real attacker means your secrets are not in git. Your passwords are not reversible. Your authorization logic cannot be bypassed by changing a resource ID in the URL. Your inputs are validated before they reach the database. Your threat model names who the attackers are and what they want, and your implementation has a real defense for each risk — not just "we use HTTPS."
Real scale means you know what breaks first at 10x current traffic. You've run a load test and you have numbers, not guesses. You have indexes on the queries that need them. You are not executing N+1 queries in your critical path. Your background jobs do not block the web process.
A real 2am outage means you have structured logs that let you diagnose a bug without SSH access. You have error tracking that tells you about the problem before a user emails you. You have a runbook that a panicking developer who has never seen this codebase can follow at 2am. You can roll back to the previous version in under five minutes, and you have proven that by actually doing it.
The Production-Readiness Checklist from the DevOps & Operations track capstone is your final gate. Every item on that list must be checked. Any item that cannot be fully satisfied must have a written exception with a rationale and a mitigation. "I didn't get to it" is not an exception. "I evaluated this risk and accepted it because X, and my mitigation is Y" is an exception.
✅ You're done when…
- The Production-Readiness Checklist from the DevOps & Operations track has been completed against the live production deployment — every item signed off, every accepted exception documented with a specific rationale and mitigation strategy
- The Security Audit Checklist from the Auth & Security track has been run against the live production application — every finding is either resolved and verified, or explicitly risk-accepted with a written rationale that names the residual risk and the mitigating control
- The Before/After Audit demonstrates measurable, specific improvement across all six disciplines — not vague assertions of improvement, but concrete before-and-after comparisons with specific examples from the codebase, the schema, the deployment, and the security posture
- The app is live, monitored, tested, and documented — a real public URL, error tracking active and receiving events, CI pipeline green on the main branch, README complete enough for a stranger, runbook written and reviewed, rollback procedure tested and timed
- You can explain and defend every line and every architectural decision — not just what the code does, but why it exists, what the alternative approaches were, what the tradeoffs of the chosen approach are, and what you would do differently with more time or a different set of constraints
A note on where you started
You started this curriculum as a vibe coder. That is not a criticism or a limitation — it is a genuine superpower. The ability to go from an idea to a working prototype in an afternoon, using AI to accelerate every step of the process, is valuable and rare and you should keep it.
What Stage 3 built underneath that superpower is the layer of engineering rigor that makes the things you build actually trustworthy. The ability to look at what you or an AI just created and ask the harder questions: Is this schema going to hold up at scale? Does this authentication implementation actually prevent the attacks it claims to prevent? Can a developer who has never seen this codebase understand and maintain it without a three-hour onboarding session? Will this application survive a 2am outage without you being the single point of failure?
The Grand Capstone is where you prove you can answer yes to all of those questions — and still move at the speed that made you good in the first place.
You are not graduating away from vibe coding. You are graduating to being a developer who happens to also be a great vibe coder. That was always the point. The vibe coding gets you to a working first version fast. The engineering makes that first version worth shipping. Both matter. You now have both.
➡️ This is the finish line. You started as a vibe coder. You're finishing as a developer who happens to also be a great vibe coder. That was always the point. Build It Right, Or Don't Build It At All. 🏛️