Guide: Life After Go-Live and Sustainability

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

Most software projects are planned carefully right up to go-live day; everything after that is left to the sentence "we'll call if we need to". Yet both the real cost and the real risk of a system emerge after delivery. This guide explains, in plain language, the three contract models that govern life after go-live, the differences between them and the questions to ask before you sign. The aim is not to sell you a package; it is to show you clearly which model suits your business, what can be committed to and what cannot.

Request a proposal or discovery call → +90 543 930 12 72

3 modelsThree distinct contract structures for life after go-live

2 conceptsResponse time is committed to; resolution time is targeted

10 questionsTo ask before signing a maintenance contract

The framework first

The project ends, the system begins

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.

Let us set out 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.

Three models

The three contract structures for life after go-live, and combining them

Their names sound alike, so they are often confused; yet the three make different promises. Expecting one to deliver another's promise is the classic source of the disputes that arise after go-live.

Annual maintenance and support contract (reactive)

Its purpose is to keep the system running: intervention when a fault appears, security updates, keeping the components used and the integrated systems version-compatible, compliance with regulatory changes, and regular checks on backups and restores. In the market these contracts are usually split into tiers with names such as basic, standard and priority line; the difference between tiers is essentially the support channel, the working hours covered and the priority level during an incident. In classic maintenance contracts, new feature development is mostly out of scope; some contracts include a limited allowance for small enhancements. The contract itself is what decides: whether small enhancements are included, and if so what the monthly limit is, must be in writing.

Monthly engineering capacity retainer (proactive)

This is not a scope contract but a capacity contract. What will be done is not listed up front; a fixed amount of engineering time is set aside each month and the business decides where that time goes. A new report, an extra screen, a process change, integration maintenance, a performance improvement or clearing technical debt all come out of the same pool. Whether unused time carries over, the carry-over cap, the overage rate and the format of the monthly report are each defined in the contract.

On-demand work (no contract)

No contract is set up; each need is priced as a separate job and worked at an hourly rate. At first sight it is the most flexible option, but the unit rate is usually higher and the work is open to delay because it has to fit into the gaps in a planned schedule. That is not a penalty but a matter of planning: contracted work reserves its place in the schedule in advance, while uncontracted requests only join the queue when the schedule opens up. On top of that, the context of the system has to be rebuilt with every request, and that time is charged to the job as well. Reasonable for businesses with a small request a few times a year; risky for those where production continuity is critical.

Using two together

In businesses that have regular monthly requests and also carry downtime risk, a maintenance contract and a small monthly capacity can be set up together: maintenance keeps the system running, capacity keeps it developing. If the flow of requests is sparse, maintenance alone is enough. If you take both, it is important to keep the boundary between the two budgets clear; charging a fault fix to capacity hours, or booking a new piece of development as though it were within maintenance scope, destroys both parties' trust in the numbers at month end.

Comparison

The three models side by side

The table below shows how the three models differ against the same criteria. When you request proposals, ask the supplier to fill in each of these rows from its own contract text; look for a written answer, not a verbal explanation.

Criterion	Annual maintenance and support	Monthly capacity retainer	On demand (no contract)
The essence of the contract	Keep the system running; intervene if a fault appears	Set aside a defined amount of engineering capacity each month	No contract; each job priced separately
Approach	Reactive: steps in once an incident occurs	Proactive: planned improvement and development is carried out	On demand: only when a request comes in
Response and intervention	Committed in hours in the contract	Planned through the monthly work schedule, on top of the support level	No commitment; depends on the team's availability at the time
Prioritisation	Set by the support level defined in the contract	The business sets the priorities within the month's hours	Planned as the schedule opens up; no place reserved in advance
New development	Usually out of scope; a limited small-enhancement allowance may be defined, and must be in the contract	This is the scope itself	Repriced and replanned with every request
Price predictability	High: a fixed annual fee that goes into the budget in advance	High: a fixed monthly fee, with the overage rate known in advance	Low: spending cannot be predicted, and the unit rate is usually higher
Reporting	Fault records, intervention and resolution records	Monthly capacity report: how much time went to which job	Output per request; no consolidated picture emerges
Continuity of knowledge	The team knows the system and a record history builds up	The team stays inside the system and the context is not lost	Context is rebuilt with every request, and that time is spent too
Who it suits	Businesses with settled processes, a slow rate of change and critical continuity	Businesses whose system keeps developing and that have regular monthly requests	Set-ups with a small request a few times a year and low downtime risk

The most critical distinction

Is it response time or resolution time that is being committed to

The most common confusion in maintenance contracts is this: the customer believes a resolution time has been committed to, while the contract commits to a response time. They are different things, and not knowing the difference turns into an argument in which, at the moment of a fault, both sides feel they are in the right.

Response time is the period between your notification arriving and the issue being logged and an engineer actually starting work on it. It is measurable, controllable and therefore something that can honestly be committed to. It should be written in hours in the contract, along with the channel (telephone, email, ticketing system) and the working hours covered.

Resolution time is the period until the problem is permanently fixed, and it is not under one party's control alone. If the fault lies in the software's own code, it is predictable; but if its source is a version change at your ERP supplier, an e-invoicing provider's service, the network infrastructure or hardware, or a corrupted data set, then committing up front to when the fix will be complete is technically impossible. Where a contract does commit to a firm resolution time, you should expect that commitment to be bounded by exception clauses; when reading the contract, assess the commitment sentence and the list of exceptions together.

An honest contract writes three things separately at this point: it commits to a response time in hours; for resolution it commits to a target time together with a workaround and a regular update interval; and it lists the dependencies outside its control openly. That leaves nothing to argue about when a fault occurs.

The second detail bound up with this is fault classification. The definitions of critical, high and normal should be written into the contract, and it should state who decides which class a fault falls into. A complete production stoppage and a single report adding up incorrectly should not fall into the same class; but nor should the supplier be expected to make that judgement alone in the middle of an incident.

How it works

How a capacity retainer works in practice

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.

Before you sign

10 questions to ask before signing a maintenance contract

Every one of the questions below should have an answer in writing. A verbal assurance is worth nothing at the moment of a fault. We recommend taking this list into the proposal review meeting and ticking off the items one by one.

Is it response time or resolution time that is being committed to? If both are given, which target applies to which fault class, and are those times written in hours in the contract?
How long is the warranty period and what does it cover? Is the boundary between faults fixed under warranty and faults covered by maintenance in writing; when does the warranty end and paid maintenance begin?
Are restores from backup rehearsed? Seeing that a backup was taken is not enough; is it tested and recorded at set intervals that the system can genuinely be brought back up from that backup?
Are evenings, weekends and public holidays inside or outside the scope? If outside, how is a call raised in an emergency and how is it charged?
Are version upgrades included? Is the compatibility work arising from version changes in the operating system, the database, libraries and integrated systems within maintenance scope, or counted as separate work?
Are small enhancements included in the scope? Is a new report, an extra field or a minor screen change covered by the maintenance fee; if so, is the monthly limit in the contract, and if not, is the unit rate?
Do I have access to the source code, and how does handover work if the contract ends? Which repository does the code sit in, do I hold the access rights, and are the documents to be handed over, a working build environment and the handover period defined in the contract?
How is out-of-scope work priced? Are the unit rate, the estimating method and the approval process written down up front, or is every request negotiated afresh?
Where are fault records kept? Is there a ticketing system in which notifications, interventions and resolutions can be traced, and do you have access to those records too?
Who is responsible for third-party dependencies, and how many people on the maintenance team know this system? Who coordinates faults originating with the ERP supplier, the e-invoicing provider or the hosting provider; support that rests on a single person does not remove key-person risk, however firmly the contract is signed.

The Pan approach

How Pan Innovation House sets up life after go-live

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 entire source code of every system we build stays with the client. The code is yours while the contract runs and after it ends; continuing with us should be a choice, not an obligation. We do not accept the idea that a system can only be sustained by remaining at the mercy of its supplier.

Our principle of working without touching your existing ERP applies after go-live too. In a business running Logo, Mikro, Netsis, Canias or SAP, the layer we write runs alongside the ERP; it does not alter its tables or disturb its own design. Our aim is that your ERP supplier's support scope and our work do not collide; because the ERP's own tables and design are untouched, the boundaries of intervention stay separate. Even so, the final word rests with the terms of your own ERP contract; we check that clause together with you before going live. In a business running Netsis, we worked on a layer that runs alongside the ERP without touching it at all.

We also write down what we do not know. In the reverse engineering of an enterprise application we examined, we fully worked out the daily calculation layer; we could not reach the bodies of the six database objects (five functions and one stored procedure) on which the same system's monthly layer depends, and rather than present that as closed we marked it in the report as missing. In another system we reconstructed database objects whose source could not be found and put the result through an independent audit, preserving the distinction between the contract and the body. 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.

Frequently asked questions

The questions we hear most

What exactly does a software maintenance contract cover?

A classic annual maintenance and support contract aims to keep the existing system running: responding to fault reports, security updates, keeping the components used and the integrated systems version-compatible, compliance with regulatory changes, and regular checks on backup and restore processes. New feature development is mostly out of scope; some contracts include a limited allowance for small enhancements. The contract text is what decides: whether small enhancements are included, and if so what the monthly limit is, must be in writing. When you assess a proposal, reading what the scope leaves out is more informative than reading what it includes.

What is the difference between response time and resolution time?

Response time is the period between your notification arriving and the issue being logged and an engineer actually starting work on it; because it is measurable, it can be committed to in hours. Resolution time is the period until the problem is permanently fixed, and it is not always under one party's control. If the source of the fault is a version change at the ERP supplier, an integrator's service, the network infrastructure or hardware, giving a firm resolution time is technically impossible. An honest contract commits to a response time and, for resolution, defines a target time together with a workaround and a regular update interval.

What determines the maintenance fee?

The fee is driven by the complexity of the system, the number of integrations, the working hours covered, the response time committed to and the cost of the business stopping during a fault. A figure given before those variables are clear will either be higher than it needs to be or impossible to hold to in practice. The bands quoted in the market are explained in detail, alongside the other elements of total cost of ownership, in our custom software pricing guide; we recommend using that page as your basis when budgeting the maintenance line.

What is the difference between a maintenance contract and a capacity retainer?

A maintenance contract is reactive and concerns preserving existing behaviour: it steps in when something breaks. A capacity retainer is proactive and concerns keeping the system developing: a fixed amount of engineering time is set aside each month and the business decides where that time goes. The first is a scope contract, the second a capacity contract. In a business with settled processes and a slow rate of change, maintenance alone may be enough; in one with regular monthly requests that also carries downtime risk, setting up both together is worth considering.

Do unused hours expire in a capacity retainer?

That depends entirely on how the contract is written, and it is a clause to settle before signing. Three approaches are seen in practice: unused time does not carry over at all, it carries into the following month up to a certain cap, or it accumulates but remains valid only for a limited period. The same clause should also state the overage rate: what unit price applies to work arriving once the monthly capacity is used up, and whether overage requires prior approval. If those two rules are not in writing, a dispute at month end is inevitable.

Could I just skip the contract and call you when I need something?

You can, but it should be a choice made in full knowledge of the consequences. On-demand work is the most flexible option at first sight; on the other hand the unit rate is usually higher, and the work is open to delay because it has to fit into the gaps in a planned schedule. That is not a penalty but a matter of planning: contracted work reserves its place in the schedule in advance. On top of that, the context of the system has to be rebuilt with every request, and that time is charged to the job as well. It is a reasonable choice for a set-up with a small request a few times a year and low downtime risk; it is risky for a factory where production continuity is critical.

What happens to my system, my data and my source code if the contract ends?

In the systems we build, the entire source code stays with the client from the outset; the contract ending does not change that. Our handover file standard also means that installation steps, dependencies, configuration, known risks and a working build environment are put in writing. The aim is that a team other than ours can sustain the system. We recommend asking every supplier about this clause when you assess proposals: if the handover process, the documents to be delivered and the handover period are not defined in the contract, a maintenance contract turns over time into a hidden dependency contract.

Let us start together

Let us set up life after go-live with a written framework, not guesswork

Whether your existing system was built by us or taken over from another team, a short assessment lets us set out in writing which model suits you, what the scope includes and excludes, and which items will be priced separately. We do not propose scope you do not need; if all you require is a few small requests a year, we will say so plainly.

+90 543 930 12 72 Request a discovery call →