Business-critical software needs more than a contact address for emergencies. Effective application support combines incident response, routine maintenance and a controlled way to deliver improvements. Without all three, small problems accumulate until every change feels risky.
For a growing business, the support model should be understandable to people outside the engineering team. Staff need to know where to report an issue, what information to provide and when they can expect a response.
Define what is being supported
Start with a service inventory: applications, infrastructure, databases, domains, integrations, scheduled jobs and third-party providers. Record who owns each service and which business workflow depends on it.
This prevents a common gap where the application is covered but its email provider, mobile app certificate or nightly data import is not. From the user’s perspective those components are all part of the same service.
Use priorities people can apply consistently
Severity should be based on impact, not on how strongly a ticket is worded. A simple model might distinguish:
- Critical: the service is unavailable, unsafe or causing material data loss;
- High: an important workflow is blocked and there is no reasonable workaround;
- Normal: a limited fault exists but the business can continue;
- Improvement: a change would make the system more useful, efficient or maintainable.
Response targets should describe when investigation begins and how updates will be communicated. They should not promise an exact repair time before the cause is known.
First-hand observation
Supporting My Safety Buddy after taking over its existing platform meant treating production support and feature development as one continuing responsibility. The support record informs what should be improved next, while controlled delivery makes those improvements safer to release.
Monitor customer outcomes, not only servers
A healthy server does not prove that a customer can sign in, submit an order or receive a safety notification. Monitoring should cover important end-to-end actions as well as infrastructure measures such as CPU, storage and error rates.
Logs and alerts also need an owner. An alert that nobody sees—or that fires so often it is ignored—does not reduce risk. Review alert quality after incidents and remove noise that obscures genuine failures.
Keep maintenance visible
Framework, operating-system and dependency updates should be planned work. Delaying every update until it becomes urgent increases the size and uncertainty of the eventual change. A recurring maintenance window allows smaller updates to be tested and released while they are still manageable.
The same applies to backups, certificates, access reviews and recovery tests. These tasks rarely appear on a feature roadmap, but they determine how well the business can respond when something goes wrong.
Connect support and development
Incidents reveal where the application and its operating process need improvement. Repeated manual fixes should become backlog items with an owner and priority. Over time, the support record provides evidence for decisions about automation, redesign or modernisation.
Keeping support and feature delivery connected also reduces handovers. The engineer investigating a fault can explain the underlying constraint, while the business can decide whether a permanent change is worth prioritising.
Ask for evidence from a support provider
A useful support arrangement should make responsibility clearer, not more opaque. Ask how access is controlled, how changes are reviewed, where documentation is kept, what monitoring is in place and how the service can be handed over in the future.
Regular reporting should describe meaningful work: incidents, causes, recurring risks, maintenance completed and recommended priorities. A raw count of tickets says little about whether the application is becoming more reliable.
Kitek supports web and mobile applications that businesses depend on, including systems taken over from another supplier. We begin by understanding the operational context, stabilising the essentials and establishing a support process the business can see.