Software maintenance for existing web applications and SaaS products
Software maintenance is the work that keeps a system in production correct, secure, and changeable after launch. AL+ maintains web applications, SaaS products, APIs, and internal systems as their ongoing technical owner: releases, fixes, dependency and security updates, infrastructure, monitoring, and continued development.
What software maintenance actually contains
Maintenance is usually budgeted as upkeep. In practice it is four different kinds of work, and only the first is what the word suggests. A maintenance plan that covers only the first kind produces software that runs, drifts, hardens, and eventually gets rewritten.
-
Keeping it running
Dependency updates, security patches, certificate renewals, backup verification, capacity, incident response. Not optional. Skipping it is borrowing at a high interest rate.
-
Keeping it correct
Fixing bugs, and noticing where behavior has drifted from what users need: reports that used to be right, integrations whose other side changed, edge cases that became common as the business grew.
-
Keeping it changeable
Removing complexity that no longer earns its place. Improving tests and deployments so the next feature costs less than the last one. Invisible in the product, decisive for its future.
-
Making it better
Small improvements informed by real usage: a faster page people open every day, a form that fails less often, a workflow with one step fewer. The highest-return changes in most products.
We argue this position at length in Maintenance is product work.
Who needs a maintenance partner
Companies whose product is software but whose business is not software engineering: an online service, a marketplace, a booking system, an internal platform that the operation depends on. Founders whose original developer has moved on. Teams that can build features but do not want to carry infrastructure, security updates, and on-call alone.
Maintenance often begins with a takeover, when the software arrives from someone else. It can also begin with software we built, or with an application that was generated with AI tools and now needs an engineer behind it.
How AL+ maintains software
-
One accountable owner
You talk to the people who do the work. There is no account manager, and nothing is passed down a chain. The same engineers stay on your system, so the knowledge accumulates instead of resetting.
-
Upkeep on a schedule
Dependencies are updated in small steps rather than in one large, urgent upgrade. Backups are restored on a schedule to prove they work. Certificates, domains, and paid accounts have known renewal dates.
-
Monitoring that reaches a human
Uptime and API checks, heartbeats for scheduled jobs, and error tracking, with alerts routed to someone who can act. We built PostDeploy for exactly this, and we use it where it fits.
-
Boring deployments
Every change goes through the same path: review, tests, deploy, verify, and a known rollback. Releases stop being events.
-
A short, steady improvement list
A share of every month goes to keeping the system changeable and to small improvements drawn from real usage. Larger structural work is planned as modernization, not smuggled into maintenance.
-
Written down
How to deploy, roll back, and restore. Where the secrets live. Whom to call at each provider. The system should not depend on any single person, including us.
Security as part of responsible engineering
We are not a cybersecurity company, and we do not sell penetration testing or compliance audits. We do treat security as part of owning a system: supported dependencies, secrets outside the code, authentication and authorization reviewed by hand, input validated where it meets the database, least-privilege access to production, and backups that are tested. If a system needs a specialist assessment, we say so and work alongside them.
Where AL+ fits, and where it does not
-
A good fit
Web applications, SaaS products, APIs, mobile backends, and the infrastructure under them, on cloud or edge platforms. Systems that matter to a business and need a responsible owner for years, not weeks.
-
Not a fit
Ticket-by-ticket support desks with no ownership. Hourly staff augmentation. 24/7 contractual on-call for systems we do not otherwise own. Platforms outside our experience, which we will name in the first reply rather than learn on your budget.
Related thoughts
-
Software needs an owner
Software becomes expensive when nobody clearly owns it. Ownership is a role, not a repository permission, and most struggling systems are missing it.
-
AI-built software still needs an engineer
AI changes how code is produced. It does not remove technical responsibility. Software generated quickly still needs someone who understands it and answers for it in production.
-
Maintenance is product work
Most of a product's life happens after launch. Treating maintenance as a cost to minimize is how software quietly degrades and how the best improvements never get made.
Need someone responsible for your software every month?
Write a few sentences about the system, who built it, and what worries you. You will hear back from the people who would do the work.