Scoping and MVP for CS50 Capstones: Focus, Not Feature Frenzy

"Less is better, faster, and more demo-friendly." — Probably your future grader

You already picked a problem that matters (Ideation and Problem Selection) and wrote down what success looks like (Defining Success Criteria). Now comes the part where dreams meet deadlines: scoping and building an MVP. This is where ambitious creativity gets tempered by time, sanity, and Git branches.

---

Why scoping and MVP matter (beyond 'get to a demo')

• You prove value early. An MVP shows the core idea actually works for users.
• You reduce risk. Fewer moving parts → fewer bugs, fewer late-night meltdown commits.
• You get feedback while there's still time to pivot.

Think of your capstone like cooking for a dinner party. You could attempt a seven-course molecular gastronomy nightmare, or you could perfect a killer main and dessert that actually taste good. The MVP wins every time.

---

Step 1 — Start with the core user story

A user story is a one-liner that explains what a user wants and why. Keep it laser-focused.

Example: Student user story for a flashcard app

• "As a student, I want to create, review, and track flashcards so I can study for quizzes effectively."

Now strip that down to the absolute core: what part of that single story would still demonstrate the app's value if everything else disappeared?

• Minimum core: Create a flashcard, review flashcards, track correct/incorrect count.

Micro explanation

Core user story = the spine of your MVP. Everything else (sharing, spaced repetition, analytics dashboards) are toppings.

---

Step 2 — Must-have vs Nice-to-have vs Stretch

Make a simple table. Commit it to your README or project board.

Category	Examples (flashcard app)
Must-have	Create flashcard, display deck, answer flashcard, record score
Nice-to-have	Sign in, sync across devices, deck import/export
Stretch	SRS algorithm, collaborative decks, mobile offline support

Why this matters: use it to decide what gets built before the demo and what becomes a post-demo roadmap.

---

Step 3 — Translate must-haves into milestones and issues

Use your repo and project board (you learned Git and collaboration already — time to use Issues). A suggested milestone breakdown for a 6-week capstone sprint:

1. Week 1: Wireframes + Data Model + Core API endpoints
2. Week 2–3: CRUD for flashcards + local review flow
3. Week 4: Basic UI polish + automated tests + user auth (if needed)
4. Week 5: Integrations, deployment, demo flow
5. Week 6: Buffer, bugfixes, rehearsed demo

For each milestone, create GitHub Issues and link PRs to issues. Use small, testable tasks.

---

Step 4 — Keep scope small with an acceptance criteria checklist

For each must-have feature, write 2–4 acceptance criteria. These become your definition of "done" and map to your success criteria.

Example: "User can create flashcard"

• Form saves card to DB
• Created card appears in deck immediately
• Error shown if front/back empty
• Unit test for creation API

Acceptance criteria turn vague hopes into pass/fail items you can demo and test.

---

Step 5 — Prototype fast, iterate faster

Start with the quickest prototype that exercises the core loop.

Options:

• Paper or Figma wireframe to validate flows
• Static HTML mock to test UX with friends
• Minimal backend stub (JSON file) to simulate API

Get real eyes on it early. Aim for observational feedback not "doesn’t this look great?" Ask users to perform tasks.

---

Step 6 — Use Git like the team you want to be

You already know version control. Now apply it to scope control:

• Create branches per issue, not per developer ego
• Keep PRs small, focused, and linked to specific issues/milestones
• Use draft PRs to show work-in-progress design choices
• Protect your main branch and make demos come from a known commit or tag

Example Git workflow commands (concise):

# create feature branch
git checkout -b feature/create-flashcard

# work, commit, push
git add .
git commit -m 'Add API route for creating flashcard'  # use single quotes
git push -u origin feature/create-flashcard

# open PR, link to issue, request review

Pro tip: add a tiny demo script in your repo that seeds data and opens the demo page so reviewers see the MVP instantly.

---

When to say "no" (or "later")

Ask these questions whenever a new feature proposal arrives:

• Does it directly enable the core user story?
• Will it be visible in the demo and easy to understand?
• Can it be built, tested, and deployed reliably within the time left?

If the answer is no to any, shelve it as "future work" and add it to your README roadmap. That shows maturity.

---

Quick example: Scoping a Ride-Sharing Study Group App

Core user story: As a student, I want to find nearby classmates heading to the same lecture.

Must-haves: search for rides, request to join, accept/decline.

Nice-to-have: ratings, chat, route optimization.

Stretch: payment splitting, live GPS.

Milestone plan:

1. Basic DB + search (week 1)
2. Request/accept flow + notifications (week 2–3)
3. UI polish + deploy (week 4)
4. Testing + buffer + final demo prep (weeks 5–6)

---

Closing: Key takeaways

• Scope is your friend. It keeps your demo coherent and your nights human.
• MVP = core user story + clear acceptance criteria + a demoable pipeline.
• Use Git, issues, and milestones to make scope visible and accountable.

Remember: an MVP that works reliably and proves your thesis beats a half-broken swiss-army-knife of features. Your demo should make someone say, "I would actually use this." That's your win.

Action item: Right now, write one core user story for your project and list three must-haves. Put them in an Issue and branch for the first task. Demo-ready momentum begins the moment you commit.

---

Quick checklist to paste into your README

• Core user story written
• 3 must-have features identified
• Milestone schedule created
• Acceptance criteria for each must-have
• Initial prototype or seeded demo script
• Linked issues and PR workflow setup

Good luck — scope like a scientist, build like an artist, and demo like you mean it.