Support is not a phone number that answers eventually. It is a defined response target, a patching rhythm, tested restores and an improvement backlog that moves every fortnight. We take on software we wrote and software we inherited.
A maintenance agreement describes four things: response speed, patching frequency, what we monitor and how much improvement work is included monthly. Everything else is quoted separately.
Most arrangements begin with a specific event — an outage, a departed developer, or a security notice nobody can act on.
A service stopped overnight and nobody in the business knows where it is hosted, which account pays for it, or how to restart it. The immediate work is recovery; the durable work is writing the runbook that should have existed.
An internal tool is business-critical and its author is no longer available. We start by establishing what is actually running in production rather than trusting the repository.
A notice arrives about a library deep in the dependency tree. Nobody knows whether the system is affected. We assess exposure, test the upgrade in staging and report in writing.
A system that was fast two years ago now takes eleven seconds to open a job list. The usual causes are unindexed growth and report queries against live tables. Both are measurable first.
A scheduled backup has reported success for years and no one has attempted a restore. We treat that as untested, run a drill into an isolated environment and record the recovery time.
Taking on an unfamiliar system carries risk for both sides. The first six weeks are structured to reduce it: stabilise before improving.
A short review of the application, its hosting environment, dependencies and data. The output names the risks we can see and those we cannot yet see.
Before enhancements we close the obvious gaps: monitoring that alerts someone, backups restored at least once, credentials in a managed store, access restricted to named accounts. Two to four weeks.
As we work we record how the system is deployed, where it runs and how failures present themselves. That documentation is what makes the arrangement transferable.
Improvements sit in one prioritised backlog owned by a named person on your side. Releases go out fortnightly with release notes; emergency fixes follow the severity process.
Quarterly we report on availability, incident volume, resolution times, patch status and open risks. The review is where we raise anything structural, including requests better handled as a project.
The client is described by sector only.
A WA utilities maintenance provider ran a scheduling and job capture platform whose original developer had ceased trading. Nobody held the deployment credentials, the database had never been restored from backup, and a monthly report failed silently whenever a nightly job overran. We began with a four-week stabilisation: monitoring and alerting, a restore drill into an isolated environment, credential custody transferred to the client and access restricted to named accounts.
Tiers differ by response target, coverage hours and included improvement allocation. All include monitoring, patching and the quarterly review.
Indicative, exclude GST and exclude cloud consumption, billed by your provider into your own account. Fees assume one production application with staging; additional applications are quoted individually. The initial term is six months, then month to month with one month's notice.
Support quality is mostly a matter of cadence. These are the practices we follow on every agreement.
Framework and library updates are reviewed fortnightly and applied in a window agreed with you. Security patches follow the vendor advisory and are tested in staging first.
Automated scans run on every commit and weekly against the deployed state. Findings are triaged by exploitability rather than severity label, so the list you receive is actionable.
Backups are restored into an isolated environment on a schedule, with elapsed time and data currency recorded. A backup never restored is treated as unproven.
Every production change is recorded with its purpose, rollback step and blast radius. Changes carrying data or downtime risk are scheduled with you in advance.
Error rates, response times, queue depth and integration freshness sit on a dashboard you can open at any time. Each alert names the runbook section that applies.
Yes, subject to an assessment. We establish that the system is maintainable — a deployed environment, identifiable source and no licensing obstacle. Where it cannot be supported safely, we say so.
Severity-one incidents are acknowledged within the target for your tier, typically fifteen to thirty minutes during coverage hours. Lower severities are acknowledged within one business day.
An incident is something that has stopped working; a change is something you would like to work differently. We classify at triage, because the distinction determines whether it draws on the included allocation.
We tell you when maintenance has become poor value. If the cost of keeping a platform running approaches the cost of rebuilding it, that appears in the quarterly review with figures, and you decide.
A short assessment gives you a written view of risks, patch status and recovery readiness before you commit to anything.
