What a retrofit touches, the far longer list it should leave alone, and the four questions to answer before anyone writes code.
Your system works. It has worked for years. It is unglamorous, a previous developer wrote most of it, and the business runs on it.
Somewhere inside it, a person is reading, sorting, matching or deciding by hand. That is the part that does not scale, and it is the part someone has told you AI can now do.
They are probably right. What they are usually wrong about is how much of the system has to change for that to happen. The honest answer is: less than you have been quoted for.
What a retrofit is
A retrofit adds one capability to software already in production and leaves the rest alone. No migration. No rewrite. No modernisation programme with the old system's name crossed out on the invoice.
If that sounds unambitious, that is the point. The ambition is in choosing the one decision worth automating and refusing to touch anything else.
The four things it touches
One decision, currently made by a person. Not a process. A decision. Which supplier does this invoice belong to. Is this delivery note a duplicate. Which of the eleven categories does this complaint go in. If you cannot write the decision as a question with an answer, there is nothing to automate yet, and that is the finding rather than a failure.
A way in and a way out. The model needs to receive the same thing the person receives, and to put its answer back where the person would have put theirs. In a system built in 2016, this is usually the hard part, and it is engineering rather than AI.
A written record of what it decided. Every decision, with its inputs, timestamped and queryable. Not for compliance theatre. For the Tuesday in eight months when someone asks why an invoice went to the wrong ledger and the only useful answer is one you can look up.
A way to switch it off. A flag that returns the decision to the person who used to make it, without a deployment. If the retrofit cannot be turned off in a minute, it is not a retrofit. It is a dependency.
What it must not touch
Your database schema. Your authentication. The workflows for every decision except the one in scope. Your team's habits, beyond the single screen where the answer now appears already filled in.
Anyone proposing to change those has stopped talking about a retrofit. That may still be the right project for you. It is a different project, with a different price and a different risk, and it should be named as such before you agree to it.
Four questions before anyone writes code
Which single decision? Name it in one sentence. If the sentence needs an "and", you have two projects.
Is the data that feeds it right? Not complete. Right. A model trained on a field that three people fill in three different ways will learn all three conventions and apply them at random. Bad data does not make AI fail loudly. It makes it wrong quietly, at a speed no human could manage.
What happens on the day it is wrong? Not if. A wrong invoice classification costs an afternoon. A wrong stock decision costs a lorry. Answer this before the build, because it determines how much checking you need, and checking is most of the cost.
Who is watching it in month seven? The question everyone skips.
Month seven is when retrofits die
A model is fitted to the world as it was on the day it was built. The world then moves. A supplier changes their invoice layout. You add a product line. A festival season arrives and the volumes look nothing like the training data.
Nothing announces this. Accuracy does not fall over. It sags, and it sags inside a system everyone has stopped watching because it worked for six months.
This is why we operate what we retrofit rather than handing it over and leaving. Either we monitor and retrain it on a monthly retainer, or we hand it to your team with documentation good enough that they can do it themselves. Both are priced before the build starts. The one option we will not sell you is the third one, where a model runs unwatched in your business and everybody assumes someone else is checking.
What it costs
We quote after the call rather than before it, because a number without a scope is a guess and you would be right not to trust it.
What we can tell you now is the shape. A single retrofit into a system that already runs is one phase, one price, one invoice, usually weeks rather than months. Monitoring afterwards is a monthly retainer, cancellable. Indian clients are invoiced in ₹; European clients in €.
The number is set by the second and third questions above, not by the model. Clean data and a cheap failure make it small. Messy data and an expensive failure make it large, and the finding will say so in writing before you have spent anything.
When the answer is no
If the data that feeds the decision is wrong, we will tell you that and stop. Fixing the data is real work and sometimes it is the whole job — after which you may find the decision no longer needs a model at all, because a rule covers it.