It only ever saw the happy path
It was tested on the clean example. Real inputs are truncated, duplicated, badly scanned, in the wrong format, or simply missing.
WHEN THE DEMO WORKED AND THE PROJECT DIDN’T
The demo worked. That was the easy part.
Someone on your team built something that proved the idea. Months later it is still a demo. Nobody uses it for real work, nobody wants to be responsible for it, and nobody can say exactly what is wrong with it.
- Diagnosis before any rebuilding
- An honest answer about whether to finish it
- Your team owns it at the end, not me
01 / WHY IT STALLED
It is almost never the model.
A demo proves something can happen once, with a person watching. Real use means it happens repeatedly, unattended, on messy inputs, when the person who built it is on holiday. These are the gaps I find most often.
Nobody can tell when it is wrong
It produces a confident answer either way. Without a way to catch bad output, no one is willing to act on the good output either.
It has no owner
It was somebody’s side project. They moved teams, and it now belongs to nobody—which means nobody can approve using it.
It costs more than anyone checked
Fine at ten runs a week. Nobody priced it at a thousand, and now the bill is a reason not to roll it out.
It cannot reach the real data
It works against a copied spreadsheet because getting proper access meant a conversation with IT that never happened.
It cannot be handed over
No documentation, no tests, no way to change it safely. Using it means depending on one person’s memory.
02 / THE FIRST CONVERSATION
Before rebuilding anything,
find out if it should exist.
The most expensive version of this work is finishing something that was never worth finishing. So the first question is not how to fix it.
- 01
What was it supposed to replace?
If nobody can name the work it was meant to take over, that is usually the actual problem—and no amount of engineering fixes it.
- 02
Who stopped using it, and why?
The people who abandoned it know exactly what is wrong. They are rarely the people who commissioned it.
- 03
What would have to be true to trust it?
Usually a specific, nameable thing: someone checks the output, or it never touches the live system, or it flags what it is unsure about.
- 04
Is finishing it cheaper than restarting?
Sometimes the prototype is a good specification and a bad foundation. I will tell you when the honest answer is to keep the lesson and throw away the code.
03 / WHAT USUALLY GETS BUILT
The unglamorous half
that nobody scoped.
What happens when it goes wrong
Retries, timeouts, bad inputs, and a clear signal when the system should stop rather than guess.
A place for a person to say no
The output arrives somewhere a human can check it, correct it, and approve it before it counts.
Proper access, properly scoped
It reads the data it actually needs from the real source—and nothing else, because that was easier to wire up.
A number you can plan around
What one run costs, what a thousand cost, and which parts are worth spending on.
Some idea of what it did
A record of what ran, what it decided, and what it skipped. Without this, nobody can defend the result.
Something your team can change
Documentation and structure, so the next change does not require the person who wrote it.
04 / WHERE THIS COMES FROM
Being straight about
what I can show you.
I do not have a published case study of rescuing someone else’s stalled AI project. If that is the proof you need, I would rather say so here than let you find out on a call.
What I can point at is this. Taking software from “it worked on my machine” to “a team depends on it” is my day job—I am a Staff Software Engineer, and most of that career has been the part after the prototype.
And every build on this site was made to survive real use rather than to demo well. The media-list workflow is mostly guardrails, refusals, and evidence, because that is what made it trustworthy enough for someone to actually rely on.
See what that looks like in practice05 / THE HANDOFF
What you have
when it is over.
Agreed before anything gets built, so there is nothing to discover at the end.
A working system
Running on your real inputs, not a demo file. If it has not survived the actual work, it is not finished.
The code and the documentation
Written so another engineer could pick it up. Where it lives and who can reach it is settled in writing up front.
A walkthrough
The people who will run it are shown how, using their own work as the example.
The limits, written down
What it does not do, where it stops and asks for a person, and what we deliberately left out.
What to do when a run fails
The failure modes, who checks the output, and what happens when it goes wrong—agreed before it does.
What it depends on
The outside services it needs to keep running. They bill you directly and can change their terms without asking either of us.
BRING THE ONE THAT STALLED
What did you build
that nobody uses?
Tell me where it stopped What it was meant to do, who stopped using it, and what you think went wrong. If the honest answer is that it is not worth finishing, you will hear that—email [email protected] if that is easier.