Practice 01.04 · Product quality

Ship updates without surprises

A safe release answers three questions in advance: what will be checked before rollout, who will watch the first signals, and what condition will stop distribution.

Practice outcomeA one-page release card covering affected user journeys, checks, owners, metrics, and stop conditions.

45 minutes before release

In plain language

A release is a controlled check, not just a Publish button

Even a small change can break login, analytics, or the path from a notification. Before publishing, the team agrees which journeys are affected, who watches the first hours, and which signal means continue, stop, or roll back.

What you will need

BuildThe release build for iOS and Android, plus the previous version from the store to test the update path.

TeamA release owner, a mobile developer or QA engineer, and a support contact for the observation window.

WindowAt least 60 minutes before publishing for checks and the first 2–4 hours after release for monitoring.

Terms in plain language

When to use it

Before every update — especially when registration, data storage, notifications, deep links, or a key user journey change.

In plain language

What to open before the release

Collect the links in advance. When a problem hits, the team should not be hunting for the right dashboard or person in chat history.

Change list

Take the release tasks and translate them into user journeys: login, registration, content, a transaction, notifications, profile.

If there is no change list, ask each developer to state their change and the screen it might affect in one sentence.

Stability and events

Prepare dashboards for the crash-free rate, ANR, API errors, and key events of the new app version.

Without a dashboard, assign someone to check logs, test accounts, and support requests at 30, 60, and 120 minutes.

Reaction channel

Specify in advance the chat, the decision owner, and the way to halt the rollout or quickly ship a fix.

If a technical rollback is impossible, write down a safe plan: pause campaigns, disable the feature, or notify users.

Prepare the release in five steps

Translate tasks into user journeys

Do not stop at a list of technical changes. Say what the user will see and which neighboring journey might break.

Where to do it: At the top of the release card, next to the version.
What the result looks like: Changed authorization → check login, session restore, the update from the old version, and the deep link for a signed-out user.

Check a clean install and the update

A fresh install and an update from an old version are different scenarios. Run both on iOS and Android with real test accounts.

Where to do it: In the test build and the store version.
What the result looks like: After updating from 4.2 the user stays signed in; history and settings are preserved.

Walk through the critical actions

Check login, the first useful action, the key transaction, a notification, and returning from the background. Record the fact, not “should work.”

Where to do it: In a checklist with the date, device, and the checker's name.
What the result looks like: Android 13: registration passed 10 out of 10 times; the completion event is visible in the report.

Write down the stop conditions

Before publishing, define the specific signal that stops the rollout. “If things look bad” does not help anyone decide.

Where to do it: In the last column of the release card.
What the result looks like: We stop if login conversion in the new version is more than 10% below normal or sessions start getting lost.

Assign post-release monitoring

Name the owner, the check intervals, and the reaction channel. Support must know what changed and what data to attach to requests.

Where to do it: In the chat and on the release card.
What the result looks like: Checks at 30, 60, and 120 minutes; owner — Maria; support attaches the app version and user ID.

Practical examples

Before publishing: the update from 4.2

QA updates the store version and checks the saved session and history. Losing the session or data is a pre-written stop condition, not something to argue about after launch.

After publishing: checkpoints

The release owner watches the crash-free rate, login errors, and key-action conversion at 30, 60, and 120 minutes; support attaches the app version to every new request.

The finished artifact

Release control card 4.3

One row per check. The owner, the observed fact, and the stop condition sit right next to it.

Check	Owner	Expected result	Stop condition
Update from 4.2	QA	Session and data preserved	Login or data loss
Clean registration	iOS/Android	Code and profile work	Success below 95% in tests
Key action	Product manager	Event and result visible	Conversion drop >10%
Deep link from push	CRM specialist	The right screen opens	The link lands on an error
First 2 hours	Release owner	Crash-free in the normal range	Sharp rise in crash/ANR

The release owner makes the call. On a stop signal the team halts the rollout, records the time and version, notifies support, and chooses a rollback or an urgent fix.

Release checklist

Do not tick items in advance. Every check needs a fact: device, time, result, or a dashboard link.

Changes are translated into clear user journeys. A clean install and the update path are tested on iOS and Android. Critical actions, analytics events, and deep links work. Stop conditions and a safe reaction plan are written down for the key metrics. A release owner, monitoring intervals, and a support contact are assigned.

What to watch after the release

Stability

The crash-free rate, ANR, and API errors of the new version stay within the normal range.

Key journey

Live signals

Support and reviews show no new recurring problem in the first 72 hours.

If the team does not know who stops the rollout and on which signal, the release is not ready to publish.