Skip to main content
Section 5

Launch and beyond

Go live safely, and stay healthy after.

4 lessons25-question quiz
5.1

The pre-launch check

7 min read

Every lesson before this one built toward a moment: the day real people hit your site or app for the first time. Before that day, there is one more step, and it is not optional. The pre-launch checklist is a fixed list of areas known to break in production. Walking it once before you ship is the difference between finding a gap yourself and having a stranger find it for you.

A gate, not a suggestion

Treat the checklist as a gate: pass every area or you do not ship, the same way a pull request does not merge with a failing test. "It worked in every test I happened to run" is not the same as "I checked the areas known to fail." Most launches that go wrong were not hit by something exotic. They skipped a known area because nothing forced anyone to look.

#Area
1Frontend
2APIs and backend
3Database and storage
4Auth and permissions
5Hosting and deployment
6Cloud and compute
7CI/CD and version control
8Security and row-level security
9Rate limiting
10Caching and CDN
11Load balancing and scaling
12Error tracking and logs
13Availability and recovery
The 13 areas, at a glance

That is a recap, not the full checklist. The pre-launch checklist walks all 13 areas in depth: why each one breaks, what to confirm before you ship, and a cited best practice for each. Work through it before this launch, and run it again before the next one.

Key idea
The checklist is a gate, not a formality. Pass all 13 areas before you ship, and run it again after a big feature ships or your first real customer signs up.
Key terms
Pre-launch checklist
A fixed list of areas known to break in production, checked before every launch.
More

It covers five stages: frontend and delivery, backend and data, access and security, infrastructure and scale, and operations. The full 13-area breakdown lives in its own guide.

5.2

Going live

7 min read

Passing the checklist tells you the app is ready. It does not tell you launch day will be uneventful. The launch itself is a separate, deliberate act: how you roll code out to real traffic, what you watch while it happens, and what you do the moment something looks wrong.

Roll out in stages

A "big bang" launch, all traffic to the new version at once, means a bug reaches every user at the same time. A staged rollout limits how many people a problem can reach before you notice it.

  1. 1Small sliceSend a small percentage of traffic, or one group of users, to the new version first
  2. 2WatchCompare error rates and key metrics against the old version, in real time
  3. 3ExpandWiden the percentage in steps once the numbers hold up
  4. 4Full rolloutOnly after each step looked healthy, not on a fixed schedule
A staged rollout

What to watch

  • Error rate: is it higher than the version you just replaced?
  • Response time: are requests taking longer under real load than they did in testing?
  • The specific flows that matter most: signup, checkout, login, whatever the app cannot work without.
  • Anything unusual in logs that did not show up before real traffic arrived.

Keep a rollback ready

Decide the rollback trigger before launch, not while it is happening: an error rate above some number, a broken checkout, a spike in support messages. Confirm the rollback itself is quick before you need it. Deciding whether to roll back, or how, in the middle of an incident costs time you do not have.

Key idea
Roll out in stages, watch real numbers as they arrive, and have a rollback ready before launch, not while things are already breaking.
Key terms
Staged rollout
Releasing a new version to a small slice of traffic first, then widening it once the numbers hold up.
Rollback
Reverting to the previous working version, ready to use the moment launch metrics look wrong.
5.3

Availability and recovery

7 min read

A launch that goes well does not mean the app stays healthy on its own. Things fail after launch too: a server crashes, a dependency goes down, a bad deploy slips through review. What decides whether that is a bad hour or a bad week is what you set up before it happens.

Four things to have in place

  • Health checks and uptime monitoring, live before launch, not added after the first outage. Something needs to notice the app is down before a user tells you.
  • Backups restored on a schedule, not just taken. A backup nobody has ever restored is a hope, not a plan. Restore one onto a fresh machine on a regular cadence and confirm it actually works.
  • A written runbook for the failures you can predict: what to check first, who to call, how to roll back. Improvising the steps during an outage costs time you do not have, at the worst possible moment to be figuring it out for the first time.
  • Someone actually on call, and they know it, reachable in a way that does not depend on the system that is currently down.
A status page, or any way to tell users something is wrong before they have to ask, buys you goodwill during an incident that silence never does.
Key idea
Monitoring catches the failure, a tested backup and a runbook fix it, and someone on call makes sure it gets done. Set up all four before you need any of them.
Key terms
Runbook
A written guide for common failures: what to check first, who to call, and how to roll back.
On call
A person responsible for responding when something breaks, reachable outside normal hours.
5.4

After launch: iterate and keep it healthy

7 min read

Launch day ends. The app does not stop needing attention the next morning. A site or app that just shipped is the least-tested version of itself it will ever be: the version with the smallest amount of real usage behind it.

Keep it healthy

  1. 1MeasureReal usage: what people actually do, not what you assumed they would do
  2. 2PrioritizeFix what affects the most users or the most important flow first, not whatever is loudest
  3. 3PatchKeep dependencies updated on a schedule, not only when something breaks
  4. 4Repeat1.0 is a starting point, not a finish line
After launch, on repeat

Measuring real usage means watching what people actually click, where they drop off, and which errors show up in the wild, not just the ones you happened to hit while testing. That data tells you what to fix next far better than a guess does.

Not every bug or request deserves the same attention. Fix by priority: what breaks the most for the most people, or blocks the flow the app cannot work without, goes first. A small cosmetic issue can wait.

Dependencies keep shipping their own updates and their own vulnerabilities after you launch. A dependency scan you ran once at launch is already stale a few months later. Patch on a schedule, the same way you would revisit the pre-launch checklist after a big feature ships.

Where to go from here

This closes the five sections of Shipping Web & Apps, and the last course in the Academy ladder. If any of the ideas along the way felt new, AI Foundations covers what models actually are, Prompting covers getting good output from one, Building with AI covers wiring a model into something that acts, and Running Local AI covers running one on your own hardware instead of a provider's. Building and launching is not a one-time project. Treat it as a loop: build, ship carefully, watch what happens, and keep going.

Key idea
A launch is a starting point. Measure real usage, fix by priority, patch dependencies on a schedule, and keep treating the app as a work in progress, not a finished product.

Section 5 quiz

25 questions. Pass at 75% to master this section. Retakes are unlimited, and the quiz is where the learning sticks.

Section 5 quiz · Launch and beyondQuestion 1 of 25

What should the pre-launch checklist function as, according to this lesson?

Back to Shipping Web & Apps