Every product I've launched taught me at least one check I wish I'd done earlier. This is the list: ten checks, each one learned on a real product, including Find Your Calm, LeanDeck, KpiClock and SportsOnTV. The same list is a one-page PDF at the end of this post.
The checks are in the order you'd meet them: before you build, before the switch-over, while you build, and after launch.
Before you build: agree what success means
- Agree success metrics and launch targets with the client before you build. On AidNetwork, a US healthcare staffing platform, we set them before launch. Without agreed targets, "launched" is the only measure you have. Agreeing them cost time on alignment before the build, and it gave us something to measure against after launch.
- Set usage goals at kickoff, alongside delivery goals. On SportsOnTV, success was "looks established" and "the client can run it himself", and both were met. I'd also agree measurable targets at kickoff, such as sessions, time on site and returning visitors, so the next round of work is driven by data.
- Write the business rules into one signed-off rulebook in week one. On Mark Andrews Creative, I defined the commerce and subscription logic from a one-sentence brief. One written, signed-off rulebook would have given every edge case (users per plan, download limits, course access) a single reference.
- If you take over a project, run a handover audit on day one. On AidNetwork, I took over the requirements mid-project. Starting with a structured audit of every inherited decision, open question and assumption, before changing anything, keeps anything important from being lost in the switch.
Before the switch‑over: measure, then move
- Track the old system before you replace it. On Find Your Calm, Microsoft Clarity, Mixpanel and GA4 ran on the old system from the start of the project. That's how we knew the biggest drop was in the booking flow, and fixed that first. Booking completion later rose 31% against the old system.
- Agree how the main result is measured, and over what window, before the switch-over. On Find Your Calm, booking completion only became a tracked metric after launch. Agreeing it with the client before the switch-over would have made the before-and-after comparison cleaner.
- Plan a switch-over with no gap. Find Your Calm had "zero interruption to bookings during the migration" as a success metric from the start. Every booking path was tested and all the data moved across before the switch, so bookings kept flowing. That meant moving Rooftop Saunas, with private sauna cabins across more than one London location, onto the new platform while its customers kept booking.
While you build: prove it's ready
- Build readiness checks into the plan from day one. At BYSL, a launch-readiness audit of SmartPeople, an HR and payroll platform, found 23 critical points where people got stuck, in product structure, payroll and settings. I'd build checks like payroll and tax correctness, settings and onboarding into the plan from the start, so readiness is proven step by step. To launch on time, we held a fixed 16-week plan and cut about 30% of modules, features and reports.
- If the product uses AI, build the test set on day one. On LeanDeck, I'd build a fixed set of test proposals in week one and score every prompt change against it, instead of judging AI output case by case. LeanDeck's AI returns structured sections that agencies edit and send, so its output has to be accurate and consistent every time.
After launch: watch real use
- Plan time to fix what real use shows you. On KpiClock, the client saw people start the time tracker but forget to check in, so attendance showed them absent while they were working. Starting the time tracker now marks attendance automatically. On Mark Andrews Creative, customers asked to buy single books, courses and modules, so they can now, alongside the subscription. On SportsOnTV, we improved the AI summaries on the client's feedback. All three came from watching real use after launch.
