How to Ship Your First Production Web App

A local application proves that the happy path can work on one machine. Production requires a stronger claim: real users can use it safely, failures are observable, data survives change, and the team can recover from a bad release.

Define the production contract

List the critical user journeys and their acceptance criteria. Include authentication, authorization, validation, error states, empty states, and mobile behavior. Decide what data is sensitive, how long it is retained, and who can access it. These are architecture inputs, not polish tasks.

Create separate development, test, and production configuration. Validate required environment variables at startup. Keep secrets out of source control and expose only variables that the browser genuinely needs.

Make data changes deliberate

Use versioned migrations. Test a fresh database and an upgrade from the current production shape. Back up before destructive changes and decide how the old and new application versions coexist during rollout. A deployment that updates code and schema without compatibility planning can fail even when both are individually correct.

Seed only safe reference data. Never depend on a developer's local rows or manually edited production state.

Build a release gate

The pipeline should install from a lockfile, generate clients, run formatting checks, lint, typecheck, unit and integration tests, build the production bundle, scan dependencies and secrets, and publish one immutable artifact. Deploy that exact artifact. Rebuilding on the server creates a revision you did not test.

Run browser tests against the core journeys in an environment that resembles production. Accessibility and responsive checks belong in the gate because layout and keyboard failures are user-visible regressions.

Observe the application

Add structured logs, error reporting, health checks, and basic service metrics. Include a release identifier so every incident can be tied to the deployed revision. Define alerts around user impact: sustained errors, unavailable dependencies, queue backlog, or latency, not raw log volume.

After deployment, run a smoke test through the real domain, authentication layer, API, database, and background jobs. Configuration presence is not runtime proof.

Prepare rollback and ownership

Write the rollback action before release. Confirm the previous artifact still exists and schema changes are compatible with rollback. Assign an owner for the release window and record where alerts, logs, and runbooks live.

Use a staged rollout when risk is high. Watch evidence, not optimism, and stop or roll back when the acceptance threshold is breached.

You can move on when a second engineer can deploy the tested artifact, verify the live data path, find the release in observability, and restore the previous version from the runbook.