← Week 06: Ignite: launch, learn and decide
SESSION 01 · TUESDAY
Launch: from a working build to real people using it
A launch is a promise to real people. Tonight you make it safe, measurable and supported, then put it in their hands.
Launch readinessStaging & productionFirst-value funnelFirst usersMCP
Present slides ▶
Full screen, one slide at a time · 12 slides
By the end of tonight you can…
- Explain how a launch differs from a demo, and check readiness in five areas
- Use local, staging and production environments, and deploy with Claude Code’s help
- Define five events that trace your first-value funnel, collected with consent
- Plan a first-users programme: recruit, onboard, observe, support and ask
- Connect Claude Code to a browser tool with MCP and walk through your live flow
OUTPUT · Launch checklist + live URL + event plan + first-users list
A demo shows it can work. A launch means it works without you.
A demo
- You drive, and you know which buttons to avoid
- Runs on your laptop with made-up data
- If it breaks, you restart it and carry on talking
- Success means the audience was impressed
A launch
- Strangers drive, at times you don’t choose
- Runs on a server with real people’s details
- If it breaks, you find out, fix it and tell people
- Success means someone reached the first value moment
Launch small and on purpose: a few named people, one working slice, and a way to learn what happened.
Launch readiness: five questions before real people arrive
- WORKSThe first slice runs end to end on the live site, on a phone, for someone new
- SAFESecrets are out of the code, logins are required, users see only their own data
- PRIVATEYou collect only what you need, say why in a privacy notice, and can delete it
- OBSERVABLEYou will know when it breaks and what people did: error alerts plus five events
- SUPPORTEDUsers know how to reach you, and you know how to roll back a bad release
Each answer needs evidence you can show, not a feeling. Anything unproven goes on the checklist as a task.
Three places your product lives: local, staging, production
- LOCALYour laptop. Fast to change, safe to break, test data only. Only you can see it.
- STAGINGA private online copy, set up like the real thing, with test data. Rehearse here.
- PRODUCTIONThe live site real people use, with real data. Only tested, reviewed code goes here.
Code moves one way: local → staging → production. Each place has its own settings and secrets.
Plan the deploy with Claude Code, then run it together
I’m launching [MY PRODUCT] to about ten first users next week. It runs locally and its tests pass. I want to put it on [HOST I’VE CHOSEN], first as a private staging site, then production, so that real people can complete the first slice. Read CLAUDE.md and the repository, then propose a step-by-step plan: what the host needs, which settings and secrets each environment needs (names only; I’ll enter the values myself), how we check staging works, and how we roll back. Show each step as one line with the command or screen involved. If you’re unsure how the host does something, say so and point me to the part of its documentation to check. Done means a staging URL where I complete the slice on my phone, and a rollback step written in CLAUDE.md.
Check the response
- Every secret appears by name only, never with its value
- Staging is deployed and checked before production
- The plan has a rollback step you can explain
Measure the first-value funnel, with consent
- EVENTSA few named moments that matter, named for what the user achieved: booking_confirmed
- PROPERTIESSmall facts attached to each event: time, tutor ID, device. Never names or messages.
- FUNNELThe events in order. Count how many people reach each step and where they stop.
- CONSENTSay plainly what you record and why; ask before any non-essential tracking.
Five well-chosen events beat a dashboard of hundreds. Each one answers a question you will act on.
TutorDesk’s five events
Starting point
“Let’s track every click and page view. We’ll work out what matters later.”
Reframed
Five events trace one booking: enquiry_started → slot_requested → booking_confirmed → reminder_sent → repeat_booking. Each carries tutor ID and time, no names.
Ask
- Which event is TutorDesk’s first value moment, and why?
- What might a drop from slot_requested to booking_confirmed mean?
- Which property would let you compare tutors by number of learners?
- What would you deliberately not record?
A first-users programme: few people, close attention
- RECRUIT5–10 named people from your evidence log who have the problem now
- ONBOARDSet each one up yourself, on a call or in person, until they reach first value
- OBSERVECheck the events daily and sit beside one or two people as they use it
- SUPPORTReply the same day, fix blockers first, and tell people what changed
- ASKAfter a week: what did you use it for, what nearly stopped you, would you miss it?
At this stage you learn from people, not percentages. Do things that don’t scale, and write them down.
Connect Claude to a browser and walk your live flow
I’ve connected a browser tool with MCP so you can open and use web pages. My staging site is [STAGING URL]. I want to check the first slice works for a newcomer before I invite real users, because I can no longer see it with fresh eyes. Using the test accounts in [TEST ACCOUNTS FILE], walk it as a learner: open the booking link and request a slot. Then sign in as the tutor and confirm it. Stay on staging, since production holds real people’s data. Report each step as a numbered line: what you did, what you saw, and anything slow, confusing or broken. If you can’t tell whether a step worked, say so rather than guess. Done means a short table of steps, the problems listed by severity, and the one fix you would make first.
Check the response
- Claude reports what it actually saw, step by step
- Each problem points to a specific step and screen
- Nothing was done on the production site
Launch your first slice to your first users
Get your product live and safe, so that real people can reach your first value moment before Thursday.
- Write the launch checklist: five readiness areas, each with evidence or a task (15 min)
- Deploy to staging with Claude Code, test the slice on a phone, then go live (25 min)
- Write the event plan: five events, properties, consent wording and a launch threshold (12 min)
- List 5–10 first users by name, how you will reach each, and the date you will ask (10 min)
Deliverable
Checklist, live URL, event plan, first users: product/06-launch.md
Launch rubric
- The live URL completes the first slice on a peer’s phone without the learner’s help
- The checklist covers works, safe, private, observable and supported, each with evidence
- Staging and production are separate, and no secret appears in the code or repository
- Event plan: five events with properties, no personal data, consent wording, a threshold
- The first-users list names 5–10 real people, how each is reached and an invitation date
- Users can see how to get help, and a rollback step is written down
HOMEWORK · Invite your first users, onboard at least three, and bring event counts and quotes on Thursday.
© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms