Course B · Module B3 Capstone · Lesson 16 of 18

Choose Your Capstone

Pick one real app with one real production concern.

~15 min · Blank doc or notepad ready · Prereq: B15 (Build Your Own Skill)

Every course that ends with "now go build something" fails unless "something" is specific. Vague ambitions don't ship. Your single win from this lesson: by the end you'll have written a one-paragraph build brief with a name, a narrow job, at least one real production concern (auth, real data, or payments), and a crisp definition of done. That brief is your launchpad for the next two lessons.

What makes a good capstone

Think of a good capstone the way a good knife is good: one sharp edge used for one job, not a Swiss Army blade that tries to do everything. The best small apps solve one narrow problem so cleanly that someone reaches for them every week. Wide scope is the number-one reason first builds never ship.

The other ingredient: at least one real production concern. If your app has no auth, no live data, and no payments, it's a prototype — useful for learning but not something you'd hand to a customer with confidence. Crossing that line, even once, is what separates a demo from a product.

Good capstone candidates

A simple client portal where customers log in and see their project status
A one-product checkout page that takes real payments
An internal tool that reads from your own database and outputs a weekly report
A waitlist app that captures emails and notifies you on signups

Scope traps to avoid

"A platform where users can…" — more than one user job = two capstones
Anything that needs a mobile app before it's useful
Builds where "done" depends on another person finishing something first
A full e-commerce store — too many moving parts for a capstone sprint

The three production concerns

You don't need all three. You need at least one. This is what makes the build real rather than a toy — and it's what this course has been preparing you for:

AuthUsers can create an account and log in. Their data is theirs. Covered in B6.

Real dataThe app reads from or writes to a live database — not a hard-coded demo. Covered in B5.

PaymentsReal money moves through Stripe. You've tested it in test mode before going live. Covered in B8.

Write your capstone brief

Use this checklist to draft your brief before moving to B17. A brief that passes all six checks is ready to build. One that fails any of the first four needs another pass — going wider or shallower here costs you a week of wasted sprint, not an afternoon of planning.

Capstone brief checklist:

Name & one-sentence pitch. What is it called and what is the one job it does?
Who uses it? One type of user (you, a customer, a team member). Not "everyone."
Production concern. Which of the three does it include — auth, real data, or payments?
Scope ceiling. What is explicitly out of scope for v1? Write it down.
Low risk if wrong. If the first version ships with a bug, is it annoying or catastrophic? If catastrophic, narrow the scope further.
Definition of done. Write the one sentence that means "I can hand this URL to a real person and feel good about it."

The rule of one: one user type, one job, one production concern, one definition of done. Every time a capstone fails it's because someone broke the rule of one. You can always build v2. Ship v1 first.

Check yourself

Answer before opening. Recalling it now is what makes it stick.

Your idea: "A dashboard where clients can log in, see invoices, pay online, submit support tickets, and download files." Is this a good capstone?

Too wide. That's four separate jobs (view invoices, pay, support, download). Pick one — "clients can log in and pay outstanding invoices" is a strong, shippable capstone. The others are v2 and v3.

Your app stores no user data and takes no payment — it just shows a hard-coded price list. Does it qualify as a capstone?

No — it's a prototype. Without at least one production concern (auth, live data, or payments) you're not crossing the line from demo to product. Add one real concern — even a simple login or a live data pull — and it qualifies.

Why write a scope ceiling (what's explicitly out of scope) before you start building?

To prevent scope creep during the build sprint. When a good idea surfaces mid-build — "oh, I should also add X" — you can park it on a list instead of derailing v1. The scope ceiling is a commitment device, not a limitation.