Skip to content
B2B platforms

What support for a system costs after launch and what it covers

The cost of supporting and developing a custom system after launch: 5–15% of the build cost a year for an accounting integration, 15–20% for a platform, 20–30% for SaaS. What support covers, how it differs from the warranty and how to pay for it.

By Nikolay Mazur · · 8 min read · Originally published in Russian: читать оригинал

Short answer: a live custom system costs roughly five to thirty per cent of its own build cost every year. Where inside that range yours lands depends on two things: how many external connections it has and how often the business around it changes. An exchange with an accounting system that nobody touches sits near the bottom. A SaaS product with paying customers and regular releases sits near the top. The vendor’s warranty is not part of this: it covers their own defects and ends after a few months.

We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.

Nobody talks about this spending at signing, although over five years it easily matches the price of the build itself.

Benchmarks by type of system

SystemPer year, as a share of the buildWhy
Accounting system integration5–15%Little code, but versions and the API on the other side keep moving
B2B platform, customer portal15–20%Hosting, updates, fixes, small changes
AI assistant15–20%Plus knowledge base updates and answer quality checks
SaaS product20–30%Constant releases, customers expect new features

The same proportions sit behind our per-direction breakdowns, for instance in what a B2B platform costs and what accounting integration costs.

Support per year as a share of the build cost: accounting system integration 5–15 per cent, B2B platform 15–20, AI assistant 15–20, SaaS product 20–30
The more external connections and releases, the more the year after launch costs.

What support covers

Infrastructure. Server, database, backups, certificates, monitoring. The most predictable part, and the one you can price exactly in advance.

Updates. Libraries and the operating system get security fixes. Skip them for a year or two and the update turns into a small project, sometimes into rewriting part of the system.

Fixes. Defects that surface after the warranty ends, and defects at the seams with other people’s systems. The second kind appears even when nobody has touched the code: a marketplace changed its response format, an accounting system received a configuration update.

Small changes. A new field on a form, a new report, one more role. These usually eat most of the support hours, because the business around the system keeps moving.

Large additions, such as a new module, are normally outside support and estimated separately.

Warranty and support

A warranty covers defects the vendor introduced and runs for a limited period after acceptance, most often three to six months. During that period the vendor fixes them at no charge. Which clauses to look for is in what to put in a development contract.

Everything else falls outside it: changes on the side of external services, new requirements, updates, running the server. So a support agreement is needed from the first day after launch. Wait for the warranty to expire, and the first breakage on a marketplace’s side turns out to be nobody’s job.

How to pay for support

A retainer with a block of hours. A fixed monthly sum covering infrastructure, updates and a set number of hours for fixes and changes. Convenient when changes are modest and regular. Unused hours usually expire, which is worth discussing.

Hourly, as used. Suitable when the system is stable and requests are rare. The drawback: an urgent task waits until the vendor has time.

A response time in the contract. For a system that sales or the warehouse cannot work without, the contract states how many hours before the vendor starts on an incident and during which hours they are reachable. The shorter that time and the wider those hours, the more support costs.

When support moves in-house

An in-house developer pays off when the stream of changes is enough for a full-time job. For a single mid-sized system that is rare: the person is busy for six months, then spends months on small items.

If that decision is taken, plan the handover in advance. It needs the source code, server access, deployment documentation and a few weeks where the new developer works alongside the outgoing vendor. Without that, the first months go on working out how the system is built.

Common questions

Can we do without support? Yes, if the system is connected to nothing and the business around it does not change. There are few such systems. Usually something at a seam with an external service stops working within six months of no updates.

Why is SaaS support more expensive? Paying customers expect new features and fast fixes, and every defect is visible to many people at once. Releases are continuous, which is closer to development carrying on than to support.

Is hosting inside those percentages? Yes, our benchmarks include hosting. If the system runs on your own server, the figure is lower by what that server costs you.

The rule

Ask what support will cost before you sign the development contract. Comparing vendors is fairer on the build plus the first three years taken together.

Facing a similar problem?

Tell us what you are building. We will walk through the architecture and give you a budget range in one call.