Course resource
Example Capstone Gallery
Six worked examples at the scope a capstone should actually be. Each shows the problem, the build, the measured result, and what went wrong — because the failures are the useful part.
These are illustrative reference builds, not student submissions.
1. The invoice chaser
Problem. A freelance designer spent about 40 minutes each Monday checking which invoices were unpaid and writing chasers.
Build. Scheduled trigger → read the invoices sheet → filter to overdue → AI drafts a chaser matched to how overdue it is → drafts land in the email client for review.
Result. 40 minutes → 6 minutes. Average days-to-payment fell from 34 to 27, mostly because chasers now actually went out.
What went wrong first. The first version sent automatically. It chased a client who had paid the day before, because the sheet was a day stale. Draft-first fixed it permanently.
Why it works as a capstone: small, weekly, measurable, and the failure taught the draft-first rule properly.
2. The support triage
Problem. A two-person SaaS team got 30–50 support emails a day, all landing in one inbox, urgent ones buried.
Build. New email → filter to the support address → AI classifies category and urgency → urgency 4–5 posts to chat immediately, everything else gets labelled and logged.
Result. Median response time on urgent issues: 4 hours → 25 minutes. No change to overall volume handled.
What went wrong first. The classifier ran at default temperature and gave different answers to identical emails. Dropping it to 0.1 fixed it. The second problem was "Billing." with a full stop not matching "billing" — everything fell to the fallback for two days.
3. The research digest
Problem. A policy analyst read six sources every morning, taking 45 minutes, and still missed things.
Build. Scheduled trigger → pull from six RSS feeds → de-duplicate → AI summarises and ranks by relevance to three named topics → one email at 07:15.
Result. 45 minutes → 8 minutes. Reported catching two significant items in the first month that they would have missed.
What went wrong first. Version one summarised everything and ran to 2,000 words — no better than reading the sources. Adding "if nothing meets the bar, write Nothing" and capping it at 250 words made it usable.
4. The onboarding assistant
Problem. A 40-person company answered the same new-starter questions constantly.
Build. A custom assistant with twelve cleaned policy documents, instructed to answer only from them and hand off otherwise, in a chat channel.
Result. About 60% of new-starter questions answered without a human. Handoffs logged, and the top three gaps became three new documents.
What went wrong first. Two versions of the expenses policy in the knowledge files meant it gave both answers at random. Deleting the old one fixed it. This is the most common knowledge-file failure there is.
5. The quote builder
Problem. A building contractor spent 2–3 hours per quote, transcribing site notes into a formatted document.
Build. Voice note → transcription → AI extracts line items into a structured table → populates a quote template → contractor reviews and prices.
Result. 2.5 hours → 40 minutes. Quotes went out same-day instead of at the weekend, which they believed won them work.
What went wrong first. The extraction invented plausible quantities when the voice note was vague. Adding "use null if not stated; never infer a quantity" removed it entirely.
6. The lesson planner
Problem. A secondary teacher spent Sunday evenings building differentiated worksheets for three ability levels.
Build. A custom assistant holding the curriculum spec, the school's format, and examples of the teacher's own worksheets. One topic in, three differentiated versions out.
Result. 3 hours → 50 minutes, including review. Quality judged equivalent by a colleague blind to which were AI-assisted.
What went wrong first. Early output was generic because the assistant had the curriculum but no examples of the teacher's actual style. Uploading six past worksheets changed everything — the lesson being that examples beat description.
The patterns
Reading across all six:
Every one is narrow. One task, done weekly or daily. None tried to be a system.
Every one has a number. Before and after, measured, not estimated.
Every one keeps a human in the loop at the point where being wrong would cost something.
Every one broke the first time, and the fix was almost always a prompt constraint rather than a better model.
None of them are impressive in isolation. They are useful, which is the point. A capstone that saves you forty minutes every week is worth more than a demo that impresses a room once.
The failures that did not make the gallery
Common shapes of unfinished capstone:
- Too broad. "An AI assistant for my whole business." No definition of done, never finished.
- No real user. A chatbot for a business the student did not run. No feedback, no motivation.
- Data that did not exist. Turned into a data-collection project and stalled.
- No baseline. Finished, but could not show it helped.
- Rebuilt an existing tool. Working, but pointless.
Your turn
| Which example is closest to my problem | |
| What I would change about their approach | |
| What I expect to go wrong first |
That last row is worth taking seriously. In every example above, the first failure was predictable in hindsight.