The Four Ways the Build Dies

By Sean Hsieh, Founder & CEO, Runline

It is September now. The prototype that made the room go quiet back in the spring, the one that took an afternoon, has been live for a few months. Here is what it looks like today at most of the credit unions I visit. The weekly bill from the model provider is larger than anyone forecast. The analyst it was built for has quietly gone back to her old way of working, because the new way turned out to be slower once she counted the corrections. And nobody has said out loud that it is dead, because saying so would mean accounting for the two hundred thousand dollars.

This is the most common outcome, by a wide margin, and it is the part of the story the demo could never show. I want to be precise about one thing before we walk through it: this is not bad luck, and it is not your team failing to be good enough. Pilots die in the gap between prototype and production for four specific reasons, and they are the same four reasons at nearly every institution. You can see all four coming from here. That is the entire point of this piece.

Start with how predictable it is. Six independent studies, using six different methods, keep landing in the same narrow band. MIT’s NANDA report put the share of AI pilots that reach production and stay there at five percent. McKinsey’s 2026 survey, the one we have been walking through, found six percent capturing real financial value. RAND found that more than eighty percent of AI projects fail, twice the rate of ordinary IT projects. Deloitte, BCG, and IBM measured different things and arrived at the same verdict from different directions. And that verdict has held flat across every model generation, through each leap from one frontier model to the next. If better models were the fix, the number would be climbing. It is not. So the bottleneck is not the model. It is the four things that happen after the demo.

One: they skip the audit

The first way the build dies is that it gets built before anyone understood the work it was supposed to do.

The pattern is always the same. Someone scopes the project from the written procedure, the SOP, because the SOP is the thing you can read in an afternoon. They build against it. They demo against it, and against the SOP it works beautifully, because the SOP is a clean, bounded description of the work. Then it meets the actual work, and the actual work is not clean or bounded at all.

I showed you the shape of this in the last piece: the BSA workflow that differed from its own documentation in seventeen places. That distance between the written process and the real one is where this failure mode lives. Scope from the document, and you have built for a process that does not exist. I watched one credit union deploy a loan-file assembly workflow that had passed every test the team could think of, and then fall over in its first week on real files, because roughly a third of the institution’s loans carried some condition the SOP never mentioned: income earned in two states, a property held in a trust, a co-borrower with a prior charge-off. Each one was routine to the processor who had handled that kind of file for fifteen years. None of them were written down anywhere the build was scoped from. The build did not fail because it was bad. It failed because it was answering a question nobody in the institution actually asks.

Netflix’s Chief Product and Technology Officer named this trap from the opposite end of the size spectrum. “An organization that has thousands of people can no longer rely on tribal knowledge,” Elizabeth Stone said in 2026, “or ‘I’m going to find the one person who knows this.’” She was explaining why Netflix is now encoding its hard-won knowledge into shared infrastructure instead of leaving it in people’s heads. A credit union is far smaller, but its tribal knowledge is denser, because the person who knows why a loan held in a trust gets handled differently has been doing it for fifteen years and has never written it down. Skip the audit that draws that knowledge into the open, and you automate the documented process while the real one, the one that actually clears the work, stays locked in a handful of heads.

Two: they throw everything at the model

The second way the build dies is a bill.

Once you have a capable model, every problem starts to look like a job for the model. Need to pull a value out of a record? Ask the model. Compare two numbers? Ask the model. Check whether a date falls inside a range? Ask the model. It all works in the demo, so it all ships, and every one of those small calls goes out to a frontier model at frontier-model prices, on frontier-model latency, with a small but real chance of a confidently wrong answer every time.

One credit union I worked with built a BSA tool that did exactly this, calling a top-tier model for every alert classification, every threshold check, every comparison. By the second month the bill was north of four thousand dollars a week and climbing with volume. The latency was bad enough that the analyst it was built for stopped waiting on it. And the thing that actually ended it was the morning it read a textbook structuring pattern, a member breaking a large cash deposit into pieces each just under the reporting threshold, and called it routine. One confidently wrong answer, in the one function where a confidently wrong answer is a regulatory event. The project was shut down at a little under two hundred thousand dollars, and the person who had championed it learned the expensive way that “the model can do it” and “the model should do it” are different sentences.

Three: the sprawl

The third way the build dies is that it succeeds, quietly, in thirty places at once.

This is the failure mode that looks the least like failure while it is happening. You gave your staff access to AI, which was the right instinct, and your staff are resourceful, which is why you hired them. So they started building. The analyst has a workflow. The marketing coordinator has three. The lending assistant automated a slice of her week and never mentioned it, because it was just a shortcut and shortcuts do not go through a committee. Nine months in, the institution is running dozens of small AI workflows, none of them talking to each other, none of them on a shared foundation, and no one, anywhere, holding a complete list.

At one credit union, an employee built a small marketing agent in a vibe-coding app she signed up for in a browser, and wired it to push member-facing copy through a third-party model API that was not on the approved vendor list, because getting onto the approved vendor list takes a quarter and she had a campaign due Friday. It ran for three months before anyone in compliance knew it existed. They found it while reviewing the vendor queue for something unrelated, saw a charge from a model provider nobody recognized, and pulled the thread. The board asked how member data had been flowing to an unvetted vendor for a quarter. Nobody had a good answer, because nobody had been assigned the question. Every individual decision in that story was reasonable. The sum of them was an examiner finding waiting to be written. This is the mirror image of the argument I made in “Your Agents, Not Ours”: intelligence you do not own on a spine you control is not an asset, it is an exposure.

Four: they treat it as a project, not infrastructure

The fourth way the build dies is that it was scheduled to end.

Institutions know how to buy software. You plan it, you build or install it, you ship it, you declare victory, and you move the team to the next thing. That rhythm works for a loan origination system, because a loan origination system sits still after you install it. AI does not sit still. The models underneath it change on someone else’s schedule. What worked in the spring behaves differently by the fall. A capability that was solid the day it shipped drifts, quietly, because the ground it is standing on keeps moving.

One institution ran a six-month AI initiative, staffed and scoped like any other project, with a start date and an end date. Inside that same six months, one of the major AI labs deprecated models that teams had built on and went through a well-publicized stretch of rate-limit and quality problems. Workloads that had been reliable started failing, and no one was assigned to notice, because the project plan had no line item for “the foundation shifts under you every quarter, forever.” The initiative was never killed in a meeting. It just quietly stopped working, and no one owned putting it back together. That is what it looks like to treat infrastructure as a project. The project ends on schedule. The infrastructure was supposed to be permanent.

Four modes, one gap

Look at the four together and the shape is clear. Skip the audit, and you build for a process that does not exist. Throw everything at the model, and the economics bury you. Let it sprawl, and governance dies before anyone notices it was alive. Run it as a project, and it expires the first time the ground moves. These are not four unlucky accidents. They are the four predictable ways a build dies in the gap between “it worked in the demo” and “it runs the institution,” and between them they account for most of that ninety-five percent.

Here is the part I most want a credit union board to hear. None of this is an argument against building. It is a description of what building actually costs, stated honestly and in advance, instead of discovered one failure at a time across eighteen months and two hundred thousand dollars. Every one of these four modes has a discipline that prevents it, and those disciplines are a later piece in this series, because they only make sense once you have seen the specific thing each one is defending against.

But there is a more basic thing to understand first, the one sitting underneath all four modes at once. Skipping the audit, over-using the model, the sprawl, the expiration: each is a symptom of the same underlying fact. Crossing from a prototype to a production system is not more of the same work. It is a different kind of work, with a different name, and almost no one who has only ever bought software has had to do it before. That crossing is the chasm, and it is where we go next.