Course B · Module B3 Capstone · Lesson 17 of 18

Build Sprint

Assemble everything into one shipped thing.

~18 min · Your capstone brief from B16 open · Prereq: B16 (Choose Your Capstone)

You have a brief. You have the building blocks from Modules B1 and B2. The only thing left is to assemble them into one working, deployed app — and not get stuck trying to do it all at once. Your single win from this lesson: a sequenced assembly checklist that takes you from blank project to "here's the URL" without losing your place, cutting corners on safety, or burning money on a bug you could have caught in test mode.

The assembly order matters

Building an app is like building a house. You pour the foundation before the walls, walls before the roof. You don't tile the bathroom until the plumbing works. The order isn't arbitrary — each layer depends on the one below. Skip the foundation, and the whole thing needs to come down later.

The foundation here is hosting and environment. Auth and data come next. Payments last — never wire up real money until every earlier layer is working and tested in test mode.

Sprint assembly checklist

Work through these steps in order. Each step has a clear "done" state — don't move forward until that state is true. Skipping ahead is how bugs get buried under layers of new code that makes them impossible to find.

Set up your project and hosting. Create a fresh repository. Connect it to your deployment platform (Vercel, Railway, Render — whatever you chose in B4). Confirm the URL is live before writing a single line of feature code. Done: blank app loads at a real URL.
Lock down your environment variables. Add all secrets (API keys, database URLs, Stripe keys) to your hosting dashboard's environment settings — never in the code. Confirm they load correctly in production. Done: app starts without hardcoded secrets.
Wire up your data layer (if your capstone uses it). Connect your database from B5. Run a simple read and a simple write. Confirm data persists between page loads. Done: create one test record, reload, see it there.
Add auth (if your capstone uses it). Use the auth provider you set up in B6. Confirm sign-up, log-in, and log-out all work on the live URL. Do not build any logged-in features until this step passes. Done: a real email address can create an account and log in.
Build the core feature. Now — and only now — build the one job your app does. Keep the AI helping, keep commits small, test after each meaningful change. If the scope starts expanding, park the new idea in a list and stay focused. Done: the single job your brief describes works end-to-end.
Add payments in Stripe test mode (if your capstone uses them). Use your Stripe test keys from B8. Walk through a full payment flow using Stripe's test card numbers. Confirm the webhook fires and your app responds correctly. Done: a test payment completes without errors.
Send a transactional email (if your capstone uses them). Connect your email provider from B7. Trigger a real send — welcome email, receipt, confirmation — and verify it lands in an inbox (check spam too). Done: you receive the automated email yourself.
Human-in-the-loop review. Walk through the full user journey yourself, from landing to completion, on the live URL. Then ask one other person to do the same while you watch. Write down everything that confuses or breaks them — fix the top three before going further. Done: someone else completes the core flow without your help.
Switch to live mode (payments only). Only after steps 1–8 pass: swap Stripe test keys for live keys. Make one real transaction (even £0.50 to yourself) to confirm the full live flow works. Done: a real card completes a real payment.

Always test in test mode before taking real money. Stripe's test card numbers let you simulate every payment scenario — successes, declines, webhooks firing, refunds — without a single real charge. There is no excuse for skipping this step. A bug in your payment flow discovered in test mode takes 20 minutes to fix. The same bug discovered by a real customer takes your evening, damages trust, and may require a refund.

When the AI is helping vs when it's the right call to stop and think

Use your AI for generating boilerplate, wiring up integrations, debugging error messages, and writing the repetitive parts fast. Keep yourself in the loop for:

Always own these yourself:

Any step that touches real customer data. Read what the code does before you run it — ask the AI to translate it if needed.
The moment before you switch to live Stripe keys. Pause. Confirm every test scenario passed. Then flip the switch.
Auth rules. Confirm which pages require login, which don't, and that you can't reach a protected page by typing the URL directly.
Error handling. What does the user see if a payment fails? If the database is unreachable? A good error message is the difference between "something broke" and "something broke and the customer emailed you about it."

Check yourself

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

You want to add a new feature mid-sprint that would be genuinely useful. What should you do?

Write it down and park it for v2. Mid-sprint scope expansion is the main reason capstones don't ship. If the new idea is genuinely good it will still be good next week — after v1 is live. Add it to a list, close the tab, keep building.

Your payment flow works perfectly in test mode. Can you switch to live Stripe keys now?

Only after completing the full human-in-the-loop review (step 8). Test mode passing is necessary but not sufficient. A real person should have completed the core flow on the live URL without your help first. Then you flip to live keys.

A friend says "just hardcode the API key in the app for now, you can move it later." What do you say?

No — environment variables are non-negotiable. "Later" almost never comes. A hardcoded key in a public repository can be found and abused in minutes. The five minutes it takes to use an environment variable is always worth it.