JOURNAL
Published on
WHAT HAPPENSAFTER HANDOVER
An automation doesn’t wear out. The world it is attached to does.
THE ANSWER
At handover the system is yours and it works. What changes afterwards isn’t your process. It’s everything around it: APIs, formats, credentials that expire. Business automation maintenance covers monitoring, small updates and incidents. The monthly bands are published on the pricing page. It isn’t unlimited availability, and new features are quoted separately.
AI-generated image
IN SHORT
Support covers monitoring, small updates and incidents.
It isn’t compulsory and it isn’t unlimited availability.
Monthly bands are published on the pricing page.
THE DAY AFTER
CODE DOESN’T AGE ON ITS OWN
A delivered automation doesn’t wear out with use. The code running today is identical to the code of six months ago. Everything around it is what moves. Fondazione Stelion and Stelion Lab are mine: I built them and I keep them. Keeping them means noticing that something outside has changed, before the people using it do.
THE CAUSES
WHAT BREAKS, AND WHY
None of this is your fault. None of it is the code’s fault. It all arrives from outside.
An API changes version
The supplier ships a new version and closes the old one. If nobody is watching, you find out the day everything stops.
A credential expires
Tokens, keys and certificates have a lifetime. It’s the most common cause and the most trivial. Ten minutes if somebody is watching, a lost week if nobody.
An export changes shape
An extra column, a renamed header, a different separator after an update. The automation keeps running and starts writing wrong data. (Worse than stopping.)
The volume grows
What works on a hundred rows behaves differently on a hundred thousand. Rate limits, run times, memory. It isn’t broken: it has reached a place nobody measured.
The people in the process change
Somebody new uses the tool in a way nobody anticipated. Or stops filling in the field an automation was leaning on. The code holds, the process doesn’t.
THE PERIMETER
WHAT SUPPORT COVERS
- Monitoring
- I check that scheduled runs start and finish. Errors reach a person, not a log nobody opens.
- Small updates
- A library to move forward a version, a column that changes name, a message to correct. All inside the perimeter it was delivered with.
- Incident handling
- When something stops I get it running again and write to you about what had changed. The second half matters as much as the first.
- What it isn’t
- It isn’t unlimited availability. New features change the perimeter and are quoted separately: another automation, one more integration, a different objective.
- What it is priced on
- The system as delivered: how many integrations it has, how critical it is, how often it runs, how fast you need an answer. The monthly bands are on the pricing page.
- Not compulsory
- You decide after handover, looking at the system in your hands. If you go without it, the system stays yours as it is.
AI-generated image
IF YOU DON’T TAKE IT
THE SYSTEM STAYS YOURS
Going without support isn’t dramatic. The system keeps running until the environment around it moves. What changes is how you find out. At handover I leave logs and alerts pointed at an address of yours. When a run fails, the news reaches a person. Nothing forces you back to me. (If it holds without me, I handed it over properly.)
THE CALLOUT
WHEN SOMETHING STOPS
The order is the same. With a support arrangement or a one-off callout.
I stop the damage
First: it must not keep producing wrong data. A paused process beats twenty records to correct by hand.
I find where something changed
It’s almost never the code. It’s a different response from an external service, a field that stopped arriving, a permission revoked. The log says where to look.
I get it running again
The smallest repair that brings it back inside the delivered perimeter. If a larger change is needed, we estimate it separately.
I write down what happened
Two lines in the documentation: what changed, what I did, what could recur. The second incident of a kind costs less.
Automations don’t age on their own: everything they’re attached to does.
QUESTIONS
- Is monthly support compulsory?
- No. It’s priced on the system you’re holding. The monthly bands are published on the pricing page.
- Where is the line between a small update and a new feature?
- An update keeps the system inside the perimeter we wrote. A change that alters the objective, an integration or a responsibility falls outside. It becomes its own line, with its own estimate.
- Are hosting, domains and APIs included?
- No, unless the proposal says otherwise. They stay in your name and billed to you. What you pay for stays yours.
- If I stop working with you, who can maintain it?
- Anybody who can read what I left. A repository with its history, declared dependencies, handover documentation. That’s the minimum for somebody else to continue.
- How often does something break?
- It depends how many outside things the system touches. I have no figure valid for your case. Risk grows with connected services: 3 outside APIs are 3 calendars you don’t control.
Have you got a system delivered a while back that nobody watches any more? That’s the moment to write. Even just to work out what’s worth monitoring.