The bill that starts the day you launch
Most budgets stop at the build. The running cost is a permanent line, and leaving it out is how a working system quietly rots.
Plan for an annual running cost that is a meaningful fraction of the build, not a rounding error, and treat it as five separate lines rather than one. A system with no running budget does not stay still, it degrades, because the world around it keeps moving.
Software does not sit still
Nothing about a finished system stays finished. Payment providers change their integrations, browsers change what they allow, dependencies publish security updates, tax rules change, and the business changes what it sells.
A budget that funds the build and nothing after it is not saving money. It is deferring a cost until the point where it arrives as an emergency, which is the most expensive way to buy anything.
The five lines every annual budget needs
Split them, because they behave differently and one of them is always the one that gets cut first.
- Infrastructure and third-party services, which scale with usage
- Licences and subscriptions, which renew whether used or not
- Maintenance: updates, dependency upgrades, small fixes
- Support: somebody answering when it breaks, with an agreed response time
- Change: the improvements the business will ask for, budgeted before they are asked for
The change line is the one that matters
Maintenance keeps a system alive. Change keeps it useful. Offices that fund the first and not the second end up with a system that works perfectly and no longer matches how the business operates, which is how a two-year-old build starts being described as legacy.
Suppose the build was 200,000 dirhams. A change budget of a few thousand a month buys a steady stream of small improvements. The alternative is a second project in three years to replace something that only needed adjusting.
What happens with no running budget
The pattern is consistent and it is not dramatic. Updates get skipped because there is no line to bill them to. A dependency falls far enough behind that upgrading it becomes a project. A small change is refused because it needs an approval nobody wants to request. Staff build spreadsheets beside the system to do what it no longer does.
By the time anybody proposes replacing it, the replacement is priced against the original build and looks like an outrage. It is not: it is three years of deferred maintenance arriving at once.
How to set the number
Start from what the system does rather than what it cost. A system three people use for internal reporting needs support during office hours and little else. A system your customers pay through needs a response time you can state in a sentence, and that is the expensive part.
Then agree the response time before you agree the price. Support pricing without a stated response time is a number attached to nothing.
What to take from this
- 01Running cost is five lines, not one, and change is the line that gets cut
- 02Skipped maintenance does not disappear, it accumulates into a replacement project
- 03Set support cost from the response time you actually need
- 04Budget the improvements before the business asks for them
Ask the question directly
- Can we do maintenance in-house and buy only support?
- Yes, and it works when somebody in-house has the time genuinely allocated. Maintenance assigned to a person who already has a full week is maintenance that will not happen.
- What is a reasonable response time to ask for?
- Match it to what an hour of downtime costs you. If nothing happens for an hour, next business day is sensible and much cheaper. If orders stop, you are buying something else and should price it that way.
- Does a system built well need less of this?
- Less maintenance, yes. The change line is unaffected, because it is driven by your business changing rather than by the quality of the code.
Related answers
Web development
New builds, rescues and re-platforms, measured against what the site earns rather than against how it looks. The brand system that carries it is built in the same engagement.
AI transformation
Most AI projects fail because they add a chat box next to the problem instead of removing the step that costs the hours. We start from the workflow, and from the systems and the data underneath it.
Bring the decision you are stuck on
A call, forty five minutes, no deck. We will tell you if we are the wrong firm.