Every website, app and business system starts decaying the day it launches. Frameworks release security patches. Browsers and app stores change their rules. Hosting bills creep, certificates expire, integrations break when the other side updates their API. None of it is dramatic on its own. Left alone for a year or two, it adds up to a system nobody wants to touch.
Most businesses find this out the hard way: the developer who built the thing has moved on, nobody knows the hosting password, and the first anyone hears about a problem is a customer ringing to say the site is down.
Support and maintenance is the fix for that. One team accountable for keeping your software working, with the scope and response times written down.
What looking after software involves
The core of it is routine: dependency and framework updates applied before they become urgent, security patches on a schedule, backups that get tested by restoring them, and monitoring that tells us something failed before your customers do.
On top of that sits the small work that never justifies a project on its own. A field added to a form. A report tweaked. Wording changed, a price updated, an integration adjusted because the accounting software moved something. On a plan, that work just gets done inside the agreed hours instead of waiting for enough of it to pile up.
We support systems we built and systems we inherited. For our own builds, maintenance is a natural extension of how we develop software: documented, tested and handed over properly. For inherited systems, we review first. If the codebase turns out to need rescue work before it’s safe to maintain, or it’s an AI-built app that was never hardened for production, we’ll tell you that up front and quote it as its own job.
Websites need this too
A business website is software, and it rots the same way. CMS and plugin updates, form and email deliverability checks, performance kept honest as content grows, and small content changes handled without your team fighting the editor. If the site has drifted too far for maintenance to save, a rebuild is sometimes the cheaper path, and we’ll show you the comparison rather than sell you the bigger job by default.
No lock-in, on purpose
Support agreements have a bad reputation because plenty of them are designed to be hard to leave. Ours aren’t. You own the code, the accounts and the documentation from day one, and everything we do is logged so another developer could pick it up tomorrow. We want you to stay because the work is good, not because leaving is painful.
That also means we’ll tell you when you’re paying for more than you need. A system that’s stable, low-risk and rarely touched might only need a light plan, or none at all. See how we quote for how we put those numbers together.
Start with what’s running
Send a list of what you’ve got: the site, the app, the internal system, where each one is hosted and who built it. We’ll review the lot, flag anything urgent, and come back with a support option priced in writing.