Written by:
Last Published:
11 August 2026
•
The short version:
Most digital products do not need a full-time support team after launch. They need a small, named team on a retainer that watches the system during business hours, fixes what breaks, and ships planned improvements in scheduled blocks. Budget 10-20% of the build cost per year to keep the product running, and budget separately for the work that makes it grow. This guide sets out what that maintenance covers, what it costs, and how to contract it.
A digital product is software your customers use or buy directly: a web application, a mobile app, a platform, an API, a subscription service, or a downloadable asset such as a template, a course or a report. Nothing physical changes hands. But there are still servers, dependencies, browsers, app stores, payment providers and security advisories underneath it, and all of them keep changing whether or not anyone touches your code.
That is the difference that catches product owners out. A physical product is finished when it ships. A digital product is more like a boat in the water: the hull needs scraping on a schedule, a leak needs plugging the day it appears, and a bigger sail is a project of its own. Launch day is when it goes in the water, not when the work stops. If you sell digital products, or run one as the engine of a service business, that is the day the running costs start.
Whenever a digital product goes live, product owners worry about how it will be maintained. It is a common concern, and a justified one. This is the point in the life cycle where the product needs the most support, and it is also the point where the engineering and design team phase out, because keeping the full team assigned is not economically viable.
So both sides get a problem. The product owner loses the team that holds the context, so nobody who knows the system is free when something urgent lands. The agency inherits regular, unplanned support requests that arrive while the same people are working on other projects. Context switching under firefighting conditions, deadlines slipping on the new work, and two products suffering instead of one.
What you want instead is a balanced arrangement: product owners get a team in times of need, and project teams are not constantly interrupted after a project phases out. To design that, you need to know what actually has to happen once a product is delivered.
Several tasks have to be executed once a product is live and in what is called the maintenance phase. Understanding the nature of these tasks is crucial, because each type is bought, scheduled and priced differently. They are usually organised as follows:
This split is not something we invented. ISO/IEC/IEEE 14764:2022, the international standard for software maintenance, formalises post-delivery work into four categories: corrective, adaptive, perfective and preventive. Our three-line model maps onto it directly. Preventive stays preventive, corrective stays corrective, and we group the two enhancement types, adaptive and perfective, into a single line we call evolutive, because commercially they are bought and scheduled the same way.
The research behind the standard is consistent on one point that surprises most product owners: the majority of maintenance effort goes on enhancement, not on fixing defects. In the classic survey by Lientz, Swanson and Tompkins, perfective work, meaning enhancement, alone accounted for around 60% of maintenance effort, while corrective bug-fixing was under a fifth. The finding has been replicated repeatedly since.
At Imaginary Cloud we run these three types as three separate lines in what we call a three-line retainer: one contracted line each for preventive, corrective and evolutive work, priced and scheduled independently rather than drawn from a single pool of hours.
Why split them? Because the three behave differently. Preventive work is predictable and can be scheduled. Corrective work is unpredictable and needs a response commitment. Evolutive work is planned like any other project. In our experience, an undifferentiated pot of hours is the usual reason a maintenance budget runs out early in the year: one incident in the first quarter eats the hours meant to cover twelve months of patching, and the planned improvements are the first thing to go.
In any of the situations that fall under preventive and corrective maintenance, the product owner needs a team to deal with existing issues. But the majority of digital products do not need a team working 24/7. What they need is a team that keeps an eye on the system and intervenes when it fails. With the proper measures in place, modern infrastructure is stable enough that support during business hours is sufficient for most products.
The time dedicated to maintenance is usually contracted via a retainer: a fixed monthly fee that reserves an agreed block of a named team's time, whether or not you use all of it that month. You are paying for availability and retained context as much as for hours. To make that efficient, the team keeps an eye on several products at once and runs standardised processes for services such as server monitoring and security patching.
In some cases you do need 24/7 support, and that is a different service entirely. Expect to pay a premium, usually to a company dedicated to maintenance contracts, because it requires rota staffing and escalation procedures that only work at a much larger scale.
The corrective line is where response times get agreed, and vague language here is what causes conflict later. A workable service level agreement states three things for each severity of issue: how quickly someone acknowledges the report, how quickly work starts, and what the target is for a fix or a workaround. A common structure for a business-hours retainer looks like this:
| Severity | Example | Acknowledgement | Target resolution |
|---|---|---|---|
| Critical | Product down, checkout failing, data at risk | Within 1 business hour | Same business day, workaround first |
| High | Core feature broken for many users | Within 4 business hours | Next business day |
| Medium | Non-critical defect, workaround exists | Within 1 business day | Next scheduled release |
| Low | Cosmetic issue, minor content change | Within 2 business days | Batched into planned work |
Agree the definitions of each severity before you sign, not during your first incident. Agree who is allowed to declare a critical issue. And agree what happens to the month's planned work when one is declared.
Business-hours support only works if the system tells you it is in trouble rather than waiting for a customer to. A workable monitoring baseline covers uptime and endpoint checks, error tracking with alerting, log aggregation, infrastructure metrics such as CPU, memory and disk, database performance and slow queries, backup verification with a tested restore, and dependency and vulnerability scanning against public advisories such as the National Vulnerability Database and the guidance published by OWASP.
That last one is what turns preventive maintenance from a calendar exercise into a real safeguard. When a vulnerability is disclosed in a framework you depend on, the question is not whether you will patch it. It is how many days pass before you know it exists.
Evolutive maintenance is mostly about business growth and service improvement, and it can be planned and executed in a timely manner. Put a list of tasks together, then ask your technology partner to assemble a team and deal with it in a couple of sprints: fixed blocks of development work, typically one or two weeks each, with an agreed scope at the start and a release at the end.
Keeping evolutive work in its own line, in scheduled sprints rather than trickling through the support channel, protects both sides. The product owner gets a predictable release cadence and a visible cost per block. The team gets to plan its capacity, which is another way of saying nobody is pulled off another project at half a day's notice. See Waterfall vs Agile: when to use each for how the two planning styles compare when you are structuring those blocks.
This is also where growth work lives. Re-architecting a product so it can carry more users is a classic evolutive project: we rebuilt GoodBarber's app-building experience on a more scalable architecture in exactly this way, which you can read about in the GoodBarber Composer case study.
The single biggest driver of evolutive cost is not the size of the feature. It is how hard the existing codebase is to change. That difficulty has a name, technical debt, and left unmanaged it quietly inflates every enhancement you ship. Robert Glass made the same point decades ago: the dominant task in maintenance is understanding the existing product before you can safely touch it.
The way to keep that cost visible is to measure it. A periodic code audit that scores maintainability, complexity and test coverage tells you where the debt sits before it derails a release. We produced pseudocode documentation of 195 templates for GoodBarber, described in the code standardisation case study, so they could make architectural decisions on evidence rather than guesswork ahead of a major rebuild. For the wider picture, our guide on how to manage technical debt sets out the practical options.
Digital products are not one thing commercially. The way yours makes money decides how much downtime costs you, how fast you have to patch, and which of the three lines carries the weight. Five shapes cover most of the market.
The practical use of this list is sizing. Work out what an hour of downtime costs in your model first, then buy the retainer that matches it. A marketplace at transaction volume and a template shop with fifty sales a month are both digital products, and they should not be buying the same support.
The instinct after launch is to size the team for the worst month. That is what makes maintenance look unaffordable, and it is the wrong calculation, because the worst month is not the average month.
For most products in their first year, a workable shape is a fractional team rather than a dedicated one: a part-time engineer who holds the product's context, a part-time DevOps or platform engineer covering infrastructure and monitoring, and access to a designer and a lead for evolutive blocks. That is a fraction of a full-time equivalent in cost, and it beats one dedicated junior on availability, because it covers holidays, illness and the specialisms a single person will not have. When a product does have its own squad, an embedded model works well too: we joined AppTweak's team as an integrated frontend unit, following their own processes. Three contract models cover almost every situation:
| Model | What you get | Best for |
|---|---|---|
| Business-hours retainer | Fixed monthly fee, agreed block of hours, response commitment in working hours. Unused hours typically capped, not banked. | Most products; the model the three-line retainer is built for |
| Time and materials | Pay for what you use, no availability guarantee. Cheapest on paper, most expensive during an incident, because you join the queue. | Internal tools, low commercial exposure |
| 24/7 or extended cover | Rota staffing, on-call escalation, premium pricing. | Transactional platforms, regulated or safety-critical services |
Decide which one you are buying by asking what an hour of downtime costs you, not by asking what the retainer costs. Businesses that sell digital products continuously, rather than in project cycles, almost always find the retainer is the cheaper number.
Across the products we deliver and then support, preventive and corrective maintenance runs at 10-20% of the original build cost per year, and that is the range we budget with clients. It sits comfortably with the wider research on software life-cycle costs: Robert Glass puts maintenance at 40-80% of total life-cycle cost, averaging 60%, in Facts and Fallacies of Software Engineering (2002), which is more, over a product's life, than the original build.
In practical terms: a product that cost £150,000 to build should be budgeted at roughly £15,000 to £30,000 a year to keep running, before any new features. Where you sit in that range depends on the commercial model above, the number of third-party integrations, and how much of the stack you control.
Evolutive maintenance sits outside that figure, because it is tied to how much the product will grow. Treat it as a separate budget line, the third line of the retainer, and size it against your roadmap rather than the build cost. A product in an active growth phase can easily spend more on evolutive work in a year than the preventive and corrective lines cost together.
Two costs are routinely left out of the first budget and then arrive anyway: third-party services (hosting, monitoring, error tracking and any paid APIs), and the app-store and compliance overhead of keeping a mobile product publishable as the platforms change their requirements.
Work on the answers from day zero with your software development partner. Be open about your concerns, and set out in the contract what happens when something goes wrong rather than assuming goodwill will cover it. That avoids the situation where, after launch, you end up with a problem that cannot be solved without conflict, and when that happens, the first to suffer are your users, and in consequence your business.
Something customers use or buy without anything physical changing hands: a web or mobile application, a platform, an API, a subscription service, or a downloadable asset such as a template, course or report. All of them depend on infrastructure, third-party services and code libraries that keep changing, which is why every digital product carries a running cost after launch.
Budget 10-20% of the original build cost per year for preventive and corrective maintenance. A product that cost £150,000 to build sits at roughly £15,000 to £30,000 a year. Evolutive maintenance, meaning new features and growth work, is budgeted separately against your roadmap.
Most do not. With monitoring, alerting and a business-hours retainer in place, the majority of products are adequately covered. Round-the-clock cover is justified when an hour of downtime carries a direct revenue, regulatory or safety cost, and it is usually bought from a company dedicated to maintenance contracts.
The work that improves or extends a live product rather than keeping it running: new features, performance rewrites, added capacity, integrations. It maps to what ISO 14764 calls adaptive and perfective maintenance, is released in sprints like any other development work, and should be contracted and budgeted separately from support.
Preventive maintenance is scheduled work that stops failures happening, such as applying security updates and renewing certificates. Corrective maintenance is the reactive work after something has already broken, such as restoring a failed server. Preventive work is predictable and plannable; corrective work needs a response-time commitment.
A named team, an agreed monthly block of hours, response and resolution targets by severity, a defined monitoring and alerting setup, a patching cadence, and a stated process for what happens to planned work when a critical incident is declared, including who can declare one.
Less engineering than a SaaS product, but the commercial surface still has to be maintained: checkout, payment-provider integrations, licence delivery, file hosting and access control. Most of the risk sits in the preventive line, because the parts most likely to break are third-party services changing on their own schedule.
You can, and it makes sense once the product is large enough to keep a full-time team genuinely busy. Below that point, a fractional team on a retainer covers holidays, illness and specialisms a single in-house hire cannot, usually for less than one full-time salary.
If your product is close to launch, or already live and being supported informally, it is worth putting the arrangement on a proper footing before the first incident does it for you. Our team can review your current setup and propose a retainer shape that fits the product's actual risk rather than the worst case.
Talk to us about post-launch support and we will walk you through what your product needs and what it should cost. You can book a call here.
CEO @ Imaginary Cloud and co-author of the Product Design Process book. I enjoy food, wine, and Krav Maga (not necessarily in this order).
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
.webp)
