A web app isn't finished when the code is done. The moment that causes the most trouble is when the app goes onto the server, and every update after that: a page that worked a minute ago suddenly breaks, data goes missing, or a change you were told about never shows up. A safe release isn't down to luck. It comes from a handful of simple habits repeated every time.
This article covers six checks before and after releasing a web app, with the question to put to your developer or vendor and a way to check each one yourself. You don't need a technical background to use it.
At a glance: six release checks
| Check | Question it should answer | Quick check |
|---|---|---|
| Back up before overwriting | Is there a copy of what is running now, data included? | Ask to be shown the copy made before the release |
| Test somewhere separate | Was the change tried before it touched the app people are using? | Ask where, and by whom, the release was tested |
| Match before overwriting | Is what is about to be replaced really the version everyone expects? | Ask for evidence the version was checked before anything was overwritten |
| Verify after release | Does the change actually appear and work? | Open the changed feature and run its main flow yourself |
| A rollback plan | How do you get back to the previous version, and how fast? | Ask for the steps in writing, including who carries them out |
| Monitoring after release | Who watches for errors in the first 24 hours? | Ask where error records are kept and who reads them |
1. Back up before overwriting anything
A useful backup covers two things: the application files (code, templates, configuration) and the data (the database and anything users have uploaded). A backup that covers only one of them often can't restore a broken app.
How to check: ask to see the copy made before the latest release, not just a promise that backups happen "automatically". Also ask how much recent data could be lost if the backup were restored.
On Codwa's own site, we copy every file we are about to replace with a .bak suffix first, and before changing the content of many articles at once we save the old content to a JSON file. That rule applies to the smallest change as well as to big releases. For general security basics, see why a secure digital foundation matters for your business website.
2. Test somewhere separate first
A change tried directly on the live app turns your users into testers. At a minimum, a change should be tried first on a separate copy, whether on the developer's own computer or in a dedicated test environment.
How to check: ask where the release was tried, who tried it, and whether any automated tests were run. Automated tests don't replace a manual check, but they catch breakage that is easy to miss, especially in parts of the app that weren't supposed to change.
We run a suite of automated tests on a local computer before a release. If anything fails, the release stops until the cause is clear.
3. Match the live version before overwriting
One of the most underrated sources of breakage is overwriting files or folders without confirming that what's there is what everyone thinks is there. A server can differ from the record, because of an emergency fix made directly on it or simply because the wrong folder was targeted.
How to check: ask how the vendor confirms the running version matches the expected one before overwriting it. A good answer names something concrete, such as comparing file contents or their fingerprints, not "it should be the same".
We have twice uploaded to the wrong folder and once overwritten a file without checking its contents first. After that we wrote a release procedure: check on the server that the content is what we expect, keep a copy, only then write, and stop if anything doesn't match. The same standard appears in the Release Engineering chapter of Google's SRE Book: releases should be repeatable, and changes to the release process should be intentional rather than accidental.
4. Verify after the release
A release isn't finished when the files are uploaded. It is finished when the change is proven to appear and work in the app people are using.
How to check: once you are told the release is done, open the changed feature yourself and run its main flow, for example logging in, submitting a form or making a test transaction. If the change affects layout, look at it on a phone too.
After writing a file, we read it back from the server and compare it with the intended version, then open the changed page and check its status code and the part that changed. One trap we have met in production: the app caches its configuration and routes, so a change that has been saved may not take effect until the cache is rebuilt. Without verification, that looks exactly like a successful release.
5. A complete rollback plan
A rollback means returning the app to its previous version when a release goes wrong. The plan has to exist before the release, not be worked out once something is already broken.
What's often missed: a rollback has to restore every component of the release together. Restoring only part of it can be more dangerous than restoring nothing.
| Release component | What has to go back with it |
|---|---|
| Code and templates | The previous version of the application files |
| Styling and scripts | Stylesheets and JavaScript that match those templates, including the manifest that points to both |
| Configuration | Environment settings and caches that agree with the code |
| Data and database structure | A copy of the data from before the release; database changes can't always simply be undone |
When we rolled back one release on our own site, only part of it went back: the templates and scripts reverted but the stylesheet didn't, so the look of several pages no longer matched their content and they stayed broken until we fixed them one by one. The lesson: check the full list of release components before reverting anything.
6. Monitoring after the release
Many problems only appear hours after a release: on rarely visited pages, in scheduled tasks, or on particular devices. That means someone has to be responsible for looking.
How to check: ask where error records are stored, who reads them, and whether an automatic check alerts anyone when an important page becomes unreachable. An app with no monitoring only turns out to be broken when a user reports it.
We check the error records after a release and run a regular site health check. For an app that handles data or transactions, watch more closely on the first day.
How strict? Match the type of change
Not every release needs the same heavy procedure. The bigger the effect on data and users, the more complete the process should be:
| Type of change | A reasonable minimum |
|---|---|
| A small text or visual change | Back up the files being replaced, then check the changed page after the release |
| A new feature or a changed workflow | Add testing somewhere separate, a written rollback plan, and monitoring for the first 24 hours |
| A change to the database, login or payments | Add a full data backup, testing on a copy of the data, a quiet-hours slot, and a rollback that has actually been rehearsed |
Where to start if your app doesn't have this yet
The right approach depends on your situation. There are usually three:
| Where you are now | A sensible next step |
|---|---|
| The app is running, but there is no backup anyone can show you | Make a backup of the files and data now, then test that it can be restored |
| Your developer or vendor releases without a clear process | Ask for the six answers in the table above and agree a written release procedure |
| The app hasn't been built yet | Put backup, testing, rollback and monitoring into the scope of work from the start |
If you are still weighing whether your business needs a web app or an internal dashboard, read when does your business need a custom web app or internal dashboard. Maintenance and updates after launch are among the factors covered in the cost of building a web app, and for a lighter first version, see how to build an MVP for a startup web app.
Frequently asked questions
Does a small app need a separate test server?
Not always. For a small app, a copy on the developer's computer run with automated tests is far better than changing the app people are using. The more important the data, the more you need a test environment that resembles the real thing.
How often should backups be made?
It depends on how often the data changes. Ask yourself: how much recent data can you afford to lose if something breaks? If the answer is "almost none", backups need to be more frequent, and you should check that the data can actually be restored.
Next step
Pick one app you rely on and put three questions to the team that looks after it: where is the latest backup, how would they return to the previous version, and who watches for errors after a release? The answers usually show which area needs attention first.
Talk to Codwa Studio about building and maintaining your business web app
Reviewed by Hammam Adi Praksasa Putra. Published: October 6, 2026.
