Launching an app is the start of its working life, not the end of the project. Software depends on other software, services and accounts that change over time. Someone has to look after it, and it is far better to decide who before launch than to find out when something stops working.
What upkeep involves
- Monitoring. Knowing when the app is down or failing, ideally before customers tell you.
- Updates. The libraries and services an app uses release fixes, including security fixes. They need to be applied and checked.
- Backups and restore tests. Having backups is not enough. Someone should try restoring one now and then.
- Access. Who can log in to the hosting, the database and the code, and who removes access when someone leaves.
- Support. Who users contact when they cannot log in or something looks wrong.
- Incident handling. What happens when the app goes down or data is exposed: who is told, who decides and who fixes.
- Renewals and costs. Domain, hosting and other service fees, and who pays and watches them.
- Improvement. Collecting feedback and deciding what to change next.
A responsibility checklist for owner and developer
Use this as a conversation guide. For each row, agree who does it and write it down.
| Task | Usually the owner | Usually the developer or maintainer |
|---|---|---|
| Pay for domain, hosting and services | Holds the accounts and pays the bills | Advises on what is needed |
| Apply updates and security fixes | Agrees the schedule and any cost | Does the work and tests it |
| Run and test backups | Confirms it happens | Sets it up and tests a restore |
| Monitor for failures | Decides who gets alerts | Sets up monitoring and responds |
| Help users | First point of contact for staff and customers | Fixes problems the owner passes on |
| Manage who has access | Approves who needs it | Adds and removes it |
| Decide what to improve next | Sets priorities | Estimates and builds |
| Respond to an incident | Decides on notifying customers | Investigates and fixes |
Agreeing the details
Every maintenance arrangement should answer these questions plainly. They are the owner's questions, not a package any provider has to offer.
- What is included, and what costs extra?
- How do you report a problem, and what response can you expect? Ask for it in writing rather than assuming.
- What happens if the developer is unavailable? Can someone else take over from the documentation?
- Where are the accounts, and who has the passwords?
- How are changes tested before they go live?
- How often will backups be restored as a test?
Be wary of any promise of guaranteed uptime or response times unless it is written into an agreement that you have read. Likewise, be wary of a developer who cannot explain how they would look after the app.
Set it up before launch
- Make a list of every account the app depends on and record who controls each.
- Put renewal dates in a calendar.
- Choose one person on your side who owns the app's day-to-day decisions.
- Keep a short list of problems users report, so you can see patterns.
- Ask for the documentation of how the app is set up, and keep a copy.
When you would rather not carry it yourself
Ask for ongoing help when real customer data is involved, when the app is important to daily work, or when you do not want to carry the responsibility yourself. A maintainer can also check infrastructure, costs and recovery plans. See the cloud and cost clarity service for how the supporting systems fit in. Before launch, the readiness checklist shows what to verify first. The ownership checklist covers accounts and access. When you budget, what affects cost explains why upkeep belongs in the total.