Contents

Post-launch support for a website or app usually costs 15–25% of the development cost per year — our own benchmark; the exact figure depends on product complexity, the number of integrations and how quickly incidents must be handled. Support covers monitoring, updates and security fixes, bug fixing, infrastructure and small improvements.

Here is what drives the cost, which pricing models exist and where you should not cut corners.

What does product support include?

Support includes everything needed to keep a product running reliably and securely: health monitoring, dependency updates, bug fixes, backups and small changes. Growth work — new features and major changes — is usually priced separately.

A baseline support scope:

  • monitoring and incident response — the site is up, errors are visible, someone owns incidents;
  • security updates — framework, libraries and server operating systems;
  • fixing bugs reported by users or monitoring;
  • infrastructure — servers, backups and restore checks, certificates, domains;
  • small improvements — copy, settings, minor UI changes;
  • advice — answering business questions about what the system can do.

Why is support needed if everything works?

Support is needed because the product lives in a changing environment: security updates are released, third-party APIs change, browsers and mobile systems evolve, data and load grow. A site nobody updates does not stay the same — it gradually becomes vulnerable and breaks.

What happens without support:

  1. Known library vulnerabilities pile up and the site becomes an easy target.
  2. An external service — payments, CRM, delivery — changes its API and the integration stops working.
  3. A certificate expires or the disk fills up, and the site goes down over the weekend.
  4. An upgrade postponed for years turns into a major rewrite project.

What drives the cost of support?

The cost is driven by the volume of routine work, the required incident response time and infrastructure costs. The strongest factor is not code size but how much the business depends on the product being available every minute.

Factor How it affects cost
Product complexity More modules and roles mean more updates and checks
Integrations Every external system is a source of change and failure
Response time 15-minute response around the clock costs more than next-business-day
Code condition Old code without tests is more expensive and riskier to update
Load and data Data growth requires optimisation and scaling
Security requirements Payments and personal data mean more audits and updates

A screen showing a monitoring dashboard Photo: Unsplash

Incident response levels

Response levels are usually set in the contract as an SLA — a service level agreement. An example split by severity:

Critical — site down, payments failing           response within 1 hour, 24/7
High     — an important feature is broken        response within 4 hours, business hours
Medium   — a bug with a workaround               response within 1 business day
Low      — cosmetic issues, requests             scheduled

Which support pricing models exist?

Support is paid in three main ways: a fixed monthly bundle of hours, hourly billing for actual work, and a dedicated specialist or team. The choice depends on how predictable the workload is.

How to choose:

  • A monthly bundle of hours (retainer) suits most products: a predictable budget and reserved people; unused hours sometimes roll over.
  • Pay as you go suits stable products with rare requests; the risk is slow response, since nobody is reserved for you.
  • A dedicated team fits when support is combined with active development and there is plenty of work every week.

We covered pricing models in general in fixed price vs Time & Materials, and how to read a work breakdown in how to read a software development quote.

How do you reduce the cost of support?

Support costs are reduced by decisions made during development: a standard stack, automated tests, documentation and deployment automation. A product that is easy to verify and update is cheaper for any team to support.

What works:

  1. Keep dependencies fresh with small, regular updates rather than once every three years.
  2. Automate deployment and rollback — manual deploys eat time and raise the risk of mistakes.
  3. Cover critical flows with tests: payments, sign-up, checkout.
  4. Set up error and uptime monitoring so you learn about problems before users do.
  5. Keep short architecture and deployment docs — they cut the time of every task.

Above all, do not save on backups and security updates. Their cost is small compared with the consequences of a data leak or data loss.

In short

  • Our benchmark is 15–25% of development cost per year; the exact figure depends on the product and response time.
  • Support means monitoring, security updates, bug fixes, infrastructure and small improvements.
  • Without support a product gradually becomes vulnerable and breaks as the world around it changes.
  • A monthly bundle of hours with a severity-based SLA suits most products.
  • Products with a standard stack, tests, docs and automated deploys are the cheapest to support.

FAQ

  • Can a different team support the product than the one that built it?

    Yes, provided there is access to the code, infrastructure and documentation. A new team needs time to get up to speed, so a handover with an overlap period works best.

  • Is hosting included in the support fee?

    Usually not: servers and cloud services are paid separately, ideally directly from the company's account. Support covers the work of configuring, updating and monitoring them.

  • What happens if we drop support altogether?

    The product will keep running for a while, but risks will grow: vulnerabilities, broken integrations, unexpected outages. When a problem does hit, an emergency fix costs more than regular support would have.