Scoping a project you'll finish

Welcome to the capstone. Instead of learning one more concept, you'll build one real app end to end — a task manager (a to-do app) — and ship it live. But first, the single most important skill for actually finishing: scoping a project you'll finish. Most projects die from being too big. Let's scope smart. Let's plan a project you'll actually finish.

Why projects die — and how to scope one that ships

THE #1 REASON PROJECTS NEVER GET FINISHED: they're TOO BIG. Beginners plan a huge app (a whole
social network, a full clone of some app) with dozens of features -> get overwhelmed, stuck, or
bored -> never finish. A FINISHED small app beats an UNFINISHED big one every time.

THE SKILL: SCOPE SMALL. Define the SMALLEST version that's still USEFUL + COMPLETE, build THAT,
ship it, THEN add more. This is the "MVP" idea (Minimum Viable Product) — the leanest thing that
actually works.

DEFINE YOUR MVP — answer these:
- WHAT does the app DO (in one sentence)? e.g. "It lets me add tasks, see my list, + delete
  done ones."
- WHO is it for + WHAT problem does it solve? (Even if it's just YOU.)
- The CORE FEATURES (the must-haves) — the fewest features that make it useful. For a task app:
  ADD a task, SEE the list, DELETE a task. That's a complete, useful app.
- The NICE-TO-HAVES (later) — everything else (edit, due dates, categories, accounts, sync).
  Write them down — but DON'T build them yet. Ship the core first.

CUT SCOPE RUTHLESSLY: if a feature isn't in the "smallest useful version", it goes in the "later"
list. You can always add more AFTER it works + ships. Finishing > perfect.

The #1 reason projects never get finished: they're too big. Beginners plan a huge app (a whole social network, a full clone of some app) with dozens of features → get overwhelmed, stuck, or bored → never finish — a finished small app beats an unfinished big one every time. The skill: scope small — define the smallest version that's still useful and complete, build that, ship it, then add more (this is the "MVP" idea — Minimum Viable Product — the leanest thing that actually works). Define your MVP — answer these: what does the app do (in one sentence — "it lets me add tasks, see my list, and delete done ones"); who is it for + what problem does it solve (even if it's just you); the core features (the must-haves — the fewest features that make it useful — for a task app: add a task, see the list, delete a task — that's a complete, useful app); and the nice-to-haves (later) (everything else — edit, due dates, categories, accounts, sync — write them down but don't build them yet — ship the core first). Cut scope ruthlessly: if a feature isn't in the "smallest useful version," it goes in the "later" list — you can always add more after it works and ships — finishing beats perfect.

What we'll build in this capstone

OUR CAPSTONE PROJECT: a TASK MANAGER (to-do app) — the classic "real app" that touches
everything. We'll build it end-to-end + ship it. The plan (each = a lesson):

FRONT-END (what runs in the browser — you'll build this LIVE, runnable, in these lessons):
- The HTML SKELETON — the structure (input, button, list).
- STYLING the layout with CSS — make it look good.
- RENDERING tasks from a JS ARRAY — show the list from data.
- ADDING items — a working "add task" feature.
- EDITING + DELETING — change + remove tasks.
- SAVE/LOAD with localStorage — persist tasks so they survive a refresh.
- The COMPLETE app with persistence — it all working together.

BACK-END + SHIPPING (the concepts + how real apps go further):
- FRONT-END vs BACK-END — what each is + why you need a back-end.
- TALKING TO AN API (fetch) — get data from a server.
- WIRING YOUR OWN REST API — a simple back-end (Node/Express) for your app.
- BACK-END ENVIRONMENT SECRETS — keys/config kept safe.
- DEPLOYING the front-end — put it LIVE on the internet (free).
- WHERE TO GO NEXT — grow the app + your skills.

By the end you'll have BUILT + SHIPPED a real, working app — the thing that turns "I'm learning
to code" into "I built this." That's the portfolio piece + the confidence. Scope it small, build
the core, ship it — then grow it.

THE PRINCIPLE: the skill that gets projects FINISHED is SCOPING SMALL — define the MVP (the
smallest useful, complete version: for a task app = add/see/delete), build THAT, ship it, + add
nice-to-haves LATER. We'll build + ship a TASK MANAGER end-to-end. A finished small app beats an
unfinished big one. Let's build something real.

Our capstone project: a task manager (to-do app) — the classic "real app" that touches everything — we'll build it end-to-end and ship it. The plan (each = a lesson): the front-end (what runs in the browser — you'll build this live, runnable, in these lessons) — the HTML skeleton, styling with CSS, rendering tasks from a JS array, adding items, editing + deleting, save/load with localStorage, and the complete app with persistence; then back-end + shipping (the concepts + how real apps go further) — front-end vs back-end, talking to an API (fetch), wiring your own REST API (Node/Express), back-end environment secrets, deploying the front-end (live, free), and where to go next. By the end you'll have built and shipped a real, working app — the thing that turns "I'm learning to code" into "I built this" — that's the portfolio piece and the confidence — scope it small, build the core, ship it, then grow it. The principle: the skill that gets projects finished is scoping small — define the MVP (the smallest useful, complete version: for a task app = add/see/delete), build that, ship it, and add nice-to-haves later; we'll build and ship a task manager end-to-end; a finished small app beats an unfinished big one — let's build something real.

The mistake beginners make

The first mistake is scoping too big — planning a massive app with dozens of features, then never finishing (the #1 project killer); scope small (define the MVP). The second mistake is no clear MVP — building without deciding the smallest useful version, so it sprawls; define the core features (must-haves) first. The third mistake is building nice-to-haves first — adding fancy extras before the core even works; build the core first, extras later. And not writing the plan down — keeping it all in your head, so scope creeps; write the one-sentence purpose, core features, and later list. And perfectionism over finishing — polishing endlessly instead of shipping; finishing beats perfect (ship, then improve). Scope small, define the MVP, build the core first, write the plan down, and prioritise finishing.

Your turn

---

Your turn

1. Understand why projects die: recognise the #1 reason is scoping TOO BIG - a finished small app beats an unfinished big one every time.
2. Define your app in one sentence: state what it does simply (e.g. 'It lets me add tasks, see my list, and delete done ones') - the whole point of the app.
3. List the core features (MVP): write the fewest must-have features that make it useful - for a task app: add a task, see the list, delete a task. That's a complete, useful app.
4. Park the nice-to-haves: write down everything else (edit, due dates, categories, accounts, sync) in a 'later' list - and commit NOT to build them until the core ships.
5. Commit to the capstone plan: note you'll build + ship a real task manager - front-end (HTML/CSS/render/add/edit-delete/localStorage) then back-end concepts + deploying - finishing over perfect.

Key points

• The #1 reason projects never finish: they're TOO BIG (dozens of features -> overwhelmed/stuck -> never shipped). A FINISHED small app beats an UNFINISHED big one. The skill: SCOPE SMALL.
• Define your MVP (Minimum Viable Product — the smallest useful, complete version): WHAT it does in one sentence, WHO it's for + what problem it solves, the CORE FEATURES (fewest must-haves — for a task app: ADD / SEE / DELETE), and the NICE-TO-HAVES (a 'later' list — written down but NOT built yet).
• CUT SCOPE ruthlessly: if a feature isn't in the smallest useful version, it goes in the 'later' list. Build the core, ship it, THEN add more. Finishing > perfect.
• The capstone: build + ship a TASK MANAGER end-to-end — FRONT-END (HTML skeleton -> CSS -> render from an array -> add -> edit/delete -> localStorage persistence -> complete app; all runnable live) then BACK-END + SHIPPING (front-end vs back-end, fetch an API, wire your own REST API, env secrets, deploy the front-end, where to go next).
• The mistakes: scoping too big (scope small — define the MVP), no clear MVP (list the core must-haves), building nice-to-haves first (core first), not writing the plan down (scope creeps), and perfectionism over finishing (ship then improve).