Application Maintenance and Support

Application maintenance for live software your team still depends on.

We take over applications we built and inherited codebases, establish how production actually runs, and provide bounded support for incidents, defects, security patches, dependencies, and small changes. The onboarding audit comes before an SLA so response promises match the system and access available.

From 2 hours Critical response option1 to 2 weeks Inherited-code onboarding10 to 40 hours Bounded monthly support

The problem

Sound familiar?

  • Is a live application owned by a departed developer or an agency that no longer responds?

  • Are incidents, vulnerable dependencies, backups, and production changes handled without a current runbook or accountable owner?

Short answer

Application maintenance and support keeps live software operable through incident response, defect fixes, security patches, dependency updates, monitoring, runbooks, and bounded small changes. RaftLabs supports applications it built and inherited codebases after a 1 to 2 week onboarding audit. Retainers typically cover 10 to 40 hours monthly, with critical response available from two hours.

The application still ran. Its operating knowledge had left.

A production defect returned, the last maintainer was gone, and nobody knew whether the fix belonged in code, data, infrastructure, or a vendor integration. Context was gone. Maintenance begins by rebuilding that context before promising how quickly an incident can be handled.

Support terms after onboarding

From 2 hours
critical incident response option
Coverage and severity agreed in the service schedule
1-2 weeks
inherited-code onboarding audit
Access, build, operations, risk, and baseline
10-40 hours
typical monthly capacity
Sized to the application and support model

RaftLabs does not publish a standalone maintenance outcome case. These are service parameters, not promises that every incident will be resolved within a fixed time. The onboarding audit determines whether the application is observable, buildable, deployable, and supportable enough for the requested coverage.

Use maintenance support when a real production application needs accountable ongoing care.

Complete onboarding before agreeing response terms, especially for inherited code and infrastructure.

A fit
01

The application has active users, business value, and a named owner for priorities and access.

02

Repositories, environments, vendors, and production signals can be made available safely.

03

The need is incidents, defects, patches, dependencies, monitoring, and bounded small changes.

Not a fit
01

The product is not live and the need is first-version development.

02

The codebase needs a major rewrite, replatform, or migration before routine support.

03

The buyer expects guaranteed resolution without access, observability, or an agreed support window.

Maintenance, modernization, or feature delivery

EngagementBest fitBoundary
Maintenance and supportOperate and improve a live application within bounded capacityCoverage, severity, access, backlog, and small-change limit
Legacy modernizationUpgrade runtime, architecture, framework, cloud, or platformMigration plan, compatibility, parallel run, and rollback
Feature projectDeliver a defined new product capabilityScope, acceptance, release, and separate project capacity
Dedicated teamSustain a larger evolving roadmapTeam ownership, prioritisation, delivery cadence, and governance

Scope

What belongs in an application support baseline

  • 01
    Codebase and environment onboarding
    Reproduce builds and deployments, map repositories, environments, configuration, infrastructure, vendors, and owners.
  • 02
    Incident and defect response
    Classify impact, collect evidence, mitigate safely, investigate cause, test fixes, communicate status, and record follow-up.
  • 03
    Security and dependency maintenance
    Review supported versions and vulnerabilities, plan upgrades, test compatibility, stage changes, and document residual risk.
  • 04
    Observability and runbooks
    Establish health, logs, alerts, escalation, deployment, rollback, backup, restore, and common-incident procedures.
  • 05
    Bounded change and reporting
    Deliver approved small changes within capacity and report incidents, changes, backlog, risk, usage, and recommended projects.

How it works

From inherited codebase to support baseline

  1. Phase 1
    01

    Establish access and service context

    Map users, business criticality, environments, repositories, infrastructure, vendors, data, current incidents, owners, and coverage needs.

  2. Phase 2
    02

    Audit code, operations, and risk

    Reproduce builds, inspect dependencies and observability, verify backups and deployment, review known defects, and rank stabilisation work.

  3. Phase 3
    03

    Create the support baseline

    Fix agreed blockers, document runbooks and escalation, establish monitoring, change flow, severity, response, maintenance plan, and backlog.

  4. Phase 4
    04

    Operate and review

    Triage incidents, deliver approved maintenance, record changes, report risk and capacity, and separate larger projects before work starts.

Risk

What the support agreement must settle

Coverage and severity
Define support hours, holidays, critical impact, response clock, contacts, communication cadence, and escalation.
Access and change authority
Approve repositories, environments, production data, vendor accounts, deployments, emergency change, and rollback.
Capacity boundary
Separate included maintenance and small changes from larger features, migrations, and remediation projects.
Recovery evidence
Verify backups, restore, deployment, rollback, monitoring, and runbooks rather than assuming they work.

Scope and price

Application maintenance retainers start at £1,500 per month.

Complete the inherited-code onboarding audit before SLA and monthly capacity are finalised.

£1,500-£4,000 monthly

Typical retainers cover 10 to 40 hours. An inherited-code audit usually costs £2,000 to £5,000 and takes 1 to 2 weeks. Larger upgrades and features are separate.

Modernization is scoped separately when the application needs a major runtime, framework, architecture, or cloud change.

SLA after evidence

Response terms follow a review of access, monitoring, build, deployment, escalation, and recovery, not a sales-call assumption.

Large work stays visible

Major upgrades, migrations, refactors, and features receive a separate scope before capacity is consumed.

Related enterprise-system services

Stay on topic

More on custom software

Dealer Management System Development

Work with us

Dealer Management System Development

See the service
Try it yourself

Try it yourself

Build vs Buy Calculator

The real cost of building in-house (most teams miss 40%).

Open the free tool
Junk Removal Software Development: Build vs. Buy for Multi-Truck Operators

Article

Junk Removal Software Development: Build vs. Buy for Multi-Truck Operators

Jobber and Hauler Hero work fine at one or two trucks. At five trucks across multiple markets, the gaps in off-the-shelf tools start costing real money. Here is what multi-truck junk removal operators actually need from custom software and when building makes financial sense.

Read more
Custom software development statistics: 40+ data points (2026)

Article

Custom software development statistics: 40+ data points (2026)

The custom software market will exceed $146B by 2030. Here are 40+ sourced statistics on market growth, project success rates, ROI, team sizes, and technology trends.

Read more
Dental Practice Management Software: When to Build vs. Buy (And What It Costs)

Article

Dental Practice Management Software: When to Build vs. Buy (And What It Costs)

Dentrix charges $500-$800 per provider per month. A 20-chair DSO pays up to $192K per year for software it cannot modify. Here is when building your own dental practice management software makes financial sense, what it costs, and what breaks if you rush it.

Read more

Application maintenance questions

Yes, after an onboarding audit. We need repository, environment, infrastructure, vendor, monitoring, deployment, and business-owner access sufficient to reproduce and support the application. If the code cannot build or production cannot be observed safely, stabilisation comes before a response SLA.

The agreement may cover incident triage, defects, security and dependency updates, monitoring, runbooks, backup checks, operational reviews, and bounded small changes. Coverage, hours, environments, support window, exclusions, approval, and unused capacity are written into the service schedule.

Critical response can start from two hours after onboarding, depending on coverage hours, access, monitoring, escalation contacts, and application risk. Response means an engineer has acknowledged and begun triage; it is not a guaranteed resolution time. Severity and communication rules are agreed before service starts.

Small supported upgrades may fit the retainer. Runtime migrations, major framework upgrades, architecture changes, cloud moves, and large refactors are scoped as separate modernization projects because they need discovery, acceptance, rollback, and capacity beyond routine support.

A basic retainer commonly runs £1,500 to £4,000 per month, often covering 10 to 40 hours depending on the application and SLA. An inherited-code onboarding audit typically runs £2,000 to £5,000 over 1 to 2 weeks. Larger upgrades and features are priced separately.

Work with us

Bring the production application nobody fully owns.

Share the stack, repository, environments, hosting, current incidents, user impact, access, support window, and prior runbooks. We will identify the onboarding and stabilisation needed before an SLA.

  • Scope and cost agreed before work starts. No surprises. No obligation.
  • Working prototype within 3 weeks of kickoff.
  • Pay by milestone. You see progress before each invoice.
  • 60-day post-launch warranty. Bug fixes, UI tweaks, and deployment support. No retainer.
  • All conversations are NDA-protected.