FE10: Capstone: three frontend projects for Kirana Express
Planning the capstone
🎯You'll be able to
Plan the capstone: scope, order of work, evidence and time.
🏠The everyday picture
An architect doesn't start by laying bricks. They agree the plan with the family, list the rooms and materials, and decide the order of work, so the house goes up without tearing down walls later.
📘What it really is
- The three projects, all for Kirana Express:
- Accessible component set: the kit's button, text field, select, checkbox, dialog and toast, rebuilt to work by keyboard and screen reader (checked by 20 component tests and an axe scan);
- Multi-page app: cart, checkout and order tracking added to the kit's browse and product pages, with shared state and five end-to-end journeys;
-
Slow page made fast: the kit's Deals page, measured against five budgets before and after.
-
Build in this order: the component set first (the other two use it), then the app, then performance work on the finished pages.
-
Each project already has acceptance tests in the kit and a marking guide on its project page. Add your own criteria too, such as "a full order can be placed by keyboard only".
-
Use this overview to judge your own work (each project page has the detailed marking guide):
| Area | What "good" looks like |
|---|---|
| Correct | Renders and updates correctly; keys, effects and state in the right places (FE1–FE2) |
| Rendering | Sensible rendering choice per page; no hydration warnings (FE3) |
| Fast | Field or throttled lab vitals in the "good" range; budgets met (FE4–FE5) |
| Accessible | Keyboard and screen reader journeys work; WCAG AA contrast and targets (FE6) |
| Well built | Strict types, tokens, lint clean, safe environment variables (FE7) |
| Tested | Unit, component and E2E tests that are stable (FE8–FE9) |
| Shipped (optional extra) | CI, previews, staged release and rollback rehearsed (FE9) |
📝A worked example
A learner's capstone plan (illustrative):
| Week | Work | Done when |
|---|---|---|
| 1 | The six components, styled from the kit's tokens | 20 component tests and the axe scan of /components pass; keyboard and screen reader check recorded |
| 2 | Money formatting and the cart page | 8 money tests pass; state map written |
| 3 | Checkout and order tracking | 5 journeys pass on desktop and mobile, three full runs in a row |
| 4 | Performance work on the Deals page | All five budgets in npm run perf pass (middle of three runs), plus one real-phone measurement |
| 5 | Capstone checks, demo, self-review and case studies | Every project page saved as self-checked complete, with evidence |
Building the components first meant the accessibility work was done once and reused on every page.
🌍Where it's used
- Agency and freelance projects delivering a client's website.
- Product teams starting a new app or redesign.
- Portfolios for frontend job applications.
📝Case scenario
A learner starts with performance tuning on a half-built page, then rebuilds the page with new components, undoing the tuning. They reorder: components, then pages, then performance on finished pages. The second attempt finishes on time and the performance gains stick.
🖱️Try it
Write your capstone plan: acceptance criteria for each project, a week-by-week timeline with "done when" checks, and your copy of the rubric.
⚠️Common mistakes
- Starting with the hardest part without a plan. Sign: week three with nothing finished. Fix: list the projects, their tests and a date for each.
- Leaving evidence to the end. Sign: no screenshots or test output for earlier work. Fix: save evidence as each test passes.
🛠️For your project
Download the starter kit from the path's Projects page and run its tests once before you plan, so you know what fails now.
✅Quick check
Why build the component set before the other two projects?
Show the answer
Both other projects use the components, so accessibility and design work is done once and reused.
Why leave performance tuning until the pages are complete?
Show the answer
So the gains aren't undone by later changes to the pages.