Software maintenance services that keep the software you already run safe to change

What our software maintenance services are for

Software that nobody touches still changes underneath its owners. The libraries it depends on accumulate known vulnerabilities. The language runtime it was written for leaves support on a published schedule: each PHP release branch gets two years of active fixes and two more years of fixes for critical security issues only, then none. The payment and email services it calls retire the API versions it was built against.

Our software maintenance services exist so those changes are handled on a schedule, before any of them becomes an outage. The IEEE Computer Society names four types of maintenance work:

• Corrective — repairing what broke.
• Adaptive — keeping the system working as its surroundings shift: runtimes, browsers, the APIs it calls.
• Perfective — improving what users already rely on.
• Preventive — removing the cause of the next failure before it arrives.

Adaptive and preventive work is the easiest to defer, because nothing looks broken yet. Deferred long enough, it comes back as corrective work at a worse moment.

Software maintenance and support services in one retainer

Support is the reactive half: a user reports that invoices stopped sending, and someone has to find out why today. Maintenance is the scheduled half, the upgrades and clean-up that stop the next report from arriving. Buying software support services on their own pays for the first half and leaves the second to chance, so one retainer covers both. It is a fixed monthly fee for a scope agreed before work starts, and every month runs through the same work:

• Security patches and dependency updates — flagged by dependency scanning, then applied and tested before release.
• Runtime and framework upgrades — planned while the current version is still supported.
• Fixes — triaged by severity and worked in that order.
• Monitoring — errors, availability and performance watched, with alerts going to the engineers who hold the retainer.
• Third-party changes — retired API versions, browser releases and operating system updates.
• Small improvements — the adjustments users ask for once the system is part of their day.

Your company owns the code and the intellectual property under every contract, and the accounts stay in its name throughout. When the roadmap outgrows the agreed scope, that work moves to a fixed-scope build or a dedicated team, and the retainer stays on the work it was scoped for.

Application maintenance services for what you already run

Application maintenance services differ with the application, because something different moves underneath each kind of system. Here is what that looks like on six of them.

Response times, severity levels, and what the contract settles

Response and resolution times are set per severity level in each retainer contract. One figure for every client would fail in both directions: a system that has stopped taking orders and a typo on a settings screen are different emergencies, and a single number would either overpromise on the first or waste attention on the second.

Whoever maintains your software, the severity table in the contract is where a vague promise turns into a usable one. It should settle five points:

• How a level is decided — by business impact, such as lost orders or blocked staff, whatever the tone of the message.
• What counts as a response — an engineer's first assessment of the problem, made after looking at it.
• Response and resolution, separately — a quick reply matters only when the fix follows, so each has its own target.
• The hours covered — and what happens to a top-severity issue raised outside them.
• Who can raise the top level — named people on your side, so the highest level keeps its meaning.

Picture a checkout failing on a Saturday. Under a vague contract, that is a message waiting in a queue. Under a specific one, the store owner already knows which level it qualifies for, whether Saturday falls inside the covered hours, and who is allowed to raise it. We write that table for your system while the retainer is scoped.

Taking over software another team built

We do not quote a monthly fee on code we have not read. Taking over software another team built starts with a short paid audit, because what it costs to maintain a system depends on things no sales call reveals. The audit checks whether the application builds and deploys from its repository alone, how far its dependencies and runtime have drifted from supported versions, and whether tests cover the paths that handle money or personal data. It also finds where secrets and access credentials actually live, and what is known only to a developer who has since left.

You get written findings and a fixed-price plan. The plan might be a retainer, or it might show that the system costs more to keep than to replace. The findings are yours to use with any team. For software we built, this step is unnecessary: the team that built it already knows the code.

Talk through a takeover

WordPress speed optimization services

WordPress speed work starts from how the site performs for real visitors, measured across their page loads. Google's Core Web Vitals, read at the 75th percentile of page loads, count a page as good when its largest element renders within 2.5 seconds, it responds to input within 200 milliseconds, and its layout shift stays at 0.1 or below. The responsiveness measure, Interaction to Next Paint, only became a Core Web Vital in 2024, and a lab test with nobody clicking cannot measure it. Google says good scores line up with what its ranking systems seek to reward. We treat that as a reason to fix them, and we make no ranking promise.

What our WordPress optimization services work through:

• Hosting and PHP — the server's response time, and a PHP version that still receives security fixes.
• Caching — full-page caching and a CDN, configured so logged-in and checkout pages stay correct.
• Images — sized for the space they fill, compressed, and lazy-loaded below the fold.
• The database — post revisions, expired transients and autoloaded options left behind by plugins long since removed.
• Plugins — reviewed one at a time for what each adds to every page load, then kept, replaced or removed.
• The theme — scripts and styles loaded only on the pages that use them.

The work is sold as a fixed-price project that ends with the same measurements taken again. Keeping the result is a different job. Every plugin installed and every template added later pulls the numbers back toward where they started, which is why performance optimization can continue inside a maintenance retainer for sites that need it. Moving to a different platform or rebuilding the site is project work, handled under custom web development.

How a maintenance retainer starts

A retainer begins before the first invoice, with reading. Someone has to confirm where the code, the hosting and the third-party accounts really are, and who can reach each of them. On software we built, most of that is already written down. On inherited software, it is part of the audit. The fee is settled last, because it rests on what that reading found.

Documentation is kept current as the system changes, and every account the software depends on stays registered to your company, so nothing about the arrangement rests on a password only we hold. We look after software for companies across the US and Canada, the UK and Europe, the Middle East, and Australia and New Zealand. We keep a daily working overlap with the UK and Europe, the Middle East, Australia and New Zealand, and the US East Coast. For client meetings, we overlap with all of Canada. You can meet the engineers who would maintain your system before you sign anything.

The stack we maintain

This list is drawn from the stack our engineers specialize in, grouped by the work each part does, and the full set appears in the grid further down. Specialization is where a maintenance engagement moves fastest, because nobody is learning the stack at your expense. We also take on systems built on other mainstream stacks: they go through the same audit, and the findings state plainly what supporting them would involve. Legacy .NET Framework is here deliberately, because older systems are where maintenance does the most work.

• React, Next.js, Angular and TypeScript — front ends and admin interfaces.
• Node.js, NestJS, Java, PHP and Laravel — APIs, background jobs and integrations.
• .NET and legacy .NET Framework — current applications and the older ones still running a core process.
• WordPress and Shopify — content sites and online stores.
• PostgreSQL — data, schema migrations and query performance.
• AWS — hosting, deployment and environments in accounts you own.
• Flutter and React Native — iOS and Android apps from one codebase.

What software maintenance costs

Maintenance is priced as one fixed monthly fee for the agreed scope, and we do not publish a band. The fee follows from the system itself: how much the software does and how many outside services it depends on, how far its dependencies have fallen behind, the severity commitments written into the contract, and how much improvement work each month is meant to carry.

Software we built can be quoted from what we already know about it. For code another team wrote, the paid audit comes first, and its findings set the fee. WordPress speed work is priced on its own as a fixed-price project. Describe the system and what it connects to, and you will hear back within one business day.

Price a maintenance retainer

Maintenance, modernization, or a rebuild?

Maintenance is the right purchase while the system still fits the business and the cost of keeping it current stays predictable. The signal to stop is when each month's patching buys less time than the last: a framework with no supported upgrade path, or a core process nobody dares change. That calls for legacy modernization, which replaces a system in phases while the old one keeps running.

A marketing site that needs a new design, or a WordPress install moving to another platform, is project work for a custom web development company, and we are one. A product still finding its first users is better served by our MVP development services, where the code is expected to change every week. A subscription product with a long roadmap usually needs the build capacity behind our SaaS development services. New logged-in business software, such as portals and internal tools, is web application development. Once any of those is live, it comes back here.

An online store that runs well and is not being found in search is a different job again, and that one is our ecommerce SEO services.

Describe your system Book a 30-min call