1. Project Planning & Scoping
Before writing any code, write down what this application actually does, for whom, and what "working" concretely means:
- What's the core user flow? — the one thing someone opens this app to do (track expenses, browse and save recipes, manage a small team's tasks).
- What data does it need? — what's read (Week 8), what's written (Week 9), and what's genuinely shared client state versus per-component state (Week 10).
- How many distinct pages/routes does it need? — enough to exercise Weeks 6–7's routing meaningfully, without padding the scope with pages nobody needs.
- What does "done" look like, measurably? — a specific list of user flows that must work, decided now rather than invented retroactively to match whatever got built.
Scope deliberately small and real rather than large and ambitious — a well-built three-page app with solid data handling, tests, and a working deploy is a stronger capstone than an ambitious ten-page app that's untested and half-finished.
2. Architecture Decisions & Tradeoffs
With the app scoped, make deliberate choices using the course's own frameworks — and be ready to explain each one, not just make it:
- Rendering strategy (Weeks 16–17) — a Next.js app if you want server rendering, static generation, or SEO to matter; a Vite SPA (Weeks 1–15's stack) if the app is fully behind a login and client-rendering is simpler for your scope.
- Server state (Weeks 8–9) — TanStack Query for anything fetched from an API, with query keys planned out before you start wiring up components.
- Global client state (Week 10) — Context for a small amount of infrequently-changing state (theme, auth), Zustand if there's real app-wide state that changes often; justify whichever you pick, or neither, over the other.
- Component architecture (Week 11) — a feature-based folder structure from the start, and at least one compound or composed component where the UI genuinely calls for one.
Justify each piece: "I used TanStack Query because this app's core data lives on a server and needs caching across several pages" is a real architectural decision; "I used Redux Toolkit because it's what I know" is not — Week 10 gave you the framework to make this choice deliberately.
3. Full Implementation, in a Sensible Order
Build in an order that lets you validate each layer before adding the next — the same incremental discipline from Week 9's exercise, now spanning the whole app:
# 1. Static shell first: routes, layouts, navigation (Weeks 6-7 or 16-17) -- no data yet
# 2. Read paths: wire up queries for every page that displays data (Week 8)
# 3. Write paths: forms and mutations, with invalidation (Weeks 5, 9)
# 4. Global/shared state ONLY where the app genuinely needs it (Week 10)
# 5. Error boundaries and Suspense around anything that can fail or take time (Week 12)
# 6. Styling and accessibility pass -- not deferred to "later" (Week 18)
This order matters for the same reason Week 8's article emphasized it: it's far cheaper to discover your data model needs to change while the shell is still simple, than after forms, mutations, and global state are all built on top of an assumption that turns out to be wrong.
4. Testing, Performance & Accessibility Pass
Apply Weeks 13, 14–15, and 18 in full, not as an afterthought:
- Test coverage (Week 13) — component tests for your core user flow using RTL, with network calls mocked via MSW; at least one Playwright e2e test covering the single most important path end to end.
- A profiling pass (Week 14) — record at least one interaction with React DevTools Profiler, and fix anything that shows an unnecessary re-render or a genuinely slow computation.
- Code-splitting (Week 14) — at least one route or heavy component lazy-loaded, confirmed via the Network tab.
- Accessibility (Week 18) — a clean
jest-axepass on your core pages, full keyboard operability confirmed by hand (mouse unplugged), and a Lighthouse accessibility score you'd be comfortable showing someone.
5. Deployment & Portfolio Write-Up
A working app nobody else can see is much less useful as a portfolio piece than a modest, deployed one. Deploy to Vercel (for a Next.js app) or a static host like Netlify (for a Vite SPA) — both have a free tier sufficient for a capstone project.
- The problem and who it's for — one paragraph, from Section 1's scoping.
- Architecture decisions and why — the choices from Section 2, and the reasoning behind each, not just the final list of libraries.
- What you tested, and how — your Week 13 coverage, honestly described, including anything you chose not to test and why.
- Performance and accessibility numbers — real Lighthouse scores, real profiler findings you fixed, not vague claims.
- A live link — the deployed app itself is the actual deliverable a reader will judge the whole project by.
6. The Capstone Project
Ship a complete, tested, deployed React application
Pick a real, well-scoped problem — a small project tracker, a recipe collection with search and favorites, a personal expense log — and take it fully through Sections 1–5.
Requirements:
- Write your project scope (Section 1) before writing any code: core flow, data needs, page count, and success criteria.
- Justify your architecture in writing (Section 2): rendering strategy, server state, global state, and component structure choices.
- Implement incrementally (Section 3), validating each layer — routes, reads, writes, shared state — before adding the next.
- Complete a full testing, performance and accessibility pass (Section 4), fixing what it surfaces rather than just running the tools once.
- Deploy the app for real and produce a portfolio write-up with a live link (Section 5).
Not scope or cleverness — a small, well-built app with real tests, a real deploy, and a clear explanation of your architectural decisions reads as far more credible to anyone reviewing it (an employer, a collaborator, future-you) than an ambitious app with no evidence any of it actually works.
7. Final Checklist
Before calling the capstone — and the course — done, confirm each of these honestly:
✓
Is the project scope written down, with concrete success criteria decided before you built the app?
Is the project scope written down, with concrete success criteria decided before you built the app?
If success criteria were defined after seeing what you built, they're no longer a fair test of it — the same discipline behind writing a Week 13 test's expectations before, not after, checking what the code currently does.
✓
Can you explain, for every major library or pattern you used, why it was necessary rather than just familiar?
Can you explain, for every major library or pattern you used, why it was necessary rather than just familiar?
Every added dependency and pattern is added complexity and surface area to maintain. A capstone that can justify each choice crisply — Zustand because this specific state changes often and is read widely, not "because it's popular" — reads as far more mature engineering judgment than one that used every tool from the course regardless of fit.
✓
Does the app actually work end to end when a stranger opens the deployed link, on a real network, with no local setup?
Does the app actually work end to end when a stranger opens the deployed link, on a real network, with no local setup?
A capstone that only works on your own machine, with your own local environment, isn't actually finished — deployment (Section 5) is not optional polish tacked on at the end; it's the proof the application is real and the actual form in which anyone else will ever evaluate it.
✓
Could someone else — a hiring manager, a collaborator — understand what this does and how well it works, without reading your code?
Could someone else — a hiring manager, a collaborator — understand what this does and how well it works, without reading your code?
A working app is only as valuable as your ability to communicate what it does and why it matters — the write-up from Section 5 is the actual deliverable a reader will judge the whole project by, exactly as it was for the LLM & ML course's capstone. A live link plus a clear explanation beats a GitHub repo nobody without your context can evaluate.
That's the full 20-week path — from your first component to a tested, optimized, deployed production React application. Congratulations on reaching the capstone.