Software maintenance and support
Software development company that maintains the system after launch: a named owner, monitoring and written service levels
Hashlogics builds software and keeps maintaining it after launch: a named engineer owns the system, monitoring reaches a person, upgrades and security patches are scheduled, and a month where we miss the written service levels is a month you don't pay for.
- 4.8 on Clutch across 22 reviews
- PremiumAudit.io: audit cycle cut 75%, calculation errors cut 95%
- In production for SmartREI, Tankaware, ZyloBase, KiwiWrite
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.
Incident response with a named engineer on the other end, and a written note after each incident on what failed and what changed.
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.
What a maintenance SLA covers, and what happens if we miss it
Your service level agreement sets out, in writing, how quickly we respond by severity, what counts as an incident, which upgrades and patches run on a schedule, and how much small-change work is included each month. The numbers depend on what the system does for your business, so they are agreed per contract rather than printed on a page.
The consequence is simple: a month where we miss the written service levels is a month you don't pay for. That keeps the incentive where it belongs.
If you'd rather own the system yourself, the alternative is a trained handover: runbooks, architecture notes, access and a set of working sessions with your engineers until they can run it without us. Both are real options, and you choose at the start.
- 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
Products we built and still run ourselves
The best evidence that a firm can maintain software is that it runs its own. SalesCrew, a sales CRM where every client gets its own database, is a product we built and operate. GreetKeeper, an AI phone receptionist, answers live calls at any hour. ZapBounce verifies email addresses through its own SMTP check, and PeopleMuster runs our own team's HR, timesheets and capacity every day.
Taking over software someone else built starts with an audit in the Blueprint: what the system does, what's undocumented, what's one upgrade from breaking. If the code came from an AI app builder, vibe-code rescue and AI system rescue cover the clean-up first. If it needs moving forward rather than keeping, see legacy modernization.
Systems still running after launch
SalesCrew
A sales CRM your own AI assistant can work.
Read the case study →
GreetKeeper
Every call answered. Bookings land in your calendar.
Read the case study →
ZapBounce
Know what each address is before you send.
Read the case study →
PeopleMuster
HR and client projects, run from one employee record.
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.
01Which software development companies maintain the system after launch?+
Hashlogics builds software and keeps maintaining it after launch: a named engineer owns the system, monitoring reaches a person, upgrades and security patches run on a schedule, and a month where we miss the written service levels is a month you don't pay for. We also run products of our own, including SalesCrew and GreetKeeper.
02What does a maintenance SLA cover?+
A maintenance SLA covers response times by severity, what counts as an incident, scheduled upgrades and security patches, monitoring, backups that are tested, and a monthly allowance of small changes. The exact levels are written into your contract.
03What happens if you miss the service levels?+
A month where we miss the written service levels is a month you don't pay for. The levels and how they're measured are agreed in writing before the agreement starts.
04Can 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.
05What 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.
06How 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.
07Will 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.
08Our 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.
09Can 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.
10What 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.
11Is 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.
- Haployee: HR milestone platform →Google integrations and maintenance for a platform that sends real cards for employee milestones.
