Our Services
Maintenance & Support Services
Software does not sit still after launch. Nothing about it changes on its own, and yet it degrades — because the world around it moves. Browsers update, operating systems raise their minimum requirements, dependencies publish security advisories, payment providers deprecate API versions, certificates expire, and the traffic patterns the system was sized for shift as the business grows. A system left untouched for two years is not merely dated; it is frequently unable to be changed without substantial remedial work first.
Atisolve provides ongoing maintenance and support for web applications, mobile apps and the infrastructure they run on. We work with businesses whose original developer has moved on, businesses with an internal team that needs cover outside working hours, and businesses that have realised the annual cost of doing nothing has quietly exceeded the cost of maintenance.
What Deferred Maintenance Actually Costs
The cost of neglect is invisible until it arrives all at once, which is what makes it easy to defer. It accumulates in several distinct ways.
- Security exposure grows continuously. Vulnerabilities in dependencies are published publicly, and automated tools scan for them indiscriminately. An unpatched system becomes more exposed every month without anything changing.
- Upgrades get harder the longer they are left. Moving a framework forward one version is routine; moving it forward five is a project, because breaking changes compound and the migration guides assume you took the intermediate steps.
- Platform deadlines arrive regardless. App stores raise minimum SDK requirements, cloud providers deprecate service versions, and payment processors retire API versions on their schedule. These are not negotiable, and meeting them from a long-neglected codebase is far more work than from a current one.
- Knowledge decays. The people who understood the system move on, and the longer nobody touches it, the more expensive it becomes for anyone to re-establish how it works.
- Small faults become normal. Teams work around a bug rather than reporting it, until the workaround is embedded in how the business operates and the underlying fault is forgotten.
What We Cover
Security Patching
Monitoring advisories for your dependencies and platform, assessing which genuinely affect you, and applying updates with testing rather than blindly.
Dependency Upgrades
Keeping frameworks and libraries current incrementally, so upgrades stay routine instead of becoming periodic migration projects.
Bug Fixing
Diagnosing and resolving faults reported by users or surfaced by monitoring, with the root cause addressed rather than the symptom suppressed.
Monitoring and Incident Response
Uptime, error and performance monitoring with alerting that reaches a person, and defined response when something breaks.
Platform Compatibility
Keeping pace with OS releases, browser changes, app store requirements and third-party API deprecations before they become outages.
Small Enhancements
Ongoing capacity for the modest improvements that accumulate — a report, a field, a workflow adjustment — without needing a project each time.
How We Start
Handover and Audit
We establish what state the system is genuinely in: whether it builds from a clean checkout, whether dependencies are current, whether tests exist and pass, where it is deployed, who holds credentials, and what documentation exists. Systems inherited from a previous developer frequently have gaps here — a build that only works on one person's machine, or deployment access nobody currently has.
Stabilising the Basics
Before ongoing maintenance is meaningful, certain things must exist: a reliable build, a deployment process that does not depend on one person, error monitoring, and verified backups. Where these are missing we establish them first, because maintaining a system you cannot deploy or restore is not maintenance.
Risk Assessment
We produce a prioritised list of what most needs attention — outdated dependencies with known vulnerabilities, approaching platform deadlines, single points of failure, missing monitoring — with the reasoning explained so you can decide what to fund and when.
Agreeing the Arrangement
We define what is covered, how issues are raised, what response times apply and how work outside the agreement is handled. Ambiguity here causes friction later, particularly about whether something is a bug covered by maintenance or a change that is not.
Routine Maintenance
Regular cycles of dependency updates, security review and monitoring checks, plus the reactive work as it arises. The routine cycle is what prevents the accumulation that makes maintenance expensive.
Periodic Review
We review what has been consuming time, what keeps recurring and what is worth addressing structurally. Recurring incidents usually indicate an underlying problem that is cheaper to fix than to keep responding to.
How We Handle Incidents
Detection Before Reports
The objective is to know before customers tell you. That requires monitoring that reflects the user's experience rather than only server health — a server can be running normally while a critical page returns errors for everyone. We monitor error rates, response times and the success of key user journeys, and set alert thresholds so they indicate genuine problems. Alerts that fire routinely without needing action are actively harmful, because they teach people to disregard the channel that will eventually carry something urgent.
Diagnosis Over Guessing
Under pressure the temptation is to change something plausible and see whether it helps. That frequently makes diagnosis harder, because the system state has now changed for reasons unrelated to the fault. We work from evidence — logs, traces, recent deployments, infrastructure changes — and prefer to restore service by reverting a recent change rather than fixing forward under pressure. Understanding what happened comes after service is restored, not instead of it.
Fixing Causes
A fault that recurs has not been fixed. When the same issue appears repeatedly we treat the underlying cause as the work item rather than continuing to apply the same remedy. Frequently the root cause is not in the code at all but in a process — a manual deployment step that is sometimes skipped, or a configuration change applied to one environment and not another.
Taking Over Someone Else's System
Much of our maintenance work involves systems we did not build, and this is normal rather than problematic. The first task is establishing an accurate picture, which usually differs from what we were told. Documentation is often absent or out of date. Test coverage is frequently thinner than believed. There is sometimes a gap between the code in version control and what is actually deployed, which is a specific risk worth resolving before anything else.
We work through this methodically and report what we find honestly, including when the honest finding is that the system is in worse condition than expected. Occasionally the conclusion is that continued maintenance is poor value compared with replacing a particular component, and we will say so rather than billing indefinitely for keeping something alive that should be retired.
Preventive Work That Reduces Incidents
Most maintenance effort in neglected systems goes on reacting. The proportion shifts substantially once a few preventive measures are in place, and the shift is usually visible within a couple of months. The measures themselves are unremarkable, which is partly why they get skipped.
Certificates and domains should renew automatically, because expiry is among the most common causes of sudden total outage and among the easiest to prevent. Disk and database capacity should be monitored with alerts set well before exhaustion, since a full disk fails in confusing ways rather than cleanly. Scheduled jobs should report success rather than only failure, because a job that silently stops running produces no error at all — the problem surfaces weeks later as missing data. Log rotation should be configured, since unbounded logs are a recurring cause of the full disks just mentioned.
Dependency updates applied in small regular batches are also preventive rather than merely hygienic. A single library moving one version is easy to test and easy to revert if it misbehaves. Twenty libraries moving several versions each, applied together because the system was left alone for a year, is difficult to test and nearly impossible to bisect when something breaks. The cadence matters more than the effort in any individual cycle.
Support Arrangements
Different businesses need genuinely different arrangements, and paying for cover you do not need is as wasteful as lacking cover you do. An internal business tool used during office hours does not need overnight response. A customer-facing platform generating revenue continuously does.
We structure agreements around what the system actually is: business-hours support for internal tools, extended or on-call cover for customer-facing systems, and retained monthly capacity where you want ongoing improvement rather than only reactive fixes. Response expectations are stated explicitly by severity, because a vague commitment to respond promptly is not a commitment at all.
What Ongoing Maintenance Includes
- Dependency and security updates — reviewed, tested and applied on a regular cycle rather than in an annual scramble.
- Monitoring and alerting — maintained and tuned as the system changes, so coverage does not decay.
- Backup verification — restores tested rather than assumed, on a defined schedule.
- Incident response — within agreed times, with a written explanation afterwards for anything significant.
- Compatibility work — OS, browser, app store and third-party API changes handled before deadlines rather than after outages.
- Reporting — what was done, what was found and what we recommend next, in plain language.
Getting Started
An audit is the sensible entry point, particularly for a system you inherited or one nobody has touched for a while. It establishes what state things are actually in, what the immediate risks are, and what maintaining it properly would involve in both effort and cost. That gives you a basis for deciding how much cover the system genuinely warrants, rather than guessing. Get in touch and tell us what you are running and what is currently worrying you about it.
Frequently Asked Questions
Our system works fine. Why pay for maintenance?
Because the risks accumulate whether or not anything visible is happening. Security advisories are published against your dependencies continuously, and platform deadlines arrive on someone else's schedule. Maintenance is the cost of keeping a system changeable; the alternative is discovering that a routine-sounding update has become a project at the moment you urgently need it done.
Can you maintain a system you did not build?
Yes, and much of our maintenance work is exactly that. We start with an audit to establish the real state, which sometimes reveals gaps such as missing deployment access or a build that cannot be reproduced. Those get resolved first, because they are prerequisites for maintaining anything reliably.
What if the original developers left no documentation?
That is the normal case rather than the exception. We work from the code, the infrastructure and the running system, and document what we establish as we go. It takes longer initially than inheriting a well-documented system, and it is entirely tractable.
How do you decide what counts as a bug versus a change?
A bug is behaviour that differs from what was specified or reasonably expected; a change alters intended behaviour. The boundary is occasionally genuinely ambiguous, and we discuss those cases rather than deciding unilaterally in our own favour. Agreements define the distinction explicitly to reduce how often the question arises.
Will you upgrade our system to newer technology?
Where it is justified. Upgrading for its own sake is not a good use of budget, but staying on versions that no longer receive security updates is a real risk. We recommend upgrades based on support status, security exposure and whether the current version constrains work you want to do — not on whether something newer exists.
Can we start with a one-off review before committing?
Yes, and it is often sensible. An audit tells you what condition the system is in and what it would take to maintain, which is a better basis for deciding on an ongoing arrangement than committing first and discovering afterwards. It also frequently identifies a small number of urgent items worth addressing immediately regardless of what you decide about ongoing support — an expiring certificate, an unpatched vulnerability, or a backup that has never been tested.
How much should maintenance cost relative to the original build?
It varies with complexity and how well the system was built, and general percentages are of limited use. What is more reliable is that neglected systems cost more to maintain than well-maintained ones, because deferred work compounds. A system kept current absorbs routine updates cheaply; one left for years turns each update into a project.
What if we only need occasional help rather than a retainer?
That works for some systems, particularly stable internal tools with no external users. The trade-off is that ad hoc work means we are unfamiliar with the current state each time, and nothing preventive happens between requests. For customer-facing systems where downtime has a cost, a regular arrangement is usually better value than paying more per hour reactively.
Do you provide support for systems built in older technologies?
Generally yes, though we assess viability first. Some older platforms can be maintained safely for years; others have reached a point where security updates no longer exist and continuing carries real risk. Where that is the case we will say so plainly rather than accepting an arrangement that gives you false assurance.
How do you handle emergency changes outside normal cycles?
Through a defined path that trades some process for speed while preserving the ability to revert. Critical security patches and outage fixes bypass the normal release cadence, but they are still deployed in a way that can be rolled back and are reviewed properly afterwards rather than left as undocumented changes.
Have a vision? Let’s bring it to life.
Whether it’s an app, website, or platform—your idea deserves expert execution. Let us help you build it from the ground up with clarity, care, and speed.
Gallery
Subscribe
Get a sneak peek into our latest developments
