Skip to main content
Back to module
Front-End Engineering · Shipping

Capstone: production-ready app

Reading42mLesson 3 of 3 in this module

Plan, build, test and deploy an accessible, fast React app with CI, then present it as portfolio work.

Why it matters

Hiring managers for front-end roles look for evidence that you can ship, not just follow tutorials. A single small app that is accessible, tested, fast, deployed and maintained through pull requests and CI says more than ten unfinished clones. This capstone pulls together everything in the course: structure, TypeScript, state, performance, component design, testing, motion, CI and review.

The brief

Build a small but real application with React (Vite, or a framework such as Next.js) and TypeScript. Pick something you would actually use. Good shapes:

  • A course or reading tracker: list, filter and search items; add and edit; mark complete; a progress summary.
  • A public data browser: search a free, keyless public API (for example Open Library or a government open-data API), with filters in the URL and a detail page.
  • A habit or study planner: create habits, check them off, see streaks, export the data.

Keep the scope small enough to finish in two or three weekends. Depth beats features.

The definition of done

Treat this as a checklist; each item maps to a lesson.

Structure and types

  • Feature folders, a small shared components/ui layer and a framework-free lib/.
  • TypeScript in strict mode; API responses validated at the boundary.

State

  • URL state for search, filters and the current tab; server state through a data library or framework loaders (if you call an API); local state everywhere else; no derived state stored.

Accessibility

  • Semantic HTML, one h1 per page, labelled inputs, visible focus, keyboard-operable everything, a skip link.
  • Lighthouse Accessibility 100 and no serious axe violations on the main screens; tested once with a screen reader.

Performance

  • Lighthouse Performance in the green on the Mobile preset for the main page; LCP under 2.5 s and CLS under 0.1 in the lab.
  • Route-level code splitting; images sized, in a modern format, with srcset and lazy loading below the fold.

Components and motion

  • At least Button, Input and one dialog or disclosure built as reusable, accessible primitives.
  • Transitions use transform and opacity only and honour prefers-reduced-motion.

Testing

  • Unit tests for pure logic, component tests for each feature's main states (loading, empty, error, success), and one Playwright e2e test for the core journey.

Delivery

  • GitHub Actions CI running lint, typecheck, tests and build on every PR; required on main.
  • Work done in small PRs, each with a description; review your own PRs with the checklist from the previous lesson.
  • Deployed to a free static host (Netlify, Vercel, Cloudflare Pages or GitHub Pages). No paid plan is needed for a portfolio app.

A suggested plan

  1. Day 1: plan. Write a one-page README: problem, users, three core user stories, and what is out of scope. Sketch the main screens.
  2. Day 2: skeleton. npm create vite@latest with the react-ts template, ESLint, Vitest, folder structure, CI workflow, first deploy of a "hello" page. Deploying on day one removes the scariest step from the end.
  3. Days 3–5: features. One feature per PR, with tests in the same PR.
  4. Day 6: quality pass. Lighthouse and axe on every screen, keyboard and screen reader run-through, reduced-motion check, fix what you find.
  5. Day 7: polish and present. Empty and error states, a 404 page, README with screenshots and decisions.

Deploying a Vite app

Static hosts build from your repository:

  • Build command: npm run build
  • Publish directory: dist
  • Single-page app routing: if you use client-side routes, configure a fallback so /courses/42 serves index.html (a _redirects rule /* /index.html 200 on Netlify, a rewrite on Vercel, or a 404.html copy on GitHub Pages).
  • Environment variables: anything read on the client (for example Vite's VITE_ variables) ends up in the public bundle. Never put secrets there.

Presenting it

Your README is the first thing a reviewer reads. Include:

  • What it does and a link to the live site, with two or three screenshots.
  • How to run it locally (npm ci, npm run dev, npm test).
  • Decisions: why you chose this rendering strategy, state approach and folder structure, and what you would do next.
  • Quality evidence: Lighthouse scores, test counts, a short accessibility statement listing what you tested and any known gaps.

Be ready to talk through one hard bug you fixed and one trade-off you made. That conversation is often the most valuable part of an interview.

Common mistakes

  • Scope creep: a half-finished app with twelve features impresses less than a finished one with three.
  • Deploying only at the end and discovering routing or environment problems on the last day.
  • One giant commit at the end instead of PRs that show how you work.
  • Copying a tutorial project without changes; reviewers recognise them.
  • Leaving accessibility and tests "for later".

Quick recap

  • Build one small, real app and finish it to a professional standard.
  • Use the definition of done: structure, types, state, accessibility, performance, components, motion, tests and CI.
  • Deploy early to a free host, work in small PRs, and document decisions and quality evidence in the README.

Try it

The Do tab breaks the capstone into concrete steps you can tick off as you go.

Also in this lesson: