Keep Your Software Patched, Monitored and Moving Forward
Software maintenance and support through month to month Care Plans with written response targets, security patching, dependency upgrades and monitoring, for software we built or software another vendor left behind.
What does software maintenance and support involve?
Software maintenance and support is the ongoing work of keeping a live application secure, working and current after launch: applying security patches, upgrading dependencies and runtimes before they reach end of life, monitoring for errors and outages, fixing defects and making small improvements, under an agreement that sets out response targets, covered hours and what happens outside business hours.
Software does not stay finished. The day an application goes live, its dependencies start ageing. Open source libraries publish security fixes, cloud providers deprecate services, browsers and mobile operating systems change behaviour, and the runtime underneath the code has a published end of life date. At the time of writing (September 2026), for example, Node.js says each long term support release typically receives critical fixes for a total of 30 months, and each Python version receives bugfix and then security releases for about five years. An application nobody touches for two years is not stable; it is quietly accumulating vulnerabilities and upgrade work that gets harder the longer it waits. A widely used industry rule of thumb is that maintenance costs around 15 to 20% of the original build each year, and most of that is not new features. It is the work of standing still safely.
Our Care Plans make that work predictable. A Care Plan is month to month and priced for each client after we have looked at the system. It sets a written response target for each severity level, a regular patch and upgrade cycle, and monitoring designed to tell us about errors and outages before your users do. Software we build comes with a 30 day warranty from launch: we fix bugs and anything caused by our work at no cost. A Care Plan picks up from there. We track your dependencies for published vulnerabilities, apply urgent security fixes out of cycle, and plan runtime and framework upgrades well ahead of their end of life dates rather than in a rush afterwards.
Where the plan allows, time not needed for incidents and patching goes to the backlog of small improvements you actually want. We also take over software built by other vendors or by a departed developer: we start with a structured handover and a health check, so you know what you have, what is at risk and what it will take to keep running, before you commit to anything ongoing. The code, repository and cloud accounts stay in your name, so you are not locked in to us either.
AWLabs is a Sydney based AI and software development company for growing businesses and enterprise. Sister company to All Webbed Up, a separate websites and marketing company.
Why choose AWLabs to look after your software?
Written Response Targets
Each Care Plan sets out what counts as critical, high, medium and low severity, and how quickly we respond to each during covered hours. You know in advance what happens when something breaks, instead of negotiating urgency by email while your users wait.
Security Patching on a Cycle
Dependencies are scanned continuously for published vulnerabilities. Routine patches go out on a regular cycle with tests, and urgent fixes for exploitable issues are applied out of cycle. Patching maps to the vulnerability management principle in ASD Essentials and to the patch applications strategy in the Essential Eight, which contracts still cite, and this gives you the evidence trail to show it happens.
Upgrades Before End of Life
We keep a register of your runtimes, frameworks and managed cloud services with their end of support dates, and schedule upgrades months ahead. Moving one major version at a time is routine; jumping three versions after support has ended is a project.
Monitoring That Reaches a Person
Uptime checks, error tracking and key performance alerts are set up if they do not exist, and routed to an engineer who knows your system. Many problems are fixed before anyone reports them, and the ones that are not arrive with the error trace already attached.
Handover From Another Vendor
We take over software built elsewhere through a structured handover: access transfer, a working local build, a documented deployment and a health report. If the previous vendor is unresponsive, we work from what you own and tell you plainly what is missing.
Steady Improvements
Where your Care Plan includes it, time not needed for incidents and patching goes to a prioritised backlog of small improvements you choose. A monthly report shows what was patched, what was fixed, what was improved and what is coming up, so the plan is visible value rather than an insurance premium.
What technologies do we use for software maintenance and support?
How do we deliver software maintenance and support?
Typical timings; your Schedule of Work sets the real ones.
Access and Handover
We collect access to the repository, cloud accounts, domains, third party services and any existing documentation, and confirm you hold ownership of each. For software from another vendor, we run a handover session with them where possible and record anything that cannot be transferred.
Health Check and Risk Register
We get the application building and deploying from a clean environment, scan dependencies for known vulnerabilities, list runtimes and services with their end of life dates, and review backups and monitoring. You receive a short report with a prioritised risk register and a plan for anything urgent.
Stabilise the Urgent Items
Critical findings are fixed first: exploitable vulnerabilities, missing backups, expired certificates, unsupported runtimes and deployments that only one person knew how to run. This is scoped separately from the Care Plan so the monthly fee reflects steady state work.
Monitoring and Runbooks
We set up or tune uptime checks, error tracking and alerting, and write runbooks for deployment, rollback, restoring from backup and the most likely incidents. Alerts route to the engineers covering your system, and to your team if you want visibility.
Monthly Care Plan Cycle
Each month covers incident response within the agreed targets, the scheduled patch and upgrade cycle, small improvements from your backlog and a written report. We review the risk register quarterly and plan upcoming runtime and framework upgrades ahead of their deadlines.
Annual Review
Once a year we review the work done, incident history and upcoming end of life dates, and recommend whether the Care Plan still fits, whether any part of the system is due for larger investment, and whether it is time to bring maintenance in house. We will help with that transition if it is the right call.
Which businesses need maintenance and support?
Is a Care Plan right for you?
When it is the right fit
- You have a live application that customers or staff depend on, and no in house engineer whose job includes patching and upgrades
- Your software was built by a vendor or developer who is no longer available, and you need someone to take responsibility for it
- You need written response targets for incidents, for your own peace of mind or because a customer contract asks for them
- The system has several dependencies, integrations or runtimes that need planned upgrades before they reach end of life
- You want a steady flow of small improvements without scoping a new project each time
When it is not the right fit
- You already employ engineers who own the system; ad hoc specialist help or a code audit may serve you better than a Care Plan
- The software is a simple brochure site or an off the shelf SaaS product, where the vendor or a basic hosting plan already covers maintenance
- The system is due to be retired or replaced within months, where minimal keep alive support is more sensible than a full Care Plan
- You need a large new feature or a rebuild, which should be scoped as a project rather than squeezed into a Care Plan
- You need a 24/7 staffed operations centre watching your systems around the clock, which is the domain of dedicated managed service providers
Software Maintenance & Support: a quick glossary
- Service level agreement (SLA)
- The written terms that set out how quickly a support provider will respond to, and work on, issues of each severity, during which hours, and what happens if the targets are missed.
- Response time vs resolution time
- Response time is how quickly an engineer acknowledges and starts work on an issue. Resolution time is how long it takes to fix it. Honest agreements commit to response times, because resolution depends on the problem.
- End of life (EOL)
- The date after which a runtime, framework or product stops receiving updates, including security fixes. Software still running on an end of life component becomes steadily more exposed.
- Long term support (LTS)
- A release line that a project commits to supporting for an extended, published period. At the time of writing, Node.js says its LTS releases typically receive critical fixes for a total of 30 months, which is why production systems should run on LTS versions.
- Dependency update
- Moving a third party library your code relies on to a newer version, usually to pick up security fixes or maintain compatibility. Tools such as Dependabot and Renovate propose these automatically for review.
- On call roster
- A schedule that makes a named engineer reachable outside business hours to respond to critical incidents, usually paid as a standby fee plus time worked when called.
- Runbook
- A written, step by step procedure for a routine or emergency task, such as deploying, rolling back or restoring from a backup, so anyone on the team can do it correctly under pressure.
Common questions about software maintenance and support
A common industry rule of thumb (a market planning figure, not our pricing) is 15 to 20% of the original build cost each year, covering patches, upgrades, bug fixes and small changes, plus hosting and licences on top. The real figure depends on how many dependencies and integrations the system has, how often it changes, and what response times you need. Our software maintenance cost guide explains the drivers and the arithmetic in more detail. Our own Care Plans are month to month and priced for each client after we have looked at the system; we do not publish rates or hours.
A Care Plan is month to month and priced for your system. It typically includes response targets by severity during covered hours, dependency and security patching on a regular cycle, monitoring and alerting, runtime and framework upgrades planned ahead of end of life, small improvements from your backlog, and a monthly report. Larger features and major upgrades are scoped separately so they do not quietly consume the plan.
Our standard cover is Sydney business hours, Monday to Friday, with response targets rather than guarantees. For systems where an outage at night or on a weekend has real cost, after hours cover for critical incidents can be added where your system needs it, agreed in writing and priced separately because it means an engineer is rostered and reachable outside hours. We will tell you honestly if your system does not need it.
Yes. We start with a handover and health check rather than an immediate Care Plan, because we need to confirm we can build, deploy and safely change the system before we commit to response targets. If the original vendor has disappeared or will not cooperate, we work from the source code and accounts you own and document anything that is missing, such as credentials or undocumented infrastructure.
Where your Care Plan includes improvement work, quiet months go to your backlog of small improvements, technical debt reduction or documentation, agreed with you in advance. If the system consistently needs less attention than the plan allows, we will tell you and recommend a smaller plan.
Working software can still be vulnerable. Security issues are regularly found and published in open source libraries, and once a fix is public, attackers know exactly what to look for in unpatched systems. Runtimes also reach end of life on published dates, after which they stop receiving security fixes. Small regular upgrades are cheap and low risk; large overdue ones are expensive and risky.
No. The code stays in your repository and your cloud accounts stay in your name. We work through your access, commit through normal pull requests and keep runbooks up to date, so another team or your own staff can take over at any time. We will assist with the transition if you decide to move maintenance elsewhere.
Support is reactive: responding to incidents, answering questions and fixing defects users report. Maintenance is proactive: security patching, dependency and runtime upgrades, monitoring and small improvements that stop problems arising in the first place. A good agreement covers both, with response targets for the reactive side and a regular cycle for the proactive side.
Yes. We maintain web applications, APIs and backends, mobile apps and internal business systems, most comfortably on the stacks we build with ourselves: TypeScript, React, Next.js, Node.js, Python, Flutter and PostgreSQL on AWS, Azure, Google Cloud or Vercel. For anything outside that, the handover and health check tells both of us whether we are the right team before any Care Plan starts.
Response targets should be set per severity level, with a critical outage acknowledged fastest and minor issues handled in the normal cycle, and they should state which hours they apply to. Commit to response times rather than resolution times, because how long a fix takes depends on the problem. We agree the severity definitions and targets with you in writing before the Care Plan starts.
Yes, and we start there before touching the code. We help you find out who holds the hosting or cloud account, domain registrar and DNS, Apple and Google developer accounts, database backups and paid service billing, then move each one into your name. Where an account sits in the departed developer's personal name, we tell you exactly what to request. We can't force a transfer, but we work from whatever you already control.
Close, but narrower. A managed service provider usually runs your IT: devices, networks, Microsoft 365 and help desk. A Care Plan looks after one piece of software: its code, dependencies, hosting, monitoring and small improvements, with response targets during Sydney business hours. Many clients have both, and we work alongside the managed service provider rather than replacing it.
Because with custom software you own the asset, so its upkeep is yours, just as it is inside the subscription price of a SaaS product. The difference is control: you decide what gets fixed, upgraded or improved, and you can move maintenance to another team. Budget for it from the start. Our software maintenance cost guide explains the typical drivers so you can compare the two honestly.