Software maintenance and support
Software maintenance with an owner who answers at 2am
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 systemEvery build starts with a fixed-fee Blueprint: an engineer reads your real systems and writes the plan, with a fixed price for each milestone rather than a guess. The fee is credited in full against the build, and if the plan isn't one you'd act on, you don't pay for it.
- 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 the Blueprint is paid work rather than a guess. Time inside a codebase produces an honest map: what runs where, what it needs, who owns none of it. Then the harder call — which parts are fragile, as opposed to merely unfamiliar. Quoting maintenance without that map is a guess dressed as a price.
- Scoping conversations cost nothing. The Blueprint is fixed-fee and credited in full against the build; if the plan isn't one you'd act on, you don't pay for it.
- 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
- Next.js
- React
- Vue.js
- Node.js
- FastAPI
- Ruby on Rails
- PHP / Laravel
Mobile
- React Native
- App Store releases
- Play Store releases
Data and infrastructure
- PostgreSQL
- MySQL
- Redis
- Supabase
- AWS
- Vercel
- Docker
- Nginx
No-code and automation
- Bubble
- n8n
- Zapier
- WordPress
Systems still running after launch
TankAware
AI + IoT platform for petroleum site management.
Read the case study →
Maidily
Integrated operations platform for residential cleaning businesses.
Read the case study →
Elevent
Real-time multiplayer trivia for corporate events and training.
Read the case study →
TomoDomo
The platform that runs TomoDomo's Swiss coliving spaces.
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.
When work happens
The usual approach
When something breaks.
How we work
On a schedule, plus when something breaks.
Upgrades
The usual approach
Deferred until an emergency forces one.
How we work
Applied while they are still routine.
Monitoring
The usual approach
A dashboard nobody opens.
How we work
Alerts that reach a named person.
Backups
The usual approach
Configured once, never restored from.
How we work
Restore tested, so it is a capability not a belief.
Knowledge
The usual approach
In one contractor's head.
How we work
In a runbook you keep either way.
Scope arguments
The usual approach
Held during the incident.
How we work
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. The Blueprint is fixed-fee and credited in full against the build; if the plan isn't one you'd act on, you don't pay for it. 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 Blueprint 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. The first 2 months of support and maintenance are free, with every build.
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.
