Capstone Ideation and Problem Selection — CS50

"A project idea is where curiosity meets constraints — and constraints are your new best friend."

You've already learned how to use Git, set contribution guidelines, and think about licensing and governance for a team repo. Great — those are the tools and rules of the road. Now the important human question: what on earth are you going to build? Welcome to Ideation and Problem Selection, the moment where inspiration, empathy, and hard truth collide. This guide helps you pick a capstone problem that's meaningful, doable, and impresses both your peers and your future self.

Why this matters (and why naive enthusiasm can betray you)

• Real capstones ship — professors, TAs, and future employers care more about a well-executed small project than an under-delivered ambitious one.
• Scope is the silent killer — big ideas die slowly from feature creep. Choosing a problem wisely saves your time, sanity, and grades.
• Your repo isn't magic — Git, contribution guidelines, and licensing set the infrastructure. But a messy idea will still produce messy commits and unhappy merge conflicts.

This is about matching ambition with reality.

The FRAME test: a quick filter for ideas

When a cool idea hits, run it through this five-part filter:

• F — Feasibility: Can you build an MVP within the semester with your current skill set (or reasonable upskilling)?
• R — Relevance: Does it solve a real problem for real people (not just "it would be cool")?
• A — Ambition: Is it interesting enough to learn from but not so grandiose it collapses?
• M — Maintainability / Modularity: Can the project be split into clear components for parallel work and future contributors? (Think: front end, API, DB, tests.)
• E — Ethics & Licensing: Any privacy, bias, or copyright risks? Does your licensing plan fit dependencies and your deliverable goals?

Quick verdict: if anything fails dramatically, either redesign the idea or pick a different problem.

Practical steps to go from fuzzy idea to chosen problem

1) Brainstorm with constraints (15–30 minutes)

• Timebox the session.
• Everyone writes 3 ideas on sticky notes (or in a shared doc). No debate. No death threats.
• Cluster similar ideas. Name clusters.

2) User and stakeholder map (30–60 minutes)

• Who benefits? Who's harmed? Who pays? Who uses it daily?
• Sketch basic user journeys and edge cases.

Why this matters: your future demo will be judged by how intuitively it solves a real user's problem.

3) Rapid feasibility check (30 minutes)

For the top 3 ideas, quickly ask:

• What are the core technical components? (DB, auth, scraping, ML model…)
• Data needs: public dataset, simulated data, user input?
• Known blockers: rate limits, paid APIs, hardware, or legal restrictions?
• Required skills: Do you need to learn a framework? Is that reasonable?

4) MVP definition (1–2 hours)

For the leading idea, create a single-paragraph MVP description: "A minimal app that does X for Y by doing Z." Example:

"An event-scheduling web app that allows students to propose study groups and automatically finds 3 time slots that maximize availability using their calendar free/busy data. MVP includes sign-up, proposing an event, and an algorithm that suggests times."

Then write a 6-week milestone plan and assign responsibilities (UI, backend, data, tests, presentation).

5) Ethics & licensing check (30 minutes)

• Does the project collect personal data? If so, how is it stored and who can access it?
• Any licensed data or libraries requiring permissive vs. copyleft licenses? Match with your repo license.
• If your project could be harmful, add safeguards or pick a different idea.

Relate this to previous module: your license and contribution guidelines should already reflect these decisions — update them if the project's legal/ethical profile changed.

Good idea vs. Bad idea (with examples)

Good idea (scoped): "Classroom Polling Tool"

• Single core feature: create polls, students vote, results visualize.
• Uses a public JS charting lib; stores votes in a simple DB.
• Ethics: anonymous voting by default, no PII stored.
• Git plan: feature branches per component, small PRs, CONTRIBUTING.md updated.

Bad idea (too big): "Autonomous Research Assistant with Web-Scale Crawling and ML Summaries"

• Too many heavyweight parts (web crawling, large language model fine-tuning, scalability, legal risk).
• Likely blocked by API costs and dataset licensing.
• Better to take a smaller, focused slice (e.g., summarizer for short, public articles with no crawling).

Team organization & governance (tie-in to Version Control and Collaboration)

You've set up the repo rules; now use them to enforce good ideation outcomes:

• Create an IDEATION.md or project README that contains your MVP, milestones, and risk log.
• Use issues to track features, and label them mvp, nice-to-have, and blocked.
• Make a simple branching strategy: main for demos, feature branches for work, sprints using GitHub Projects or issues.
• Contribution guidelines should include how to propose features or change scope (e.g., feature request issue template).

"If it's not in the repo's roadmap, don't merge it." Treat the roadmap like a social contract for the team.

Quick decision rubric (3–2–1)

Rate each candidate idea on a 3–2–1 scale across these axes: Feasibility, Value, Ethics.

• 3 = Strong (buildable, high value, no ethical red flags)
• 2 = OK (some work, modest value, small concerns)
• 1 = Risky (unlikely to finish, low value, ethical/legal issues)

Add scores across the axes and pick the highest. If tied, choose the simpler one.

Final checklist before you commit to an idea

• MVP fits into semester milestones
• Team can split work into parallel tasks
• No major legal or privacy blockers
• Data sources are accessible or mockable
• Licensing for code/deps is compatible and documented
• Repo has an IDEATION.md and updated CONTRIBUTING.md
• At least one demo-ready slice can be shown by midterm

Key takeaways

• Scope ruthlessly. The most graduate-level-looking demo is a small, polished, working product — not an unfinished epic.
• Use your governance tools. Your Git workflow and contribution rules aren't bureaucracy; they're the scaffolding that keeps the project moving.
• Design with a user in mind. Problems that solve specific user pain points win more than clever tech for its own sake.
• Validate early and ethically. Quick user feedback and a licensing checkbeat feature bloat and legal headaches.

"This is the moment where the concept finally clicks." Pick an idea you can explain in one sentence, ship a working slice quickly, and iterate. Your Git history will look clean, your demo will shine, and you'll graduate to the next thing with fewer scars.

Good luck — and remember: brilliant ideas are everywhere, but brilliant execution is rare. Be the rare one.