Engineering services
Maintenance & Support
After launch we keep it running — helping your team when they get stuck, fixing the small things inside the working day, applying security updates, and adding new features as your business changes.
Part of your product’s journey
Of the eight stages we run, this service covers Maintain, Scale. We also run the others.
What this makes possible
Software does not hold still after launch. The outside components it is built from publish security warnings. Security certificates expire. The services it connects to withdraw the features you depend on. Data grows until a search that used to be instant is not. None of this is caused by anything you did. It happens to every live system, whether or not anyone is watching.
Our approach in more detail
The common arrangement after a project ends is that nobody owns it. The agency has moved on, the freelancer answers sometimes, and small problems pile up quietly until one of them becomes urgent. By then the fix is not a fix. It is an upgrade across four major versions at once, or a scramble to move off a service withdrawn six months ago with a notice nobody read. Deferred maintenance does not stay the same size.
We take ownership instead. Faults are ranked and answered within a response time written into the contract. Security warnings are reviewed on a schedule. The components the software is built from are kept current, so upgrades never pile up into a rebuild. Performance is tuned against measurement rather than guesswork. And new features keep arriving — because a product that only ever receives fixes is a product slowly going out of date.
What you get
- Day-to-day help for your team
- An agreed time to respond, and an agreed time to fix
- Problems sorted by urgency, then fixed
- Security updates, and upgrades to the parts we build on
- Server upkeep, and renewal of security certificates
- New features as the business needs them
- Written documentation kept up to date
How we get there.
- 01
Technical audit
We read the code, the setup it runs on, and the path a change takes to reach customers. Then we write down what actually exists, including the parts nobody has looked at in a while. This happens before any commitment on either side, because a response time promised over a system we have not read is not a promise worth making.
- 02
Risk report and stabilisation
Security exposure, out-of-date components, anything that would bring the whole system down on its own, and backups that are missing or have never been tested. All of it ranked by how serious it is against how much work it takes. Then the urgent items get closed and monitoring goes in, so we find out about problems before you do. The release process is made repeatable before anything else changes.
- 03
Response times and routine
Severity levels with a target response for each, written into the agreement rather than implied. A regular schedule for applying updates, upgrades taken in small steps, and certificate and backup checks at set intervals. Routine work happens on a rhythm, so it does not have to compete with whatever is loudest that week.
- 04
Ongoing development
The roadmap continues. An agreed amount of capacity each month goes to features and improvements rather than only to faults, with priorities reset with you at the start of each cycle. Performance work is driven by measurement — we find the part that is actually slow rather than the part that looks slow.
- 05
Reporting and review
A monthly summary of what was fixed, what was updated, how the system is performing and what we think is coming. After anything significant, a review written to produce changes rather than to allocate blame. Documentation updated as part of the work, not deferred forever.
A little more detail.
The process, the fit, and the questions worth asking before we begin.
Is this the right service for me?
- Not for you if nothing has been built yet. Support is for a system that exists. If you are starting from an idea, begin with planning and a scoped build.
- Not for you if we are not permitted to change the code. We can run the hosting on its own, but if faults have to be fixed by somebody else, we cannot be accountable for how long they take.
- Not for you if the expectation is unlimited work for a fixed monthly fee. We agree a capacity and a response time and hold to both, and when a month’s requests exceed the capacity we say so rather than silently dropping things.
- Not for you if the system is written in a technology we do not work in. We would be learning at your expense and responding slowly. A specialist will serve you better, and we will say so at the audit stage.
- Not for you if the real need is a full rebuild and support is being used to put off that decision. We will point it out in the audit, even though a rebuild is a harder conversation than a monthly retainer.
A worked example
Hypothetical scenario
Illustrative: inheriting an app with no current owner
Say you have a working application built two years ago by a team that has since scattered. It runs. Nobody knows how to release a change to it, the last person who did has left, and there is a folder of passwords in a shared drive. An engagement of this shape begins with reading, not changing. The audit typically produces a list along these lines. The framework the application is built on is two major versions behind, with published security warnings against it. A security certificate is renewed by hand and falls due in seven weeks. Backups run to a storage bucket nobody has ever restored from. One server’s settings exist nowhere except on the server itself. And the keys for outside services are shared between the test system and the live one, so neither can be changed without breaking the other. That list is worked through in order of what would hurt most, which is usually the untested backup and the manual certificate before the framework upgrade. Settling a system of this kind takes four to eight weeks alongside normal support.
An illustration of our approach, not a delivered client project.
How quickly do you respond when something breaks?
Response targets are agreed for each severity level and written into the contract, so they are commitments rather than aspirations. In practice: a short window where the product is down or data is at risk, a same-working-day window for serious problems that are not blocking, and a scheduled slot for everything else. The exact numbers are set after the audit, because promising a response time over a system we have not read would be guesswork.
Do you support software you did not build?
Yes, and it is a large share of this work. It always starts with the technical audit and a ranked risk report, before either side commits. Occasionally the audit concludes that the system cannot be economically supported in its current form. We will say that plainly, rather than take a monthly fee against something we know will keep breaking.
What does it cost, and what makes it more or less?
We price against an agreed capacity and agreed response times, rather than per incident. What moves the figure is how many separate services and environments have to be kept up to date, and how far behind the software’s components currently are. Also whether cover outside working hours is needed, and whether a compliance regime applies. The audit is what lets us give a number we will stand behind instead of a range full of caveats.
How do we leave if it is not working?
Thirty days’ notice, either direction, no exit fee and nothing to unwind. Your code, your hosting and your documentation have been in your own accounts from the first day, so leaving means removing our access rather than extracting anything. We run a handover session with whoever takes over and answer their questions afterwards.
Can you work with our in-house team rather than replacing them?
Commonly. The usual splits are that we hold out-of-hours and the hosting while your team does feature work, or that we take on the patching and upgrade schedule nobody has time for. We work from Mumbai, so there are overlapping working hours with Europe and Asia-Pacific, and a defined handover point for teams in the Americas. What matters more than the time difference is that severity levels and who to escalate to are agreed in writing.
Bring the pieces together
Tell us what you need to achieve. We’ll help you scope the work and see how it fits your wider product.