Weeks 25–26: Capstone — Ship a Full Application

1. Project Planning & Scoping

The single biggest risk to a two-week solo project isn't a difficult bug — it's scope that quietly grows past what two weeks can actually finish. Pick something small enough to complete, but real enough to demonstrate range across the course.

A few project shapes that exercise most of the course well:

• A task/project tracker — nested routes (Week 10), drag-and-drop reordering (Week 8), filtering and sorting (Week 6), a Signal Store (Week 17) for shared board state.
• A recipe or content manager — reactive forms with dynamic ingredient lists (Week 12), image handling, search-as-you-type (Week 15), a public/private-content split exercising auth (Week 23).
• An expense or budget tracker — charts (a natural fit for a @defer-loaded heavy dependency, Week 11), computed derived totals (Week 5), CSV import via file upload (Week 14).
• An event RSVP / small booking app — public and authenticated views, forms with validation, email-style notifications, a genuinely useful SSR story (public event pages should load fast and be indexable, Week 21).

## What it is (one sentence)

## Core user flows (3-5, no more)
1.
2.
3.

## Explicit non-goals
(Things a "complete" version of this app would have, that THIS version deliberately won't)

## Tech decisions made up front
- State management approach:
- Auth: real, mocked, or none?
- Data source: real backend, mock API, or local-only?

The "explicit non-goals" section matters as much as the flows — deciding on day one what you're not building is what keeps scope from expanding mid-project.

2. Architecture Decisions & Tradeoffs

Before writing a component, make the handful of decisions that are expensive to reverse later — and write down why, in one sentence each. This is the single habit that most separates a tutorial-follower from someone who can architect independently.

## State management
Decision: Signal-based services (Week 9 pattern), not a Signal Store.
Why: One user, one board, no genuinely cross-cutting shared state complex
enough to justify Signal Store's extra structure (Week 17's guidance).

## Auth
Decision: Mocked auth service with a fake JWT, no real backend.
Why: The capstone's goal is demonstrating the CLIENT-side auth pattern
(Week 23) -- a real backend is out of scope and would eat time better
spent elsewhere.

## Routing structure
Decision: /boards -> /boards/:boardId -> /boards/:boardId/cards/:cardId
Why: Mirrors the actual information hierarchy; each level needs its own
URL for direct linking and browser back/forward to work correctly.

Sketch your actual route tree on paper before writing a single Routes array — the exercise of drawing it tends to surface structural questions (does this view really need its own URL? should this be a modal instead?) far more cheaply than discovering them mid-implementation.

3. Full Implementation Checklist

Not every technique from the course needs to appear — but a genuinely well-rounded capstone touches most phases. Use this as a checklist while you build, not a script to follow in order:

• Phase 1-2 (Foundations, Core Reactivity): standalone components throughout, signals for all local state, the new control-flow syntax exclusively (no *ngIf/*ngFor).
• Phase 3 (Application Architecture): a real routing structure with at least one guard and one resolver, at least one non-trivial reactive form with custom validation.
• Phase 4 (Data & State): a typed HTTP data-access layer with at least one interceptor, and a deliberate state-management decision (Section 2) you can defend.
• Phase 5 (Quality & Performance): a real test suite (unit tests for services/stores at minimum), at least one measured performance fix, SSR enabled and hydrating cleanly.
• Phase 6 (Advanced): at minimum, a genuine accessibility pass (Week 22) and a considered security posture (Week 23) — micro-frontends (Week 24) are almost certainly out of scope for a solo two-week project, and that's the correct call per that week's own guidance.

4. Performance & Accessibility Pass

Once the app is functionally complete, run the exact process from Weeks 20 and 22 — not as an afterthought, but as a scheduled pass with its own time budget.

1. Record an Angular DevTools profile during your app's core flow; fix any component re-rendering more than it should.
2. Run a bundle analysis; confirm your lazy-loading boundaries actually produced separate chunks.
3. Run Lighthouse and axe; fix every accessibility issue, not just the critical ones.
4. Navigate the entire app by keyboard alone, start to finish.
5. Test with prefers-reduced-motion enabled.

Budget real time for this — a day is reasonable for a two-week project. Skipping it is the most common way a technically-complete capstone still feels unfinished.

5. SSR + Deployment

Apply Week 21's process in full: add SSR, fix every hydration mismatch, set real build budgets, and deploy to a live, public URL on a host that supports Node.js SSR.

Before considering this done, do the checks that actually reveal SSR/routing misconfiguration:

• A hard refresh on a deep, nested route (not just the home page)
• The 404 page, reached via a genuinely invalid URL
• View-source on a key page — confirm real content is present, not an empty shell

A live URL is the deliverable that actually matters to anyone evaluating this project — a capstone that only runs on localhost is, for portfolio purposes, unfinished.

6. Portfolio Write-Up & Demo

The code is only half of what gets evaluated — most reviewers read the README before they read a single file of source.

## [Project Name]

One-paragraph description of what it is and who it's for.

[Screenshot or short GIF of the core flow]

**Live demo:** [link]

### Tech stack
Angular 22, signals, [your state approach], [your backend/data approach]...

### Architecture decisions
Link to or summarize Section 2's decision record -- this is often
the single most interesting part of the README to an experienced reviewer.

### What I'd do differently with more time
Honest, specific -- this signals self-awareness more than a project
that claims to have no rough edges at all.

A 2-3 minute demo video or GIF walking through the core flow is worth the extra hour it takes to make — it's the difference between someone actually seeing your work versus deciding whether to clone and run it themselves, which most reviewers, realistically, won't do.

7. The Capstone Brief

8. Self-Assessment

Four honest questions to ask before calling the capstone done. Expand each for what a solid answer looks like.