A Pre-Launch Check Ends on Someone Else's Device

One Person Has Used This End to End

The launch date is close. Features are in, the design has been signed off, the build is sitting on the server. It looks like the only thing left is to open it. Except that the only person who has ever moved through this product from the first screen to the last is the person who made it.

Builders travel their own road. The values typed into the signup form are the values they always type. The route to the checkout screen is the route they wired. That path has been walked dozens of times, so of course it holds. First-time users do not arrive that way. They land on a detail page from a search result, abandon signup halfway and come back an hour later, and hit the browser back button in the middle of payment.

Which makes a pre-launch check less about how many boxes got ticked and more about who has travelled which route. Walking one path that was never on the list tends to turn up more than extending the list.

Walk the Whole Line Without Stopping

Check screens one at a time and you end up with a product where every screen is fine and the service is not. What a user actually does is not a screen, it is one continuous line from arriving to getting what they came for. Walk that line without breaking it: sign up, receive the verification mail, log in, add the item, pay, then go find the record of what just happened.

The breakages cluster after failure, not after success. A declined card. A verification mail that never shows up. Back button pressed mid payment. The same button tapped twice in a row. The happy path was rehearsed dozens of times during the build, while the failure path often ships having never been walked once. Duplicate orders, or a payment with no order attached to it, come from exactly here.

Make a fresh account too. The account used during development already carries permissions and data, so nobody on the team has seen an empty state. What someone who signed up this morning is looking at is only visible from a new account.

Anything You Send Has to Actually Land

A confirmation message on screen and a mail sitting in someone’s inbox are two different facts. Contact forms, signup verification, password resets, order confirmations, notifications. None of it is confirmed until it has been sent to a real address and opened there.

Teams usually validate this during the build with a mail catcher, and a mail catcher never puts anything on the wire. The moment it switches to real delivery, sender authentication becomes the gate. Major mailbox providers have spent the past few years converging on SPF, DKIM and DMARC records for the sending domain, and mail without them lands in spam or gets refused outright. Those records live with whoever controls DNS rather than with whoever writes code, which is why they are so often discovered after launch instead of before it.

Check the receiving end once as well. If the mail your contact form generates is quietly filling up a spam folder, the form works perfectly and the enquiries simply never arrive.

A New Phone, a Slow Connection, a Logged Out Window

The machine the product was built on is current, wide, fast, and already signed in. Break all four of those conditions once. Open it on a phone that is a few years old, come in from the home page in a private window with no session, and watch the order things appear in when the connection is slow. Image heavy sites reveal their real behaviour under exactly these conditions and nowhere else.

Visibility settings belong in the same pass. Staging is normally blocked from search engines, and when that block ships to production the site opens perfectly for humans and never appears in results. The mirror image also happens: the staging URL stays reachable and the same content is live in two places. Neither is visible on screen, and both come back weeks later as a question about why nothing is being indexed.

Can You Put It Back

No amount of checking removes everything, so the last question is not what was verified but whether there is somewhere to retreat to. Does anyone know how to return to the previous version, does that take minutes rather than an afternoon, and if the change touched the database, how old is the backup.

Flag the parts that do not reverse. Screens and code roll back cleanly. Migrated or deleted user records, mail already delivered, payments already captured do not. Keeping those off the launch day itself is part of the check.

The hour you open is a decision too. Ship on a Friday evening and there is nobody left to watch it. Error alerting goes on before launch rather than after, because the difference on day one is whether you hear about a failure from your own tooling or from a customer on the phone.

”It Doesn’t Work” Is Not a Test Result

When the report arrives as one line saying payment is broken, the person fixing it has to reconstruct everything from scratch. What was tapped and in what order, which device and which browser, which account and at what time, what appeared on screen. With those four attached, the cause usually narrows on the spot. Without them, reproducing it eats a day. A screen recording is the fastest version of all four.

If the person checking and the person fixing are different people, agree on this format in advance. The last days before launch are when findings pile up, and unstructured reports turn repair time into reading time.

We Take the Stranger’s Seat

Weple’s pre-launch QA is walking the routes the build team never had reason to walk. We turn the flows that must not break into automated tests a real browser executes, run them again across browser and screen size combinations, and deliberately introduce the conditions that surface in real use: empty values, very long input, slow networks, double clicks, the back button. No repository access is needed, a reachable URL and a test account are enough. What we take on and how the work is priced is written up on the pricing page. Calling us in before development finishes is fine and usually better, since it leaves room to fix what turns up. Findings come back with reproduction steps, a screen recording and a severity attached, so you can hand them to whoever is fixing things without rewriting a line.