Recovery Is the Product: Auditing Account Rescue Before Your UK Launch

Most founders treat account recovery like the fire exit: legally necessary, rarely inspected, and probably fine. Then a parent hands a tablet to a child, a mobile number gets recycled, and the fire exit turns out to open onto a brick wall.

In the UK, the shared family iPad is a brilliant stress test for that wall. It is the device on the kitchen counter, the one with three email accounts saved, a child's game still open, and a grandparent's iCloud session from Sunday lunch. If your app assumes one person, one device, one mobile number and one tidy password, recovery is where that assumption will fall over.

The shared iPad is the real stress test

Account recovery is not a back-office flow. It is a product surface. It is the screen a user sees when they are already frustrated, often on someone else's device, often with a child asking why the film has stopped. That is not a moment for a generic error message and a dead end.

For UK founders, the family device matters because it is normal. Apple and Google family sharing, hand-me-down phones, broadband bundles, and shared tablets all blur the line between one user and one account. If your recovery flow only works when the original phone is in the original owner's hand, you have designed for a tidy demo, not a real household.

Four places UK apps lose the plot

The mobile number that moved on

People change networks, move abroad for a year, or lose a phone on a night out. Mobile numbers get recycled. A recovery flow that sends a code to the number on file and offers no other route is not secure by default; it is just brittle. If the user cannot update that number before they are locked out, you have built a trap with a friendly icon.

The family device with three identities

A shared iPad may have a parent's Apple ID, a teenager's Google account, and a saved password from 2023. Autofill can be helpful or deeply confusing. Recovery needs to account for the fact that the person holding the device may not be the person who owns the account, and that signing out of the app may not sign out of the device.

The alias habit

Apple's Hide My Email, plus-addressing, work addresses that expired, and personal domains that were never renewed all make recovery email less reliable than founders assume. If your only fallback is 'we sent an email', check what happens when that email bounces or lands in a filter the user forgot they set up.

The password manager blind spot

Password managers are good. But if the only copy of the password is on the device that was lost, and the recovery route depends on that device, the user is stuck. Recovery should survive the loss of the device that usually does the recovering.

Run the locked-out test before launch

This is not a security audit. It is a usability audit with a suspicious mind. Set aside an afternoon and do it properly.

1. Write down your identity assumptions in plain English. Start with: 'We assume the user still has the mobile number on their account.' Keep going until the list feels uncomfortable. That discomfort is the point.
2. Create three test personas. One is a parent using a shared family iPad. One has a recycled mobile number. One uses an email alias and has forgotten which one. Give them realistic names and real-ish account histories.
3. Recreate the messy context. Use a tablet, not an admin dashboard. Log out, clear autofill, and try to recover the account without using your engineer brain. If you know the magic link, you are not testing.
4. Follow the 2FA handoff. Where does the code go? What if the phone is in a drawer, the number is dead, or the user is on a device that belongs to someone else? Can they change the number without being logged in? If not, note the dead end.
5. Read the copy aloud. Does it blame the user? Does it say 'invalid' and stop? Good recovery copy explains what happened and offers another route. 'That did not match. Try another way' is better than a red box and silence.
6. Time the rescue. How many minutes does it take to get back in? Count the support wait. Count the email refresh. Count the moment the user gives up and downloads a competitor.
7. Check the support script. Can an agent verify the user without asking for information they no longer have? Security theatre is not security. A support flow that only works for people with perfect records is not a support flow.
8. Log every dead end. Screenshot it. Put it in the backlog. Recovery bugs are easy to ignore because they happen to people who are already having a bad day.

What good recovery looks like

Good recovery is not one perfect route. It is a few sensible routes that respect the user's context. Offer more than one way back in: email, SMS, a trusted device, a recovery code, or a human who can help without asking for the impossible. Explain what is happening and what to try next. Let users update their recovery details before they need them, ideally with a gentle prompt after a normal login rather than a nagging banner.

On shared devices, make the handoff obvious. 'Not you? Sign out' is a small line with a big job. Clear sessions when the account changes. Do not leave a recovery code sitting in a shared inbox. And where possible, degrade gracefully: if someone cannot get back into the full account, can they still export their data, cancel a subscription, or delete the account without a support ticket?

A pre-launch checklist for UK teams

• Map every identity assumption in your recovery flow.
• Test on a shared family iPad, not just a clean simulator.
• Test with a recycled mobile number and no access to the old phone.
• Test with an email alias and a bounced recovery email.
• Test with no password manager and no saved session.
• Time the full rescue, including support response.
• Review recovery copy for blame and dead ends.
• Brief support on the routes users will actually have.
• Add a post-login prompt to update recovery details.
• Track recovery attempts, drop-off points, and support contacts.

Recovery is not glamorous. It will not make the launch video. But it is where trust gets tested, usually at the worst possible moment, usually on a device that belongs to someone else. The family iPad will find the gaps in your flow. Better you find them first.