LESSON 10 / 14 · FREE BUSINESS COURSE
A launch is a promise that someone can begin using your service and get help when they need it. Before inviting buyers, check the whole journey against that promise. A small, deliberate launch gives you room to learn.
By the end: produce a launch decision, a tested customer journey, and a short plan for responding when something fails. You can complete the planning exercise without an account or paid tools.
Define what ready means
A launch date is useful only when you know what must work by then. Write down the smallest offer you can deliver reliably: who it serves, which task it helps them complete, what is included, what it costs, and how support works. Keep unfinished extras out of the advertised promise.
For a reporting service, readiness might mean receiving a sample data file, producing a correct report, delivering it to the right person, and handling corrections. For FitSite, it includes creating a studio website from the selected template and making its contact and booking routes usable. Neither example requires every possible feature.
Separate blockers from improvements. A buyer receiving the wrong plan is a blocker. A decorative animation can usually wait. Give each blocker an owner and a retest step so a launch meeting produces a decision instead of a list of vague concerns.
Test the service underneath the offer
Confirm that the application and customer-facing pages are reachable over HTTPS, that intended domains work, and that monitoring reaches someone who can act. If you offer mapped domains, test that exact route. A wildcard certificate for your own subdomains does not automatically cover a customer’s separate domain.
Back up both data and the files required to restore the service. Restore a representative backup into a safe test environment and check the result. A successful backup notification alone does not prove that recovery works. Record who can restore it and what information might be lost between backups.
For the optional WordPress track, use a staging environment to check WordPress Multisite, Ultimate Multisite, your templates and selected integrations together. Ultimate Multisite core is free; hosting, domains, email delivery, payment processing and optional services can still cost money. Confirm the actual operating budget before taking subscriptions.
Walk through every advertised plan
Start as a new visitor rather than an administrator. Follow the marketing page to signup, select a plan, review the total, complete the provider’s supported payment tests, open the welcome email, log in, and finish the first useful task. Repeat for materially different plans and billing periods.
Check failed and interrupted journeys too. What happens after a declined payment, a mistyped email, an expired trial, or a browser refresh during setup? A reassuring success screen is not enough if the account never receives the promised access. Record the expected account, payment and provisioning state at each step.
Use the payment provider’s sandbox or test mode and its documented test details. Stripe explicitly says not to test in live mode with real payment details. Do not follow the old shortcut of charging yourself and refunding it. Review the provider’s current go-live checklist separately before accepting genuine customer purchases.
Review the visible experience
Check templates on small screens and with keyboard navigation. Replace misleading placeholders, verify image permissions, follow links, test forms, and ensure instructions describe the screens a customer actually sees. A working login is not the same as a usable first session.
Confirm that plan limits, trial conditions, renewal prices and setup charges match the offer. Check the account page, cancellation route, invoice details and support contact. State what happens to access and data when a subscription ends. Have the appropriate business policies reviewed for your circumstances rather than copying another company’s promises.
For FitSite, a launch rehearsal could use a fictional studio with a timetable, trainer profile and contact form. Label it as a demonstration. Do not place real customer information in public sample sites or imply that a stock-photo subject endorses the platform.
Invite a small pilot group
Choose a pilot group you can personally support. Ask participants to attempt real tasks and describe what happened, rather than merely asking whether they like the design. Observe where they stop, which instructions they miss, and whether they reach the outcome the offer promised.
If you offer a pilot discount, give it a defined scope and duration you can afford. A permanent half-price offer creates a long-term obligation before you understand costs. Ask separately for permission to feature a customer’s site or quote feedback; pilot participation does not supply that permission automatically.
Imagine three invited studio owners trying FitSite. Two finish setup, while one cannot connect a booking link. This is an illustrative scenario, not a reported result. The useful response is to investigate that failed task, improve the instructions or integration, and repeat the journey before inviting more people.
Give launch day an owner and a fallback
Set aside time when someone can monitor signups, payment notifications, provisioning and support. Keep contact details for essential providers available. Decide what would pause new signups, who makes that decision, and how affected customers receive a clear update.
For example, repeated provisioning failures might trigger a temporary pause in invitations while existing customer access remains available. Avoid collecting more payments for an outcome you cannot deliver. Record the problem, affected accounts, next update time and recovery checks without guessing at a resolution time.
After launch, review evidence rather than celebrating the visitor count alone. Did eligible buyers complete signup? Did they reach the first useful outcome? Which failures needed manual help? These observations become the next small improvement cycle.
Your exercise: run a launch rehearsal
Write a one-page readiness sheet with five rows: offer, payment journey, first useful task, support, and recovery. For each row record the test, the observed result, the owner and any unresolved blocker.
Choose one ordinary customer journey and one failure journey. Run both in a safe test environment. Save the evidence you need to reproduce a failure, without copying passwords or payment details into notes.
Write your pilot invitation, the feedback questions and your go/no-go rule. A useful rule might require every advertised plan to provision correctly and a successful recovery rehearsal. Select a pilot size based on your actual support capacity.
Finish with a decision: ready for a limited pilot, blocked pending specific fixes, or ready for wider invitations after a completed pilot. Record the date you will review it again.
Before you move on
Readiness means a tested promise, not a full feature list. A pilot provides learning without guaranteeing sales. Keep payment testing within the provider’s supported environment, and know how to pause, communicate and recover when a critical journey fails.
Sources and further reading
Adapted from the original Lesson 10: Launch Day. FitSite is an illustrative business used for learning, not a customer success story. Stripe testing guidance explains sandbox payment tests. WordPress backup guidance covers the data and files needed for recovery.