Software does not wear out like a machine. The code on day ninety is the code from day one. What changes is everything around it: certificates expire, card providers update their rules, a free plan hits its limit, and more people use it than you ever tested with.
So the question is not whether something will need attention after launch. It is who will notice, and how quickly.
Four things to have before you go live
None of these is expensive. They are mostly decisions, written down once.
- Alerts that reach a person: a check that runs all the time and tells a named person, not a shared inbox, when something is wrong.
- Backups you have restored at least once: a backup you have never restored is a hope, not a backup.
- A runbook: one page on what the system is, where it lives, who to call, and how to restart and restore it.
- Everything in your name: the domain, the hosting, the payment accounts, with at least two people able to sign in.
Worth remembering
A backup you have never restored is a hope, not a backup.
Decide who does what
The team that built a system and the team that runs it often drift apart. Agree the split before launch, in writing, so nobody assumes the other side is watching.
Questions to ask before launch
Can you answer these today?
- If the site went down tonight, who would know first?
- When did we last restore a backup?
- Where is the one page that explains how this runs?
- Whose name is on the domain and the hosting?
- What does the next improvement cost, and who decides?
How this shows up in practice
We engineered Fox TAS and AnswerBug for EVS7, and we have run them from first release onwards. Every question above came from running real systems for real people. Ask any partner the same questions before you rely on a system under load.