It can break even if nobody touches your code. Here's where that usually shows up.
The things around it change
Your app leans on other people's services: the one that sends email, the one that takes cards, the one that shows a map. They change their rules, retire old versions, tighten limits and raise prices. The first you hear of it can be a customer saying the receipt never came.
Real use is heavier than your testing
You built it on five records and one person. Now it has years of customers, three people on it at once, and someone pasting a phone number into the wrong box. Pages that were fast get slow. Screens that made sense get crowded. Odd cases you never thought about turn up.
Something stops without a sound
The worst failures are silent. A reminder text or a form that feeds your inbox stops working, and nothing looks wrong until someone asks why it's been so quiet.
Ask yourself this: if your app stopped doing one of its jobs today, how long would it take you to find out?
Security holes get found
Software that was safe the day it launched doesn't stay that way on its own. Problems get found in the pieces it was built from, and attackers often try known holes within days. Someone has to notice, update and check that nothing else moved.
One fix breaks another thing
Without automated tests, or at least a written list of things to try after each change, each fix is a small gamble. That's how an app gets into a state where nobody wants to touch it.
A short check you can do today
- Who gets told when something fails, and how?
- Has anyone ever tried restoring your data from a backup?
- Which outside services does your app rely on, and whose name is on those accounts?
- Who can change the app if the person who built it is away?
If you can answer all four, you're in good shape. Any you can't answer are your to-do list. They're also good questions for whoever looks after your app.
