Skip to content

Lesson 13 — Capstone change request

Objective

Independently synthesize and defend a complete feature design across state, URL, routes, validation, tests, and accessibility.

Prerequisites

All previous lessons, especially Lesson 12 — Architecture and production boundaries.

Mental Model

A capstone is not a tutorial; it is an open-ended design problem. Correctness, explicit ownership, failure handling, test quality, accessibility, and operational reasoning matter more than feature volume.

Concept

A production feature requires a clear contract: what state exists, where it lives, how it reaches the URL, and how the UI recovers from invalid or stale input. You must also be able to reject alternatives with evidence and explain what changes if requirements shift.

Example

interface ShareablePlan {
  version: 1;
  topicIds: string[];
  targetDate: ISOString;
  weeklyMinutes: number;
}

// URL contains a compressed, validated payload; notes and sensitive data are excluded.

Real-World Usage

Shareable reports, collaborative workspaces, invite links, and any feature where state crosses the browser boundary.

Common Mistakes

  • Putting the full object into a URL without versioning or validation.
  • Trusting a URL payload on the client only.
  • Prebuilding features for requirements that have not been asked for.

Mini Lab

Task

Add shareable study plans: users choose topics, target dates, and weekly minutes; the dashboard shows progress and a URL can reopen a plan in read-only mode.

Constraints

  • Existing tracker behavior must remain available.
  • Invalid or old shared payloads fail safely.
  • Shared URLs contain no notes or sensitive data.
  • The plan works by keyboard and at narrow widths.
  • Loading and save failures have recovery paths.

Expected Result

  1. State and URL schema with versioning.
  2. Route and component boundaries.
  3. Validated implementation with tests.
  4. Performance and accessibility evidence.
  5. A short design record with one rejected option.

Hints

Version the payload before encoding. Validate at the trust boundary. Keep the shareable surface small to avoid leaking data.

Knowledge Check

  • What are the trust boundaries for a shared URL?
  • How do you separate current needs from extension points?
  • What makes a design record useful to a reviewer?

Challenge

Present the design in ten minutes, then respond to changing requirements: authentication, collaboration, offline edits, and server persistence. Separate current needs from extension points; do not prebuild every hypothetical feature.

Summary

The capstone forces independent synthesis. State ownership, URL contracts, validation, and clear tradeoffs are the success criteria.

What Comes Next

Review your mastery map, then build the capstone without the reference solution. When you finish, compare your design with the completed interview-labs/ implementation.