Ship Something Real

This is the final JavaScript course capstone: a portfolio-grade project where you design first, build in your own environment, verify the behavior, document the tradeoffs, and ship something you can explain. The goal is not to finish a toy scaffold on this page; it is to prove you can carry JavaScript from idea to release.

Pick one track and take it all the way. Keep the scope small enough to finish, but real enough that the engineering choices matter.

What you'll build

Choose one track:

• Full-stack app with Node - a small product workflow with a browser UI, a Node API, validated inputs, persistence, tests, and a demoable happy path. Examples: habit tracker, workshop signup, invoice mini-app, study planner.
• Framework front-end - a React, Vue, Svelte, Solid, or Angular app with component state, routing, async data, failure UI, performance checks, and a deployed demo. Examples: reading queue, project dashboard, recipe planner, game stats viewer.
• npm library - a reusable JavaScript package with a stable ESM public API, tests, docs, examples, and a packed-artifact smoke test. Examples: form-state helper, config parser, date-range utility, validation toolkit.
• CLI tool - a Node command-line tool that reads files or flags, validates input, handles expected failure with useful output, exits predictably, and has tests. Examples: markdown checker, changelog helper, JSON report formatter, project audit command.
• Browser game - a playable browser game with state, input, rendering, assets or Canvas, restart/pause behavior, performance awareness, and a clear win/lose loop. Examples: typing challenge, puzzle board, arcade dodger, memory game.

A capstone combines the course skills into one coherent artifact. A milestone is a checkpoint with acceptance criteria you can verify before moving on.

Start with a design sketch

Use this playground only as a warm-up. It helps you choose a track and name the evidence your project must produce. The real work happens in your own repository with your editor, terminal, Git history, tests, and deployment target.

→ Full-stack app with Node: Study Sprint Board
→ A learner can plan study sprints, track progress, and recover from failed saves without losing work.
→ evidence checks: 6

Before you create files, write one paragraph that answers: who is this for, what can they do when it works, and what is deliberately out of scope? That paragraph will become the top of your README.

Milestone 1: choose the smallest real scope

Begin with the user promise, not the framework. Your first design document can be short: one page, a README section, or an issue. It should name the track, the happy path, the riskiest failure path, and the proof you will collect.

Acceptance criteria:

• The project has one chosen track, not a blend of all five.
• The README starts with the problem, intended user, and main workflow.
• You can finish a demoable version in days or weeks, not months.
• You have a "not doing yet" list that protects the scope.
• The project can be run locally from documented commands.

Useful back-references: What Is Programming & Why JavaScript for input -> process -> output thinking, and Principles of Good Design for restraint around DRY, YAGNI, names, and module boundaries.

Milestone 2: model the data and core behavior

Write the data shapes before the UI becomes busy. Decide what arrays, objects, Maps, Sets, strings, numbers, booleans, and JSON boundaries represent in your project. Then write pure functions for the core rules.

Acceptance criteria:

• Core values have clear names and examples in the README or docs.
• Arrays, objects, Maps, and Sets are chosen by the question the code asks most often.
• Core logic lives in small functions or modules that can run without the browser, server, database, or framework.
• Object mutation is intentional; immutable updates are used where state history or UI rendering needs them.
• Invalid or missing data is handled at the boundary before core logic trusts it.

Useful back-references: Choosing the Right Data Structure, map, filter, reduce, Object Literals & Properties, and Design Patterns in JavaScript.

Milestone 3: build the runtime boundary

Now connect your core to the environment your track needs.

Track-specific acceptance criteria:

• Full-stack app: a browser UI talks to a Node route/API, validates request data, and persists at least one real resource.
• Framework front-end: components render from state, handle user actions, route between views when useful, and show async states.
• npm library: public exports are intentional, examples import the package shape users will actually use, and internals stay private.
• CLI tool: command arguments or file inputs are parsed, validation failures print useful messages, and success/failure exit behavior is documented.
• Browser game: input, state update, rendering, collision/rule checks, and restart flow are separate enough to test or inspect.

Useful back-references: State -> Render: UIs Without a Framework, fetch() & REST APIs, The Node Runtime, Building an HTTP API, ES Modules in Depth, Why Frameworks Exist, and React in Focus if React is your chosen framework.

Milestone 4: make async and failure honest

Every real project waits on something: a timer, a file, a request, a database, a user gesture, or a frame. Do not leave the happy path as the only path.

Acceptance criteria:

• Loading, empty, success, and failure states are visible where the user waits.
• Expected failures are handled as product behavior, not surprise crashes.
• Network/file/database errors are logged or displayed with enough context to debug.
• Cancellation, retry, timeout, or stale-result behavior is handled when your workflow needs it.
• No secret values live in source code or browser bundles.

Useful back-references: Handling Failure Like a Pro, Debugging in DevTools, and Environment, Config & Deployment.

Milestone 5: wire tooling and tests

Your capstone is not finished because it worked once on your machine. It needs repeatable checks.

Acceptance criteria:

• package.json scripts document the project contract: at minimum setup/run plus the checks your track needs.
• Linting and formatting are configured or deliberately scoped.
• Unit tests cover important pure logic and at least two edge or failure cases.
• UI, CLI, package, or API tests cover the main user workflow at the right level.
• A fresh clone can run the documented checks without guessing.

Useful back-references: Build Tools & Vite, Testing Fundamentals, and Unit Testing with Vitest.

Milestone 6: use Git, review, and AI like a professional

Treat your own capstone like a project someone else may review.

Acceptance criteria:

• Commits are coherent snapshots with messages that explain the change.
• The branch or pull request description lists the problem, solution, tradeoffs, and checks.
• Any generated AI help is reviewed, tested, and understood before it stays in the project.
• You can point to one place where feedback, review, or a second pass improved the design.
• The repository does not contain secrets, private data, generated dependency folders, or local-only noise.

Useful back-references: Git Fundamentals, Code Review & Working on a Team, Working with AI Effectively, and Using AI Responsibly.

Milestone 7: performance, design, and polish

Polish does not mean decoration. It means the main workflow is understandable, responsive, and maintainable.

Acceptance criteria:

• The main screen or command has a short demo script you can repeat.
• Performance work starts from an observed problem or explicit budget, not guessing.
• Large dependencies, assets, or expensive operations are justified.
• Modules have sharp public edges and private helpers.
• Names reveal domain meaning and side effects.
• The final UI, CLI output, package API, or game loop has no obvious dead ends in the happy path.

Useful back-references: Profiling & Web Performance, Principles of Good Design, and Becoming a JavaScript Professional.

Final deliverables

By the end, your repository should contain:

• A README with problem, track, setup, usage, screenshots or demo notes where useful, verification commands, and known limits.
• A runnable project with the smallest complete happy path.
• Source modules with clear boundaries between core logic and runtime details.
• Tests or smoke checks appropriate to the track.
• A documented failure story: what can go wrong and how the project responds.
• A Git history or PR that makes the work reviewable.
• A short portfolio/resume paragraph that states what you built, the tradeoffs, and the evidence.

Example portfolio paragraph:

Built Study Sprint Board, a full-stack JavaScript app for planning study sprints.
The browser UI renders from state, the Node API validates task updates, expected save
failures render recoverable UI, and Vitest covers scheduling rules plus failed-save
paths. The README documents setup, checks, deployment notes, and known limits.

Stretch goals

Choose only after the base project ships:

• Add a second persistence adapter: memory plus file, SQLite, Postgres, IndexedDB, or hosted storage.
• Add accessibility and keyboard-flow checks to the main UI.
• Add a preview deployment or package publish dry run.
• Add a small performance budget and record before/after evidence.
• Ask someone else to review one module boundary and one user workflow.
• Write a short postmortem: what changed from the original plan and why.

How to get unstuck

If the project feels too big, cut scope until the happy path fits on one page. If the data feels loose, return to Choosing the Right Data Structure. If the UI is scattered, return to State -> Render: UIs Without a Framework. If async failure is vague, return to Handling Failure Like a Pro. If the project is hard to test, return to Testing Fundamentals. If the design is hard to explain, return to Design Patterns in JavaScript and Principles of Good Design.

You have the full loop now: think in values, shape data, write functions, model objects, handle async work, build browser and server boundaries, use tools, test behavior, collaborate with Git, verify AI help, choose frameworks deliberately, measure performance, and design with taste.

Ship the smallest honest version. Make it run, make it readable, make it reviewable, and make it yours.