Choosing What to Build

This decision matters more than anything you do afterwards. Most weak capstones were weak the moment the project was chosen — no amount of skill rescues a badly-scoped project, and a well-scoped one is hard to get wrong.

Nine weeks of technique now get pointed at one real problem of yours.

---

1. What makes a good capstone

Six criteria. You need all six, not most of them.

• It solves a problem you actually have. Not a hypothetical one, not one you imagine a business might have.
• You will still use it in three months. The real test of whether it was worth building.
• It saves measurable time, or removes a specific annoyance you can name in one sentence.
• 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. That is not a failure — choosing again at this stage costs ten minutes, and choosing wrong costs the whole project.

---

2. Finding candidates

Do not look at a list of AI project ideas. Look at your own last two weeks.

• 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 difficult?
• What question do colleagues or customers ask you repeatedly?
• What information do you 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. Manual copying between systems is repetitive, measurable, low-risk, and immediately obviously useful.

---

3. The selection grid

Write down five candidates. Do not skip to one.

Project	I have this problem	Saves real time	Buildable in 6h	Can demo it	Will still use it	Total

Score each 1–5. Take the highest total. If two tie, take the one you would use more often — frequency beats impressiveness.

---

4. Shapes that work

You have already built all of these. Pick the one your problem fits.

Shape	Example	Why it works as a capstone
Triage	Incoming requests sorted and routed	Clear before/after, low risk, easy to measure
Digest	One daily summary replacing six checks	Immediately, obviously useful
Draft-first	Replies drafted for you to send	High time saving, safe by design
Extraction	Unstructured text into a structured record	Very measurable, very reliable
Assistant	A custom assistant with your knowledge files	Easiest to demonstrate

---

5. Shapes that fail

Worth naming, because these are the projects that do not get finished.

"An AI that does my job." Too broad. No definition of done, so it is never done.

Anything customer-facing on day one. The risk profile is wrong for a first build. Build it internal, prove it, then consider exposing it.

Something you do monthly. You will not accumulate enough runs to know whether it works.

A chatbot for a business you do not run. No real user, no feedback, no motivation past week two.

Something needing data you do not have. It quietly becomes a data-collection project and stalls.

Rebuilding something that already exists. If an off-the-shelf tool does this, use it and build something else.

---

6. Scoping v1

Write this down before you build anything. 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:            [ME / MY TEAM / A CLIENT]
How often it happens:
Time it takes now:

V1 DOES:
- [THREE THINGS. MAXIMUM.]

V1 DOES NOT DO:
- [BE EXPLICIT. THIS IS THE IMPORTANT LIST.]

DONE LOOKS LIKE:
[One 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 every time you are tempted to add something. Every capstone that overruns does so one small addition at a time.

---

7. The baseline

Do the task manually, once more, and record it honestly.

Task
Time taken, measured
Number of steps
Where the time actually went
Error rate, if relevant
How annoying, 1–5

Measure it. Do not estimate it. Without a baseline you cannot demonstrate improvement, and "it feels faster" is not a capstone result. This is the single most commonly skipped step and the one most regretted at submission.

---

8. The risk check

Before you build, answer four questions:

• If this runs wrong 100 times before I notice, what is the damage?
• Does it touch customer or personal data? If yes, re-read the privacy rules before starting.
• Does it send anything? If yes, make it draft-first.
• What breaks if the tool I build on is down?

If the answer to the first question is more than "annoying", a human goes before the output.

---

9. Your commitment

Project
Why this one
V1 scope, three things
Explicitly out of scope
Baseline, measured
Target
Hours I will spend before stopping
Demo date

Set the hours row now, at six to eight. 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, because it is the part that demonstrates judgement.

---

⚠️ Common Mistakes

• Picking the biggest problem. Pick the one you can finish. A completed small pilot buys permission for the big one.
• Skipping the baseline. You cannot show improvement against a number you never took.
• No "does not do" list. Scope creeps invisibly and the project never ships.
• Choosing something you do monthly. Not enough runs to learn from.
• Choosing to impress rather than to use. If you will not run it in month three, it was a demo, not a system.
• Starting to build before writing the scope. Ten minutes of writing saves days of drift.

---

What's Next: You know what you are building. Now design it before you open a single tool.