Course resource
Capstone Project Selection
Choosing what to build. This decision matters more than anything you do afterwards — most weak capstones were weak the moment the project was chosen.
What makes a good capstone
- It solves a problem you actually have. Not a hypothetical one.
- You will still use it in three months. The test of whether it was worth building.
- It saves measurable time, or removes a specific annoyance you can name.
- You can build v1 in under six hours. Ambition kills more capstones than incompetence.
- You can demonstrate it in two minutes.
- Something can be measured before and after.
If you cannot tick all six, pick something else.
The selection grid
List five candidates. Score each 1–5.
| Project | I have this problem | Saves time | Can build in 6h | Can demo it | Will still use it | Total |
|---|---|---|---|---|---|---|
Pick the highest total. If two tie, pick the one you would use more often.
Where to find candidates
Look at your own week, not at a list of ideas:
- What did you do more than three times this month that felt identical each time?
- What do you put off because it is tedious rather than hard?
- What question do colleagues or customers ask you repeatedly?
- What information do you go and gather from the same four places every week?
- What do you copy from one place to another by hand?
The last one is almost always a good capstone.
Shapes that work
| Shape | Example | Why it works |
|---|---|---|
| Triage | Incoming requests sorted and routed | Clear before/after, low risk |
| Digest | One daily summary replacing six checks | Immediately obviously useful |
| Draft-first | Replies drafted for you to send | High time saving, safe |
| Extraction | Unstructured text into a structured record | Very measurable |
| Assistant | A custom assistant with your knowledge files | Easy to demo |
Shapes that fail
"An AI that does my job." Too broad. No definition of done.
Anything customer-facing on day one. The risk is wrong for a first build.
Something you do monthly. You will not have enough runs to know whether it works.
A chatbot for a business you do not run. No real user, no real feedback, no motivation to finish.
Something needing data you do not have. The project becomes a data-collection project.
Rebuilding something that already exists. If a tool does this off the shelf, use it and build something else.
Scoping v1
Write these before you start. The scope creeps otherwise, and an unfinished capstone teaches you less than a small finished one.
PROJECT: [NAME]
The problem, in one sentence:
Who has it: [YOU / YOUR TEAM / A CLIENT]
How often it occurs:
Time it currently takes:
V1 DOES:
- [THREE THINGS MAXIMUM]
V1 DOES NOT DO:
- [BE EXPLICIT — THIS IS THE IMPORTANT LIST]
DONE LOOKS LIKE:
[A SENTENCE ANYONE COULD CHECK]
SUCCESS MEASURE:
Before: [TIME / EFFORT / ERROR RATE]
Target after:
The "does not do" list is the one that saves you. Write it before you build and reread it whenever you are tempted to add something.
The baseline
Do the task manually once more and record it honestly:
| Task | |
| Time taken | |
| Steps involved | |
| Where the time actually went | |
| Error rate, if relevant | |
| How annoying, 1–5 |
Without a baseline you cannot demonstrate improvement, and "it feels faster" is not a capstone result.
The risk check
Before building, answer:
- If this runs wrong 100 times before I notice, what is the damage?
- Does it touch customer data? If yes, check the privacy rules first.
- Does it send anything? If yes, make it draft-first.
- What breaks if the tool I build on goes down?
Your commitment
| Project | |
| Why this one | |
| V1 scope, three things | |
| Explicitly out of scope | |
| Baseline | |
| Target | |
| Hours I will spend before stopping | |
| Demo date |
That second-to-last row is a real constraint. Set it now, at six to eight hours, and when you reach it, ship what you have and write up what you learned. A finished small thing beats an abandoned ambitious one, and the write-up is worth as much as the build.