Application Support & Maintenance

Incident response with agreed severity levels, response times, and a written post-incident review for anything significant. The review matters more than the response time: an incident that recurs monthly because nobody had time to find the root cause is far more expensive than the hours spent on each individual fix. We track recurrence explicitly and treat a repeat incident as a defect in our own process.

• Severity definitions agreed per system
• Escalation paths and on-call rota
• Written post-incident reviews
• Recurrence tracking and root-cause work

Triage, reproduction, fix, and regression test — tracked in a system you can see rather than reported to you after the fact. Reproduction is where most of the time goes and where most vendors cut corners; a fix applied without a reliable reproduction is a guess, and guesses come back. We write a failing test first wherever the codebase allows it.

• Reproduction before fix, wherever possible
• Regression test for each resolved defect
• Shared tracker with real status
• Monthly summary of what was fixed and why

Dependency monitoring, CVE tracking, and scheduled patch cycles so upgrades happen on a calendar rather than in a panic. The risk in a mature codebase is rarely a dramatic zero-day; it is the accumulation of thirty minor versions behind, until the upgrade path itself becomes a project. Steady small patches prevent that compounding.

• Automated dependency and CVE monitoring
• Scheduled patch windows
• Severity-based emergency patching
• Upgrade path maintained, not deferred

Profiling, query tuning, caching, and front-end work driven by real usage data rather than intuition. We measure first and publish the numbers, because performance work without a baseline is indistinguishable from performance theatre. Most systems have two or three dominant bottlenecks and a long tail that is not worth touching.

• Baseline measurement before any change
• Database query and index analysis
• Caching strategy at the right layer
• Front-end load and interaction metrics

A reserved share of each month for new work, so the product keeps improving instead of only being defended. Support arrangements that cover incidents alone tend to produce systems that are stable and slowly becoming irrelevant. Reserved capacity keeps small improvements flowing without needing a separate project each time.

• Agreed monthly capacity for new work
• Backlog prioritised with you each cycle
• Same delivery standards as project work
• Rollover rules agreed in advance

Alerting, dashboards, and log aggregation configured so problems surface before your users report them. The goal is a small number of alerts that always mean something — an alert channel everyone has learned to ignore is worse than no alerting, because it creates the appearance of coverage.

• Uptime, latency, and error-rate alerting
• Structured logging and log aggregation
• Dashboards for technical and business metrics
• Alert tuning to eliminate noise