Software maintenance and support
Your software has no owner. That is the problem
You get a named team keeping a live system healthy: upgrades applied before they become emergencies, monitoring that reaches a person, and a written answer to who fixes what.
Most software does not fail because it was built badly. It fails because the people who built it left, the dependencies aged, the platform moved underneath it, and nobody was watching any of that. Maintenance is not bug fixing. It is holding a system steady while the ground under it keeps moving. Most agencies stop that work the week the invoice clears. We built the company around not stopping.
The upgrade nobody wanted to be responsible for
It starts small. A framework version goes out of support. A library gets a security advisory. An API you depend on announces a deprecation with a date twelve months out.
Each is a job somebody could do in a day. None of them is anybody's job. A year on, the API is off and the framework is three versions behind. What was a day of work now needs a business case.
Neglected software has its own economics. The cost does not sit still while you ignore it. It compounds, quietly, until a routine upgrade needs a budget and a rewrite gets proposed instead.
What a maintenance engagement covers
Agreed in writing before it starts, so nobody discovers the boundary during an incident.
Upgrades applied on a schedule, while they are still routine rather than urgent.
Monitoring wired to reach a person, since an alert that only lands in a dashboard is a log entry with ambition.
Security patching, with a written route for anything that has to move faster than the usual cycle.
Backup and restore that has actually been tested, because an untested backup is a belief rather than a capability.
Small changes and fixes within an agreed scope, so a broken report does not need a new contract.
A written runbook covering the failures we have seen, which stays yours whether you keep us or not.
What sits outside it
- New feature work, which we quote separately so maintenance capacity is never quietly consumed by a roadmap.
- A full rewrite, which we scope as legacy modernisation rather than folding into a maintenance retainer.
- Read the systemPaid diagnostic where we must go inside.
- Find the cliffsUnsupported versions, dead deprecations.
- Make it visibleMonitoring that pages a person.
- Clear the backlogThe upgrades already overdue.
- Hold it steadyScheduled work, agreed service level.
- Write it downRunbook yours to keep.
The second station usually produces the surprise. Most teams know their software is behind, and very few know which of the things they depend on already has an announced end date.
Inheriting a system nobody can explain
The original developers have gone. Documentation is a README from four years ago. There is a scheduled job on a server nobody has logged into since the person who set it up left.
This is why we charge for the diagnostic rather than guessing at it. Two weeks inside a codebase produces an honest map. What runs where. What it needs. What has no owner. Which parts are fragile, as opposed to merely unfamiliar. Quoting maintenance without that is a guess dressed as a price.
- Scoping conversations cost nothing. The paid diagnostic applies only where we must go into the code.
- You keep the written assessment whether or not you continue with us.
- We take on systems built by other teams, in whatever they were built in, including no-code platforms.
- Where the honest answer is replace rather than maintain, we say it in the assessment.
What we already run
Web and API
Mobile
Data and infrastructure
No-code and automation
Systems still running after launch
TankAware
AI + IoT petroleum site management for Sutherland Excavating Ltd.
Read the case study →
Maidily
Integrated operations platform for residential cleaning businesses.
Read the case study →
Elevent
Real-time multiplayer trivia platform for corporate events and training.
Read the case study →
TomoDomo
Coliving operations platform for TomoDomo, Switzerland.
Read the case study →
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The usual support arrangement against ours
The difference is whether anyone is looking at the system when nothing is currently broken.
| Criterion | The usual approach | How we work |
|---|---|---|
| When work happens | When something breaks. | On a schedule, plus when something breaks. |
| Upgrades | Deferred until an emergency forces one. | Applied while they are still routine. |
| Monitoring | A dashboard nobody opens. | Alerts that reach a named person. |
| Backups | Configured once, never restored from. | Restore tested, so it is a capability not a belief. |
| Knowledge | In one contractor's head. | In a runbook you keep either way. |
| Scope arguments | Held during the incident. | Settled in writing before it starts. |
01Can you take over software another company built?
Yes, and that is most of this work. Scoping conversations cost nothing. Where we have to go inside an existing codebase to answer honestly, a paid two-week diagnostic comes first. It produces a written map of what runs, what it needs, and what is already past its end of support.
02What if the original developers are gone and there is no documentation?
That is the normal starting position rather than an obstacle. The diagnostic exists to rebuild what nobody can tell us. What is deployed where. Which jobs run on a timer. Which parts have an announced end date. The runbook that comes out of it is yours permanently.
03How is this different from a support retainer that just fixes bugs?
Bug fixing waits for a failure. Maintenance mostly prevents one. The valuable half of this work happens while nothing is broken. Upgrades land on schedule, warnings get triaged, backups get restored as a test. A retainer that only reacts leaves the growing problem untouched.
04Will you also build new features?
Yes, quoted separately from the maintenance agreement. Keeping them apart protects both. Where a roadmap can quietly eat maintenance time, upgrades stop happening. The split is written down before we start.
05Our system is on an old framework version. Is that the whole problem?
Rarely on its own, though it is usually the most visible symptom. The version tells you nobody has been maintaining it. The real risks sit elsewhere. An unwatched timed job. A library with a live security warning. A backup nobody has restored from. We check all of it rather than fixing on a version number.
06Can you maintain something built on Bubble or another no-code platform?
Yes. Several systems we run are Bubble builds, including Golancer and TomoDomo, and PremiumAudit runs its AI on Bubble with the Claude API. No-code systems still have integrations that break and platform changes that land. They need maintenance for the same reasons.
07What response times do you commit to?
We work to an agreed service level, and it is written into the contract rather than promised on a web page. The right level depends on your system and what an outage costs you. The scoping call settles it. We will not quote a number here that we have not agreed with you.
08Is this only for enterprises, or can a small team use it?
A small team is often where the need is sharpest, because there is nobody internally to absorb an upgrade. Maidily is a cleaning business, not an enterprise, and its platform still has to keep working. Larger organisations add access control, change approval and audit expectations on top of the same work.
Related
- Legacy modernization →When maintaining it is no longer the right answer.
- AI prototype to production →Hardening something that never reached production standard.
- Staff augmentation →Adding senior people to a team you run.
- Can you scale a Bubble app →What breaks on a no-code platform, and when.
- Custom software development →The builds we maintain afterwards.
