Who is responsible for running custom software once it's live?
Somebody has to be, and it should be written down before launch. Running it means hosting, backups that have been test-restored, monitoring, security updates, and a named person who responds when something breaks. Decide in advance how long the system can be down before it costs money — that single answer determines almost everything else, including how much monitoring is worth building.
Start from how long you can be down
Tolerance for downtime is a business decision, not a technical one, and it is the input everything else follows from. A tool used by three office staff during business hours can be down for an afternoon. A system that routes inbound leads cannot be down for an hour without losing money.
Answer that first, out loud, and then build the response to match. Most teams over-engineer the low-stakes tools and under-protect the one that touches revenue.
What running it actually includes
- Hosting and certificates. Someone owns the account, the bill and the renewal. Expired certificates remain a leading cause of avoidable outages.
- Backups that have been restored. Untested backups are an assumption. Restore one on a schedule and time it.
- Monitoring. Not just uptime — data freshness too. An application can be perfectly up while its data silently stops arriving.
- Security updates. Dependencies publish advisories continuously; someone has to read and apply them.
- Incident response. A named person, a way to reach them, and an agreed expectation for how fast, per severity.
The alarm most systems are missing
Conventional monitoring answers "is the server responding?" For operational software the more important question is "did the expected things happen?" A sync that quietly stops importing leaves an application that looks healthy and a report that is wrong.
So the check to build is an expectation check: we normally see records in this window; we saw none; alert. It costs very little and it catches the failure class that damages trust the most. It is standard in the way we run operational systems and connected integrations.
Decide who, explicitly
There are three workable arrangements: your builder supports it under an ongoing agreement, an internal person owns it, or you hire a third party to maintain someone else's code. All three work. What does not work is assuming, which is how a business discovers at eleven at night that nobody is responsible.
If you choose the third option, the handoff package determines whether it is feasible at all — which is why documentation quality should be settled during the build rather than negotiated after. Ask about ongoing support arrangements before launch, not after the first outage; see discuss your project.
Topics: hosting · operations · monitoring · support
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.