Application Support and Maintenance
Software does not stay still after launch. Operating systems ship a major version every year, libraries fall out of support, store policies change, certificates expire, and the integration that worked for two years stops working on a Tuesday for reasons that are not your fault.
An app with nobody maintaining it does not stay as it is. It decays, quietly, until something visible breaks and the repair costs more than the maintenance would have.
We support software we built and software we did not. Agreed response times, someone who knows your system, and enough capacity in the arrangement to make small improvements rather than only firefighting.
What Support Covers
Arrangements differ. These are the parts most of them include.
-
Response to things that break
Triage, diagnosis and a fix, within response times agreed before anything goes wrong rather than negotiated during an incident. Severity is defined in writing, so “urgent” means the same thing to both of us at two in the morning.
-
Keeping up with the platforms
iOS and Android ship a major version every year. Frameworks deprecate on their own schedule. We track what is coming, test against it ahead of release, and do the work before your users find the problem.
-
Dependency and security patching
Libraries, runtimes and framework versions kept current, with security advisories acted on rather than noticed. This is the single most neglected part of running software and the one that turns into an incident.
-
Store submissions and resubmissions
Release builds, signing, certificate renewals, store listing updates, and the resubmissions that follow policy changes. Certificates in particular expire quietly and take the app down loudly.
-
Monitoring
Crash reporting, error tracking and uptime monitoring, watched by someone rather than merely enabled. The point of monitoring is that we find out before you do.
-
Small changes and improvements
A content change, a new field, a tweak to a flow. Retainers include capacity for this, because an arrangement that only covers breakage means every small improvement needs a new conversation and most of them never happen.
-
Backups and recovery
Backups that exist, and a restore that has actually been tested. An untested backup is a belief, not a backup.
-
Reporting
What we did, what broke, what we are watching, and what we think you should do next. In plain language, monthly.
When Teams
Come to Us
-
The app shipped and the team moved on
The build is finished, the developers are on something else, and nobody owns the running system.
-
A new OS version broke something
It worked last month. The phones updated. Now it does not.
-
You need a guaranteed response time
A client, an insurer or an internal policy requires a named provider with defined response times. We put that in writing.
-
The agency that built it has gone quiet
SeeSlow replies, then none. Taking over an unfamiliar system starts with an audit rather than a retainer.
-
Your first month of free fixes is ending
Every project we build includes one month of bug fixing after launch at no extra cost. This is what follows it.
-
Certificates and store access are scattered
Nobody is sure who holds the signing certificate or the store account. We consolidate that and document it, which is worth doing before you need it urgently.
Agency Gone Quiet? Get a Free Site Audit
Tell us what you are running and what is going wrong. We will tell you what we find and what we think it needs, before anyone signs anything.
How We Work
What the system is, what it runs on, what state it is in. For software we did not build, this is a proper audit rather than a look.
Repositories, environments, store accounts, certificates, third-party services. Documented, because this is what is always missing when it is needed.
Severity definitions, response times, what is included, how much capacity for changes. Written down before anything goes wrong.
Monitoring, error reporting, backups and a tested restore, in place before the retainer really starts.
Response, patching, upgrades, releases and the agreed capacity for improvements.
Monthly, in plain language, including what we think should be done next.
What we Support
- Mobile apps in the App Store and Google Play, built in React Native
- Web applications in PHP with Laravel, Node.js with NestJS, and Python with Django
- WordPress sites, including heavily customised installs
- APIs and backend services, including the integrations they depend on
- Infrastructure and deployment pipelines as we find them
We support systems we did not build. That starts with an audit so we know what we are taking on, and so the arrangement is based on the real condition of the system rather than an assumption about it.
How We
Work Together
We work out the arrangement with each client individually. There are no public plans, because a WordPress site and a mobile app with a backend behind it do not need the same thing and should not be priced as if they do.
-
Support retainer
Starting from five hours per month. Covers response, patching, upgrades and a defined amount of small-change capacity. The hours and the response times are agreed with you before anything starts. -
Retainer plus roadmap capacity
For products still being developed. Support plus a reserved share of a developer's time each month for new work, so improvement does not depend on a separate negotiation every time. -
Ongoing team
For systems under active change, a developer and QA working to your roadmap with support folded in. SeeResponse times are part of the agreement, not a marketing claim. We set them against what your system actually needs and what you are willing to pay for, and we write the severity definitions down so there is no argument about them later.
Questions We
Get Asked
-
It starts from five hours a month and goes up with what the system needs. We do not publish plans, because the right arrangement for a marketing site and the right arrangement for an app with a live backend are not the same thing. Tell us what you are running and we will tell you what we think it needs.
-
Yes, and a good share of what we support is someone else’s work. It starts with an audit so the arrangement reflects the real state of the system. See project takeover and modernisation.
-
Agreed per client and written into the arrangement, with severity defined so both sides mean the same thing by urgent. A consumer app with a payment flow and an internal tool used by nine people do not need the same commitment, and you should not pay for one if you need the other.
-
Every project we build includes one month of bug fixing after launch at no extra cost. That covers defects in what we delivered. New features and changes of scope are new work, and we will say so clearly rather than letting it blur.
-
That is one of the things we agree with you when setting the arrangement up. We would rather settle it in writing at the start than have it become a conversation six months in.
-
You take everything with you — code, documentation, credentials, access. We will hand over properly to whoever comes next, because being easy to leave is the only honest way to run a retainer.
-
Monitoring and alerting run continuously. Who responds to an alert at three in the morning, and how fast, is part of what we agree with you rather than something assumed in either direction.