There's a particular kind of operator I keep meeting. Technical, impatient, genuinely good. They didn't wait for a vendor. They built the thing themselves — an agent that scores deals, a pipeline that ingests documents, a dashboard the team now checks every morning. And it works.
Then it becomes load-bearing. Somebody makes a real decision with its output. And the question changes from does it work to what happens when it doesn't, and will anyone notice.
That second question is a different discipline. Not a harder one — a different one. Manufacturing has understood this for a century: the lab and the line are not the same building. Software has the same distinction and we're much worse at naming it, because a prototype and a production system look identical on screen.
Here is what actually separates them. Seven failure modes, in the order they tend to bite.
1. Production has a pulse
The system runs on someone's laptop. Or their personal cloud account, or under credentials only they hold. It works because they're there — they restart it, they notice when it's slow, they know which thing to nudge.
You haven't built a system. You've built a very sophisticated extension of one person's attention. And you now have an availability requirement on a human being who also needs to sleep, travel, and occasionally quit.
Ask: if that person went dark for two weeks, what stops?
2. The repository nobody ever committed to
Version control exists in more builds than you'd think. Commits do not. A repo gets initialized on day one and never used again, because commits feel like ceremony when you're moving fast.
The cost is invisible until the day it isn't. Something worked last month and doesn't now, and there is no way to find out what changed, because nothing recorded what changed. You cannot roll back. You cannot diff. You debug by memory.
Ask: can you restore last Tuesday's version in one command?
3. Files doing a database's job
Almost every self-built system starts with JSON or CSV on disk. It's the right call at the start. It stops being the right call at a threshold nobody announces.
The symptoms are consistent: a file grown to hundreds of megabytes, loaded into memory in full to answer a simple question. Fields that accumulated one at a time until there are hundreds of them and no schema. Nobody can query it, so every new question requires new code.
Ask: how long to answer a question about your data that nobody anticipated?
4. Concurrent writers, silently corrupting each other
This one catches even strong engineers, because it's specific to how agentic systems get built. You add an agent. Then another. They're independent, which is the appeal. And two of them write to the same file at the same time.
You don't get an error. You get a file that's subtly wrong. Rankings that don't match their own subscores. Totals that don't add up. Numbers that render one way in the summary and another in the detail view — and because the discrepancy is small, it reads as a rounding quirk rather than corruption.
Ask: what happens if two agents finish at the same second?
5. Rules that were built but never wired in
Someone writes a hallucination-suppression rule, a verification step, a confidence threshold for estimated values. Real work, correctly designed. And it never gets connected to the execution path.
It exists. It's in the codebase. It has a filename. It does nothing. Everyone assumes it's running because everyone remembers building it, and the output looks plausible either way.
This is the most dangerous item on the list, because your team believes there's a safety net under them.
Ask: for each guardrail you think you have, when did it last fire? If the answer is "never," is that because the input was always clean — or because it isn't connected?
6. Failure that presents as success
A scheduled job fails. The previous output is still on disk. The dashboard renders the previous output. It looks fine.
Not stale-with-a-warning. Fine. And it can stay that way for weeks, while people make decisions off a number that stopped moving. Nobody investigates a green light.
Whether a run happened and whether it succeeded are two different facts. Most self-built systems track neither — only whether there's a file to display.
Ask: how would you know this morning's run didn't run?
7. Nobody knows what's running
Ask how many agents or jobs are live right now. Ask which ran last night. Ask which are supposed to be running but aren't. In most builds the honest answer is that there's no way to find out without reading the code.
Once that's true, the system has stopped being something you operate and become something you interpret. Every question becomes an investigation. That's the moment a build stops scaling its owner's judgment and starts consuming it.
Ask: is there one screen that shows what's running and whether it worked?
The reframe
None of this means the build was a mistake. It usually means the opposite: nobody hardens a prototype nobody uses. These failure modes are what success looks like at the prototype stage, hitting the ceiling of what prototypes can do.
But there's a specific trap in it. The whole reason to build these systems is to scale your judgment — leverage without headcount. A system that needs constant hand-holding does the reverse. It borrows against your attention and calls it automation. The tell is when maintaining the thing that was supposed to free up your evenings has become how you spend your evenings.
Getting from the lab to the line isn't a rewrite. It's usually a couple of weeks of unglamorous work: get it off the personal machine, put it under version control, move the data somewhere queryable, make failures loud, and build the one screen that shows what's running. Then it belongs to the company instead of to you.
Institutional memory shouldn't have a pulse. Neither should production.
How many of the seven do you have?
Production readiness is a scoped, two-week engagement, not a rebuild. Book a call →