Algeria AgencyArtificial intelligence
A live automation: what it costs to keep
The day it works is not the end of the project, it is the start of the bill. What to know before putting the first one into production.
An automation is almost always sold and bought as an object: it gets built, it gets delivered, it works, everyone moves on. That is what the quotation suggests, carrying an end date and a single amount.
That is not what it is. An automation is a silent employee who never takes leave, never says they are overloaded, and sometimes stops working without telling anybody. It has a running cost, it needs to be looked at, and it ages — not because it degrades, but because the world around it moves.
This article is about the afterwards. What gets paid once it is live, what changes underneath you, the failure that makes no noise, the month the volume doubles, the person who leaves, and the decision to switch one off. The companion article covers the decision to automate and the control you keep while doing it — the sort between what can be undone and what cannot, the log, the off switch — and none of that is repeated here.
One figure appears in it, and it is not about automation. It is about the size of Algerian businesses, because that is what decides whether there is anybody to watch it.
The day it works is not the end
Go-live is the moment you stop paying for development and start paying for operation. Both are real, only one appears on the quotation, and the gap between them is what produces the sentence “we were not expecting that” six months later.
None of this is specific to artificial intelligence or to software. A delivery van is bought once and paid for every month — fuel, servicing, insurance, somebody to drive it. Nobody finds that surprising, because the van is visible. An automation is invisible, and the invisible is easy to leave out of a budget.
The practical difference is that a broken-down van announces itself immediately: it does not leave in the morning. A broken automation carries on existing, its admin screen opens normally, and it simply no longer does what it was built for. Nobody finds out before the first customer complains.
So the question is better asked at quotation time, when the answer costs nothing: what does it cost per month to keep running, who looks at it, and how would you see that it had stopped? A supplier with no answer to those three has finished building the system, not designing it.
Who watches it, and the most common answer
Everything written about automation implicitly assumes a second person exists: the one who receives the alert, the one who takes back control, the one who notices that Monday’s report did not arrive. That assumption is false for the great majority of businesses in this country.
The commercial register counts 2,419,913 registered operators, of which 2,145,557 are natural persons — roughly nine in ten. A registered natural person does not necessarily have zero employees, but they are an order of magnitude away from a company with an IT manager. The median business here is one person, and that person is already doing something else.
The consequence is direct and rarely drawn: if your automation needs to be watched in order to be reliable, it is not reliable, because nobody will watch it. That is not negligence, it is arithmetic. Designing on the assumption of a watcher is designing for a business other than the client’s.
What this imposes is a firm preference for systems that complain about themselves over systems you have to go and look at. An automation that sends a message when it has done nothing for two days beats a beautiful dashboard nobody opens — and the second is easier to sell, which explains how common it is.
CNRC, position at 10 December 2025
Three costs that are not development
The first is usage: every call to a model is paid for by the volume of text read and written. It is small per unit and proportional to activity, which is the good news — an automation that costs a lot is an automation that is working — and it is the only line most people anticipate.
The second is hosting and connection: the machine that runs the work, the service that schedules it, the subscriptions to the tools the automation ties together. This line is fixed, it does not fall when activity falls, and it is the one discovered in January while looking down a year of direct debits.
The third is not an accounting line and is the heaviest: human repair time. An export format changes, a supplier adds a column, a password expires. Each of those incidents costs somebody half a day, they happen a few times a year, and they appear nowhere because internal time is not invoiced.
We publish no table of these amounts, and that is deliberate. Model prices are revised several times a year — a table published today would be wrong before this article was a season old — and the rest depends entirely on volume and on the tools already in place. What transfers is the shape: a variable line, a fixed line, and a reserve of time.
What changes underneath you
An automation does not degrade on its own. Code that worked on Monday works the following Monday. What changes are the things it is attached to, and it is attached to a great many things you do not own.
The most frequent cases are dull and inglorious. A supplier alters the format of their export file. A platform changes its messaging rules. A site the automation was reading rebuilds its pages. An access key expires because somebody set a one-year duration and the year has passed.
None of those events is individually predictable, and their overall frequency is very predictable indeed: count a few interruptions per year per integration. An automation tying four tools together is exposed to four calendars of decisions you have no say in, which is the strongest argument there is for tying together few.
The practical conclusion is not to avoid integrations but to know which ones you have. A written list of the services the automation depends on, with what breaks for each if it changes, takes twenty minutes on delivery day and is never written afterwards, when it would be most useful.
The failure that makes no noise
The noisy failure is the good one: the system stops, an error appears, somebody rings. It is fixed the same day and costs only the disruption. It is not the one that hurts.
The silent failure is where the automation keeps running and processes nothing. The expected file is empty, so it imports zero rows — with no error, since zero rows is a valid result. The report goes out every Monday, calculated on data that stopped three weeks ago. Everything is green and nothing is moving.
The remedy is one simple idea and is rarely applied: monitor work done, not the absence of errors. An automation that usually handles between thirty and a hundred rows a day should complain when it handles zero, rather than waiting for an incident to declare itself. The threshold does not need to be fine, it needs to exist.
This control is one of the few that pays for itself immediately, because a silent failure is measured in weeks. A noisy failure costs half a day; a silent one found after a month costs a month of data to rebuild, and sometimes customers nobody sent anything to without knowing it. The check that catches it earliest is the daily reading of what the automation set aside.
The alert nobody reads any more
The natural response to the two preceding sections is to add alerts, and it is the most common way to manufacture a system nobody monitors. An alert that fires often becomes background noise, and background noise is ignored perfectly well after a fortnight.
The mechanism is the same as a forklift’s reversing beeper: in the first week everybody turns round, by the third nobody does. It is not a lapse of attention but a normal adaptation to a signal that has never announced anything important.
The rule that holds is that an alert must ask for one action and only one. If the recipient can do nothing on reading it, it is not an alert, it is information, and it belongs in a weekly report. The question to put to every alert is: what does the person receiving this do, within ten minutes?
A well-tuned automation sends very few messages, and one a month that matters beats twelve a day that do not. If the number of weekly alerts exceeds what one person can handle in their day, the system is no longer warning anybody, it is offloading onto its reader.
The month the volume doubles
Automations are tuned to the activity of the moment they were built in, and activity in this market is not flat. Ramadan, Eid, the start of the school year and the sales produce weeks that resemble no others, and it is exactly when an automation is most useful that it is most heavily asked of.
Breaking points are rarely where you expect them. It is almost never computing power; it is a supplier’s cap on calls per minute, a mailbox refusing to send beyond a daily volume, a message quota on a chat platform. Those limits are written in documents nobody reads before reaching them.
The test costs an hour and is done cold: take the volume of last year’s busiest month, double it, and ask the supplier what happens at that level. The answer is often that you need to give notice or change plan, and both of those are far easier to do in December than on a peak day.
Behaviour on exceeding the limit matters as much as the limit. An automation that refuses cleanly and resumes the next day is acceptable; one that silently loses what it could not process is not, and the difference between them is a design decision that is invisible until the threshold is crossed.
The person who leaves
Every automation has a parent: the person who asked for it, who knows why it exists and what it does with the odd cases. When that person changes role or leaves the business, the system does not stop — it becomes inexplicable, which is worse, because it carries on acting.
The state that follows is recognisable. Nobody knows any more why one rule excludes a particular customer’s orders, nobody dares remove it, and everybody works around it. The automation becomes a piece of scenery to be navigated, and the navigating ends up costing more than the manual process it replaced.
What prevents this is not technical documentation, which nobody reads and which ages badly. It is a page. What is this automation for, what triggers it, what does it touch, who to call when it stops, and why the three odd rules are there. A page stays current; a manual does not.
The moment to write it is delivery, and nobody does it then because everything is fresh and seems obvious. That is precisely the reason: what is obvious today is what will be lost, because nobody thinks to write down what everybody knows.
The quarterly review, in thirty minutes
An automation does not need a weekly meeting — it has nothing to report most weeks. It needs a rare, regular appointment, four times a year, with a fixed short agenda. Thirty minutes covers a whole small estate.
Four questions, in this order. What has it done this quarter, by volume? How many times did somebody have to step in by hand, and why? What changed at the suppliers it is attached to? And is the process it runs still the business’s real process?
The fourth question pays the most and is the one that gets skipped. Businesses change how they work without announcing the changes, and an automation faithful to a process abandoned eight months ago produces impeccable work nobody has any use for — the most expensive case on this whole page.
The useful record is four lines in the same file, quarter after quarter. Its value is not in today’s line but in the series: after a year, repeated manual interventions leap out, and they are what names the next thing to fix, with no thinking required.
When to switch it off
Some automations should be retired, and that is a healthy decision rather than an admission of failure. The process has gone, the tool it fed has been replaced, the volume has fallen to three cases a month that are handled by hand faster than watching it costs.
What stops people doing it is the price paid to build it. That reasoning is understandable and wrong: the money is spent either way, and the only question worth asking is whether keeping it costs more than it returns from today onwards. The past does not enter that calculation.
Switching off is done cleanly and not by deleting. Disable it, keep the code and the data for three months, warn the people who were receiving its output — there is nearly always one nobody had counted — and note the date. An automation deleted on a Friday evening is a Monday morning incident.
You also have to check what was leaning on it without saying so. An automation often feeds another one, or fills a file somebody has been using in their corner for two years. Stopping it reveals those dependencies better than any diagram, which is an argument for stopping first and deleting afterwards.
Taking over an inherited automation
The most frequent case is not building one, it is finding one in place, written by somebody who has gone, whose workings nobody knows and which everybody is afraid to touch. The reflex is to rewrite it, and that is almost always the wrong one.
The first thing to establish is what it actually does, which is not what it is believed to do. What triggers it, what it reads, what it writes, who it sends to. That list comes from watching for a fortnight without changing anything, and it is nearly always longer than the description you were given.
The second is knowing what depends on it downstream, and that is where the surprises are. An old automation has had time to become the source of something: a file an accountant opens every month, a field another automation reads. Rewriting without that inventory means fixing one thing and breaking three.
Only then, and often the answer is not to rewrite it. An ugly automation that has run for three years has been corrected by reality an uncountable number of times, and every odd rule it contains is the memory of a real case. A clean rewrite loses all of them and rediscovers them one by one, in production.
What we do, and what we refuse
What we take on is bounded: designing the automation with the person who does the work today, installing it with its volume checks and its explanation page, and staying reachable through the first few weeks, which are when all the unforeseen cases turn up.
We do not sell a monthly maintenance contract on an automation a client can watch themselves, and that refusal costs us. Most of the systems we install need nobody between two quarterly reviews; billing for a permanent presence on them would be selling insurance against a risk we were paid to remove.
Nor do we take on a process whose owner cannot say what it is for. This is not a methodological requirement: a process nobody can justify is a process nobody will validate, and automating it produces a machine that faithfully executes something the business had stopped wanting.
Finally, we will not quote you the time saving obtained at another client. That figure is real, it was measured, and it is valid for the business it came from and for no other: it depends on volume, on the tools already in place, and on how people work. The only figure that is valid for you is the one you get by timing a week of the process concerned, and it is yours to measure before believing us.
Frequently asked questions
What does an automation cost per month once installed?
Three lines, only one of which is an invoice. Model usage, proportional to volume and generally the smallest. Hosting and the subscriptions of the connected tools, fixed. And repair time when a supplier changes something — a few half-days a year, appearing nowhere because internal time is not invoiced. We publish no table: model prices are revised several times a year and the rest depends entirely on your volumes.
How do you know an automation has failed?
By monitoring what it does, not the absence of errors. The dangerous failure is the one where everything is green and nothing is processed: the expected file is empty, zero rows imported is a valid result, and the report keeps going out. Set a volume threshold — “it usually handles between thirty and a hundred rows a day, complain at zero”. The threshold does not need to be fine, it needs to exist.
We have nobody to put on it. Is that disqualifying?
No, but it changes what should be built. Nine in ten registered operators in Algeria are natural persons, so having no watcher is the normal case rather than the exception. The consequence is to prefer systems that complain about themselves to systems you have to go and look at: an automation that needs watching in order to be reliable will not be, since nobody will watch it.
What should be done about activity peaks?
Test cold. Take the volume of last year’s busiest month, double it, and ask each supplier what happens at that level — breakages almost never come from computing power but from call limits, sending quotas and messaging caps. Check the over-limit behaviour too: refusing cleanly and resuming tomorrow is acceptable, silently losing what could not be processed is not.
Should an inherited automation nobody understands be rewritten?
Rarely, and never before watching it. Establish over a fortnight what it actually does and what depends on it downstream — a file an accountant opens monthly, a field another automation reads. An ugly automation running for three years holds one odd rule per real case it met; a clean rewrite loses all of them and rediscovers them one by one, in production.
When should one be stopped?
When keeping it costs more than it returns from today onwards — the price paid to build it does not enter that calculation, it is spent either way. Switch off rather than delete: disable, keep the code and data three months, warn the recipients of its output, note the date. Stopping reveals the dependencies nobody had counted better than any diagram.
Where we come in
An automation in service depends on outside services that change without telling you. The real cost is not building it, it is keeping it standing.
- We list those dependencies and what breaks if each one moves.
- We set a volume threshold beyond which somebody has to look.
- We design alongside whoever performs the task, not their superior.
An automation you can watch yourself deserves no monthly subscription, and most of them are in that case.
Read next
Agent, chatbot, automation: three things, one name
Three different products are sold under the same word. They fail differently, and the question that separates them is: who starts it, and who decides?Automation: the queue nobody opens
An automation that works produces cases it cannot handle. They pile up somewhere, and the report goes on showing a comfortable success rate.Automating without losing control
Automation makes a process faster, not better. How to sort what can run alone from what has to wait for a person.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.