Direct answer
Launch day should hold no first-time decisions. By the time you switch a web application on, every choice that can be made in advance should already be made and written down: who decides to proceed, who does each step, how you will know it worked and what you will do if it did not. The checklist below is the list of things to have settled, not a schedule for the day itself.
It is written for custom web applications. If you are launching a warehouse system, use the WMS go-live checklist instead. The checklist does not promise that a launch will be free of interruption: whether a switch can happen without any visible gap depends on how the application and its hosting are built, and it should be discussed and agreed, not assumed.
Readiness gate
A readiness gate is a short meeting or written check where the named decision-maker confirms the launch can go ahead. Without one, launch tends to happen because the date arrived.
- Acceptance testing is complete and any open defects are listed with a decision on each
- The person who can say go or no-go is named, with a backup
- A launch time is chosen with the team's availability in mind, not just the builder's
- A rollback plan exists, and the trigger for using it is agreed in advance
- Users who need to know have been told what is changing and when
Data and configuration
Production is not a copy of the test environment. Check that the settings that differ between them are correct in production: connections to the live database, live payment or email providers rather than test ones, real addresses for outgoing messages, and any feature switches.
If existing data is being loaded, decide who reconciles it and how. Compare record counts and a sample of real records against the source before users arrive. If the application starts empty, confirm the initial reference data, roles and administrator accounts are in place. Remove test data and test accounts that should not be seen. Confirm the configuration list is written down, so the state of production can be reviewed later without guessing.
Domain, DNS and certificates
Domain changes are the part of a launch most likely to surprise a team, because they are slow to take effect and awkward to reverse. Confirm who controls the domain and DNS, and that you can log in. Prepare the DNS changes in advance and know what each one will do.
Confirm the secure certificate will be issued and renewed automatically, or note the renewal date and owner if it will not. Test the address people will actually type, with and without the leading www, and check that old links or an old site redirect where you expect.
Access and accounts
Before launch, confirm that the accounts the application depends on are in your name and that you can log in to each one: hosting, domain registrar, email sending, file storage, error tracking and any third-party services. Check that two-factor sign-in is on for administrators and that recovery methods belong to your business.
Confirm user accounts are created or invited as planned, and that the people who need administrator rights have them and nobody else does. Credentials used during the build should be rotated or removed. The software handover checklist covers the ownership side in more depth.
Monitoring and backups
Do not launch something you cannot see. Decide before launch how you will find out that something is wrong: error reports, application logs, a check that the site responds, and a route for messages from users. Someone must be assigned to look at them, and it must be clear who that is.
Confirm backups are running and that at least one restore has been tested. A backup that has never been restored is unproven. Note where the backups are, who can reach them and how a restore is requested.
Production smoke test
Once the application is live, run a short smoke test in production itself, using a prepared list. It is not full acceptance testing; it is a check that the most important paths work in the real environment.
- Sign in as an ordinary user and as an administrator
- Complete the two or three most important actions end to end
- Confirm a form submission, a notification or an email arrives where expected
- Check that files upload and download
- Confirm any payment or integration step works with the live provider, using the smallest safe test the provider allows
- Check that errors are being captured by your error tracking
Communication and support
Tell users what is changing, where to get help and what to do if something does not work. Decide who answers questions in the first days, where questions are collected and how fixes are prioritised. A short list of known limitations, shared honestly, prevents a stream of duplicate reports.
If the builder will be available after launch, agree in writing how they can be reached and what is and is not covered; do not assume on-call cover exists. See software maintenance after launch for the options.
The first-day watch
For the first day or so after launch, have someone deliberately watching: reading the error reports, testing paths, answering users and keeping a running list of issues. Decide in advance what counts as serious enough to trigger the rollback or a rapid fix, and who can authorise it.
After the first period, review the list, close what is fixed and hand the rest into normal maintenance. Then update the runbooks with anything learned. The release and rollback process describes how later changes should go out.
Where LATYNEX fits
LATYNEX builds custom web applications remotely, in English, and agrees one scope and one price in writing before work starts. Launch preparation can be listed in that scope so it is planned, not improvised. To discuss a project, start at web application development.
Questions
How early should launch preparation start?+
As soon as scope is agreed. Domain access, accounts and production configuration often depend on people outside the project team and take longer than the code.
Is a soft launch a good idea?+
Often, yes: a small group of real users first reduces risk, and you can fix issues before everyone arrives. It needs the same checklist, just applied to a smaller audience.
Can launch happen with no downtime?+
That depends on how the application, database changes and hosting are set up. Ask the builder specifically, and plan for a short interruption unless they can show otherwise for your case.
Who should own the go/no-go decision?+
A named person on the buyer side with authority over the business outcome. The builder advises on technical readiness, but should not be the one deciding.
What if we find a problem after launch?+
Use the pre-agreed rollback trigger to decide whether to revert or fix forward, and record the issue. Having decided this before launch is what saves time under pressure.