Custom Software
One system that matches your real process, instead of four tools and a spreadsheet holding the gaps together.
Software support and maintenance
Software you own still needs someone who knows it
Ongoing maintenance for software we built or inherited — security updates, platform changes, fixes, and steady improvement.
The problem
Software is not finished at launch. Dependencies get security advisories, Apple and Google change requirements every year and start rejecting builds that were fine last time, and the small annoyances staff work around quietly become the reason nobody trusts the system. Meanwhile the developer who built it has moved on, and nobody left can safely change anything.
How we approach it
A standing arrangement rather than emergency call-outs. Dependencies and platform requirements are tracked and applied before they become forced. A defined route for reporting problems, with response expectations in writing. Small improvements land continuously so the software keeps matching the business instead of drifting away from it.
The mobile platforms make this non-optional. Apple and Google both raise minimum requirements on a schedule, and an app that is not updated eventually stops being accepted at all.
Web software degrades more slowly but in the same direction, usually through dependencies with security advisories nobody is watching.
What you get
- Dependency and security updates applied on a regular schedule
- Platform and OS compatibility maintained ahead of deadlines
- A defined channel for reporting issues, with agreed response times
- Bug fixes and small improvements within the monthly allowance
- Uptime and error monitoring with alerts
- Backup verification — a backup nobody has restored is a hope, not a backup
- A short written summary each month of what changed
Typical features
A good fit for
- Businesses depending on software daily with no in-house developer
- Teams who inherited a system when its original developer left
- Anyone running a mobile app, which the platforms require keeping current
From real projects
What this has looked like in practice
Each of these is drawn from a case study on this site, not from a hypothetical.
- GameLynx's client was written to work against both the pre-auth and post-auth versions of its API, because mobile rollouts are gradual and the app and server are never the same age.
- A GameLynx production build shipped with configuration missing from release builds, producing a blank map that worked perfectly in local testing. It now degrades to a placeholder rather than crashing, and configuration moved to managed environment variables.
Questions about ongoing support
Do you support software you did not build?
Often, yes. It starts with a paid review of the codebase and infrastructure to establish what is there. Sometimes the honest answer is that a rebuild costs less than maintaining what exists, and that is worth knowing before committing to either.
What response times do you offer?
They are agreed in writing for your plan and depend on what the software does. Something staff use hourly warrants a different commitment from an internal report. We will not promise a response time that assumes nobody sleeps.
What if we need a large new feature?
Larger work is quoted separately as a project. The monthly arrangement covers maintenance and small improvements, so a big feature does not silently consume the whole allowance.
Can we stop?
Yes, monthly. You already own the code, the accounts, and the documentation, so leaving does not require anything to be handed over.
Related
Services that often go with this
Thinking about ongoing support?
Start with a discovery call. It costs nothing to find out whether this is the right shape of work for your situation.
Prefer email? Contact@DeviceBytes.com