Software maintenance, support and a capacity retainer: the guide to what happens after the project

A software project's contract ends at delivery; the system's life begins there. An application that works correctly on the day it goes live will degrade over time even if nobody touches it, because its surroundings never stand still: operating systems and browsers move up a version, security vulnerabilities are announced in the libraries it uses, the ERP you are integrated with moves to a new release, your e-invoicing or courier provider changes its interface, regulation makes a new field mandatory. The software stays the same; its world changes.

On top of that, the business itself changes. A new line is installed, a new customer wants a different report, a pricing rule changes, a department is restructured. In a manufacturing business, going a whole year without a single process changing is not a realistic expectation. So a system with no arrangement for life after go-live either falls out of use or becomes a burden that requires negotiation from scratch every time a need arises.

There are three ways to govern life after go-live, and they are not alternatives to one another but structures that solve different problems: the annual maintenance and support contract, aimed at keeping the system running; the monthly engineering capacity retainer, set aside to keep developing the system; and on-demand work, which proceeds job by job with no contract at all. The rest of this guide sets out the differences between the three, what each commits to and whom each suits.

Here is a framework on price as well. Market convention puts the annual maintenance and support fee at roughly 15-25 per cent of the project's one-off investment; for broad, heavily integrated contracts with high availability expectations, figures above that band are also discussed. That is market convention, not our price list; the real figure is calculated once the scope, support level and complexity of the system are clear. For the full set of cost items, see our custom software pricing guide.

The easiest way to understand a capacity retainer is to stop thinking of it as a scope contract. In a classic project contract, what will be done is written down up front and the fee is tied to it. In a capacity contract the fee is tied to the engineering time set aside; the business decides during the month which work that time goes to.

For this structure to work, four things must be clear in the contract. The first is the carry-over rule: whether unused time rolls into the following month, and if so what the cap is and how long it stays valid. The second is the overage rate: what unit price applies to work that arrives once the monthly capacity is used up, and whether overage requires prior approval. The third is the prioritisation method: how the request list is kept and how it is decided which jobs are queued at the start of the month. The fourth is reporting: whether you receive an auditable breakdown at month end showing how much time went to which job.

The strength of a capacity retainer is that small but continuous needs can be handled without going through a proposal process every time. Changing a column in a report, adding a step to an approval flow or updating a changed field in an integration all create waiting time and management overhead when priced individually. Done within a defined capacity, the same tasks become plannable.

The limits of the same structure should be stated just as plainly. A capacity retainer is not the right instrument for large one-off pieces of work. Developing a new module from scratch, a substantial data migration or rewriting a system cannot be managed soundly on either budget or timeline when squeezed into a monthly capacity. Work of that kind should be handled under a separate project contract, with capacity reserved for the continuous flow that sits outside the project.

For us a maintenance contract is not a way of holding on to a client but a way of keeping a system alive. That is why the source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. Continuing with us should be a choice, not an obligation.

Our principle of working without touching your existing ERP applies after go-live too. In a business running Logo, Mikro, Netsis, Canias or SAP (ERPs widely used in Türkiye), the layer we write runs alongside the ERP and connects to it through the routes its vendor supports (API, service layer or an approved import); it does not write directly into the ERP's database tables. Our aim is that your ERP supplier's support scope and our work do not collide. The final word rests with the terms of your own ERP contract; we check that clause together with you before going live.

We also write down what we do not know. Any part of a system that we could not verify or access is marked explicitly as "not verified" in the handover file, and is never mixed with verified information. The same principle applies in a maintenance relationship: we do not present unverified information as verified.

Our handover file standard is the guarantee of life after go-live. Installation steps, dependencies, configuration, known risks and a working build environment are all put in writing. The aim is that a team other than ours can sustain the system; without that document, a maintenance contract turns into a hidden dependency contract.

On price, we do not give a figure on this page. A maintenance figure quoted without knowing the complexity of the system, the number of integrations, the availability expected and the cost of the business stopping during a fault is either higher than it needs to be or too low to hold to. After a short assessment we set out in writing which model suits you, what the scope includes and excludes, and which items will be priced separately.