The Reveal Checklist: What Must Work Before Curtain

Before a theatre opens its doors, someone walks the building with a list. Lamps are focused, microphones are checked, the safety curtain is tested, the fire exits are confirmed clear. None of this is exciting. All of it is the reason the audience enjoys the evening without ever thinking about the building.

A product reveal needs the same quiet walk. You will never be thanked for the sign-up form that worked, but you will be remembered for the one that did not. This guide is a checklist in the theatre sense: a list that is short enough to finish, specific enough to act on and ordered so that the worst failures are found first.

Why a list beats memory

A checklist is a structured list of items to be confirmed, used to reduce errors that come from forgetting. Its value is not that the items are clever. It is that tired people under pressure forget obvious things, and a list does not tire.

Reveal day is a perfect setting for forgetting. Everyone is excited, a dozen small jobs are happening at once and the most important thing, the thing that is so basic nobody thinks to check it, is the thing that breaks. Write the list days ahead, when your head is clear, and tick it on the day.

Three kinds of testing, three moments

Software teams use several terms that map neatly onto a reveal.

• A smoke test is a quick pass through the most important functions to confirm the system works at all. The name comes from switching on new equipment and seeing whether smoke appears. Do one before every release and again an hour before the reveal.
• A technical rehearsal is the theatre's version: a run in which the production's technical elements are tested together. In your case it means the whole sequence of page, product, email and posts, run in order.
• Acceptance testing asks whether the product does what a real user needs. Hand the path to someone outside the team and watch them try.

Use all three. The smoke test catches breakage, the technical rehearsal catches clashes between parts and acceptance testing catches confusion.

The front of house: the page

The reveal page is the lobby. Check it as an arriving guest would.

• The page loads from a clean browser with no saved logins and no cached files.
• The address is the one you will publish, with the secure padlock and no warnings.
• The headline, the main image and the main button appear without the layout jumping around.
• The page reads properly on a phone, a tablet and a wide screen.
• Dark mode and light mode both look right, if your page supports both.
• Every link goes where it should, including the footer links that nobody ever tests.
• The page title, description and preview card are correct when the link is pasted into a message or a post.
• The page is readable with the keyboard alone, and images carry text descriptions.

Ask a friend to open the link on a bad connection. A page that is lovely on office wifi and unusable on a train is an unfinished page.

The box office: sign-up and access

If people can sign up, join a list or request access, the box office must work every time.

• Fill in the form with a new address and confirm that the entry arrives where you expect.
• Try a wrong address, an empty field and a very long name, to see that the messages are kind and clear.
• Confirm the thank-you message and the email that follows.
• If there is a confirmation link, click it from a phone.
• Check that a person who signs up twice is handled gracefully.
• Confirm that you can export or read the list, because a list you cannot open is no list.

If the reveal includes a login, test a brand-new account from start to finish, not only your own long-standing one, which has special data and permissions.

The till: money, if there is any

Where the reveal involves payment, take extra care and keep it safe.

• Walk the payment path as far as the payment provider's own test mode allows, and stop before a real charge.
• Confirm that prices on the page, in the cart and in the receipt agree with each other.
• Check that tax and currency are stated clearly where they apply.
• Confirm the receipt email arrives and that the product is delivered or the account upgraded.
• Know what happens when a payment fails, and that the message tells the person what to do next.

Never complete a real payment as a test on a live system unless you have decided to treat it as a genuine order. A test mode exists for this reason.

The post room: email and notifications

Email is where reveals quietly fail, because the failure is invisible to you.

• Send the confirmation and welcome emails to addresses at several providers and look in the spam folders as well as the inbox.
• Open them on a phone. Check that the buttons can be tapped and the text is readable.
• Make sure the sender name is one a person will recognise.
• Check that the unsubscribe link works and that the message states who is sending it.
• If you will send a large announcement, send it in stages rather than all at once, and watch for problems after the first batch.

The stage: the product itself

The product is the performance, and it needs the most careful look.

• Run through the first five minutes as a new user, with no special setup.
• Use the same sample data you will show in any demonstration, and make sure it loads quickly.
• Check what happens with no data, with a great deal of data and with unusual characters.
• Confirm that the main action, whatever your product's one thing is, works from start to finish.
• Check on at least two browsers and one phone.
• Confirm that error messages are written for people and that none shows a raw technical code.

If an item cannot be fixed before the reveal, decide whether to hide it, label it as coming soon or accept it with a note.

The lighting rig: speed and capacity

A product that is slow under attention loses the moment.

• Measure how long the page takes to become usable on a mid-range phone with a modest connection.
• Check the largest images and compress what is heavy.
• If a short burst of visitors is likely, ask your hosting provider how the system behaves under load and whether there is a cheap way to add capacity for the day.
• Where you can, put a cached copy of the static page in front of the product so that a rush of readers does not touch the live system.
• Prepare a waiting-list form to switch on if the product cannot cope.

You are not trying to survive a flood. You are trying to be sure that a sudden crowd of a few hundred people does not take you down.

Behind the curtain: monitoring and people

Someone must be watching while the reveal runs.

• Error reporting is switched on and sends alerts to a channel the team actually reads.
• A simple dashboard shows visits, sign-ups and errors in near real time.
• Uptime checks ping the page and the product from outside your own network.
• Each team member knows their role and the person who makes the call if something fails.
• A shared channel is open and nobody is relying on a private message to reach the person who can fix a problem.

Set thresholds in advance. For example, decide that if sign-ups fall to zero for ten minutes after the page goes live, the operator checks the form first.

Law and housekeeping

Small legal and practical items are easy to forget and awkward to fix later.

• A privacy notice is linked and describes what the form collects.
• Any claim on the page, such as a number, a comparison or a quotation, is true and you can show the source.
• Images and fonts are ones you have the right to use.
• Contact details are real and monitored.
• If the page sets cookies or tracking, the consent setting behaves as described.

The freeze

Choose a freeze time, usually a day or two before the reveal, after which only critical fixes go in. Every change after the freeze brings a risk that a working system will stop working. Write the freeze into the run of show and tell everyone. When someone proposes a tempting last-minute improvement, ask whether the reveal will fail without it. If the answer is no, put it on the list for the second week.

A worked example

A solo maker is revealing a recipe-scaling tool. Three days before, she writes a list of twenty-two items grouped by the sections above. On the first pass she finds four failures.

The sign-up form accepts an address but sends no confirmation, because her email service still has the test sender set. The page's preview card shows an old image. A button in the footer points to a draft page. On her phone, the main recipe screen needs sideways scrolling.

She fixes the four, ticks the list and then asks a neighbour to try the path without help. The neighbour cannot find the button that saves a recipe, because it is below the fold on a small screen. She moves it up. On reveal morning she runs the smoke test once more, finds everything working and publishes at the planned time. The checklist took about two hours and removed the four most embarrassing problems the day could have held.

Questions people ask

Is a checklist overkill for a small product? The smaller the team, the more a list helps, because there are fewer eyes to catch mistakes.

Who should own the list? One person, usually the operator, with each item assigned to a name. A list owned by everyone is owned by nobody.

What if I find a serious problem the night before? Decide calmly between fixing, hiding or moving the date. A short delay is a minor cost; a failed reveal is not easily repeated.

Should I keep the checklist? Yes. After the reveal, add the items you wished had been there. The next reveal starts from a better list.

Summary

Treat the reveal as a performance that must open on time. Write a checklist covering the page, the sign-up, any payment, the email, the product, speed, monitoring and the small legal items. Run a smoke test, a technical rehearsal and a test by a stranger. Freeze changes a day or two before, assign every item to a person and keep the list afterwards. The audience will see only a smooth evening, which is exactly the point of the work.