'Build So We Can Control' Is Half a Sentence

By Sean Hsieh, Founder & CEO, Runline

A few months ago a leader I work with, call him a CIO because that is usually the title, sat down with two people from his team and a coding agent, Claude or Codex, it does not matter which, and by the end of the afternoon they had a working prototype of something the credit union had wanted for two years. Not a slide about it. Not a vendor quote for it. A thing, on a screen, that ran.

I have watched that look on that kind of face more than once this year, and it is worth describing, because it explains most of what follows. It is not the face of someone who found a faster tool. It is the face of someone who just discovered they can build. For a person who has spent twenty years buying software and waiting on other people to deliver it, that is not an incremental improvement. It is a door opening in a wall they had stopped noticing.

Here is the part that matters for credit unions specifically. The people opening that door first are almost never software engineers, because most credit unions do not employ any. They are IT leaders, CIOs, heads of operations. The first group inside our institutions to sit down with Claude or Codex has been precisely the group that never got to build anything before. That is why the wonder is so real: they have genuinely never had this. The energy coming off it is good, and I am not here to pour cold water on it. Just the opposite.

I have felt that exact feeling myself. This is the third technology company I have founded or cofounded, and I have helped a number of other founders lift theirs off the ground, and every one of them taught me the same quiet thing the person holding a fresh prototype does not know yet: the prototype is not the beginning of the finish. It is the finish of the beginning. The hard work has not started. It is about to. We did not skip that afternoon of wonder either. We lived it, and then we lived every mile of what comes after it, the stretch nobody in the room can see from the doorway. That crossing is the whole subject of this series, and it is the reason Runline exists. McKinsey just put a number on how many organizations are standing in the doorway right now: in its 2026 State of AI survey, 32% of them decided against buying a software product this year because they believed they could build it themselves with AI instead.

The reason that pull is so strong at a credit union is not hype, and it is not naivety. It is history. Credit unions have spent decades on the receiving end of unmet vendor expectations: core systems that overpromised and underdelivered, integrations that never quite worked, feature requests that went into a queue and came back three years later as a line item on a renewal. You learn, over a career of that, to stop asking. You budget around the vendor’s roadmap instead of your own. You tell your board the thing they want will take eighteen months and a change order, because it always has.

And then one afternoon the thing they want takes an afternoon. No purchase order. No sales engineer. No roadmap that belongs to someone else. For a leader who has spent a career waiting on other people to build what the institution needed, that first working prototype is not a productivity gain. It is a taste of something they had quietly stopped believing they would get: the feeling of not needing permission. Of building for their own members, on their own timeline, answerable to no vendor’s priorities but their own. That feeling is intoxicating, and it should be, because it is the first honest glimpse in a long time of what the institution could become if it finally owned its own capability.

I want that for credit unions about as much as I want anything, which is exactly why I am not going to let the sentence stop at the intoxicating part. The taste is real. So is the cliff just past it. And all of it is arriving under pressure: the board wants an AI strategy by the next meeting, the decision is being forced faster than anyone can carefully weigh it, and being handed a paradigm shift you did not ask for and told to have answers ready is its own particular kind of scary.

That is exactly where the sentence stops. “Build so we can control.” The room nods, the energy is high, the decision half-forms, and everyone moves to the next agenda item before anyone says the part that comes after the comma. That second half is where the costs, the rigor, and the people you would need actually live, and it is the reason most of that good energy never reaches the bottom line. This series is the rest of the sentence. Credit union teams deserve to read the whole thing, especially now, because the paradigm really has shifted under them and almost no one is showing them what comes next.

The flip

For a decade, “build versus buy” was a settled question, and the answer was buy. Building your own software was slower, more expensive, and harder to maintain than licensing someone else’s, so unless software was your business, you bought it and moved on. That is the question those 32% just reopened, and the scale is worth sitting with: in McKinsey’s State of AI in 2026 (published August 25, surveying 1,719 leaders across 97 nations), a third of all organizations walked away, in a single year, from purchases they would have made without a second thought in 2024, because agentic coding tools made building it themselves look viable.

It is not evenly spread. The more technical and AI-mature the organization, the more it builds: 41% in technology, and among the AI “high performers,” the small group actually capturing financial return from AI, nearly half skipped a purchase, against 31% of everyone else. Financial institutions sit right in the thick of it, around 36%.

So when your board says “we should build so we can control,” they are not being reckless. They are joining the majority of the most sophisticated companies in the world. The impulse is sound. Control is worth wanting, and for a regulated institution, wanting it is close to responsible.

The trouble is that the sentence stops there. And the two clauses it leaves off are the ones that decide whether building was the smartest move you made this decade or the most expensive.

The sample isn’t you

Here is the first thing nobody says out loud in that board meeting.

McKinsey surveyed enterprises. The companies driving that 32%, the technology firms and the AI high performers, share something specific: they employ software engineers. Not one or two. Teams of them, with version control and on-call rotations and an entire culture built around shipping and then owning production software.

Most credit unions do not have that. They have an IT department.

I want to be precise here, because this distinction makes people defensive and it should not. IT and software engineering are both hard, both essential, and not the same job. IT keeps the institution running: the network stays up, the core stays patched, the vendor integrations keep talking to each other, the help desk answers the phone, the examiner’s security questionnaire gets a real answer. That work is the reason your members can move money on a Tuesday. Software engineering is a different discipline: designing, building, testing, deploying, and then living with software as a system that breaks in a new way every week and has no vendor to call, because you are the vendor now. Plenty of credit unions do not staff that discipline at all, and a large share outsource even their core IT to a CUSO. The very largest institutions may keep a small development team; the vast majority neither have one nor could justify the cost of one.

So read the McKinsey number one more time with that in mind. The build-versus-buy flip was powered by exactly the capability a typical credit union is least likely to have on payroll. “We’ll build it so we can control it” quietly assumes a software-engineering organization that, for most CUs, does not exist yet. There is a hidden clause inside the sentence: using engineers we will need to hire, become, or rent.

That is not a reason a credit union cannot build. Some can, and later in this series I will be specific about which ones and how you can tell. It is the reason the decision is far bigger than the four words spoken across the boardroom table make it sound.

Everyone feels productive. Almost no one captures the value.

Now the second thing the board meeting skips.

Say you build anyway. The same McKinsey survey followed what happens next, and the drop-off is steep enough to be worth memorizing. 80% of organizations say AI improved individual productivity. It feels useful, to nearly everyone who touches it. But only 37% report any measurable EBIT impact at the enterprise level, and that figure is flat against a year ago. And only 6% clear McKinsey’s bar of attributing at least 5% of EBIT to AI.

Read that funnel twice. Eighty percent feel it. Six percent bank it. The models are good enough to make four out of five people feel more productive, which means the models are not the bottleneck. The value is leaking somewhere between “this feels great” and “this shows up in the financials,” and it is leaking for the overwhelming majority, including the companies with the engineering benches a credit union would envy.

If you want to see the small version of this before you commit to the large one, look at the pilots already running inside your own institution. Two weeks after “Pilots Die in the Middle” (the article in this series on why AI programs stall at the pilot stage), I still meet the same three people at nearly every CU: the BSA analyst with ChatGPT open in a second tab, the loan officer softening denial letters in Gemini, the CIO with a private model he has not mentioned to the board. Every one of them is smarter and a little faster for it. Not one of them has moved the institution’s efficiency ratio, examiner-prep time, or margin. Eighty percent feel it. Six percent bank it. You are watching the funnel happen at your own desks.

Where does the value leak? Always in the same place.

Control is a liability transfer

This is the part of the sentence that matters most, so I am going to be blunt about it.

When you buy software, you are also buying a transfer of responsibility. The vendor owns uptime. The vendor patches the security hole at 2 a.m. The vendor keeps current with the model that got deprecated last month. The vendor produces the answer when the examiner asks how the system reaches its decisions. You pay for all of that, and you resent paying for it, and you call it “vendor lock-in,” and every word of the complaint is legitimate. But you are not the one carrying the pager.

“Build so we can control” is a decision to take the pager back.

Control is not a feature you switch on. It is a stack of obligations you agree to hold. Build, and you now own the uptime. You own the security patching. You own staying current with a model landscape that shifts every quarter, where the version you built on in spring is deprecated by fall. You own the audit trail the examiner will ask for, in a form the examiner accepts. You own the on-call rotation for the night it breaks. And in a regulated institution, “it breaks” does not mean a slow dashboard. It means a member harmed, or a suspicious-activity filing missed while the clock the law already started keeps running.

Control and responsibility are the same object seen from two sides. You cannot pick up the one without the other. That is what the board is really voting on when it nods at “so we can control.” Not a capability. A liability transfer, back onto an institution that may not yet have the team to hold what it is catching.

The chasm

There is a specific place where all of this comes due, and McKinsey’s own data traces the walk toward it. An organization decides to build. A prototype ships fast and feels like a win, and that good feeling is the 80%. Then the work that actually decides value begins: governing it, integrating it, maintaining it, securing it. Almost everyone stalls right there. A few cross, and compound.

I call that gap the chasm, and this series keeps returning to it, because it is where the roughly nine in ten builds that never reach EBIT go to die. Prompting a demo and running a regulated, audited, maintained capability are not two points on one road. They are two different disciplines. The demo is a weekend. Production is a standing commitment. The prototype that wowed the CFO in March is, by September, either the thing the institution runs on or the thing nobody brings up anymore.

A later piece in this series is about the chasm and nothing else, because crossing it is the whole game. For now it is enough to name it, and to notice that the boardroom sentence, “build so we can control,” describes the near edge of the chasm and stops talking exactly where the hard part starts.

The rest of the sentence

So here is the whole sentence, finally finished, and here is how the series walks through it.

Build so we can control…

• …but the demo lied to you about how hard control is, because the four qualities that make AI feel effortless for software engineers all fall apart on credit union work. (Part 2: why it looks easy when your “engineers” do it.)
• …and here is exactly how the build dies in the gap between prototype and production, in four failure modes your team will hit by about month three. (Part 3: the four ways the build dies.)
• …and crossing the chasm is a different discipline than building the demo: the verification, the audit trail, the model-risk rigor that nobody put in the budget. (Part 4: the chasm.)
• …so here is the honest build-versus-buy decision, made by engineering depth rather than by whatever feels safest across the boardroom table. (Part 5: build vs buy, honestly.)
• …and control, done right, means an operating system where every build compounds instead of decaying. That is the full sentence. (Part 6: the Company OS.)

I am going to be honest about both paths the entire way. There is a real open-source road across the chasm, and I will tell you what it costs and who can actually walk it. There is a Runline road, and I will tell you where it fits and where it does not. This first piece exists to make one point stick before we go deeper: the sentence your board is saying is half a sentence, and the missing half is the expensive one.

I keep coming back to why this matters beyond any one vendor decision. Credit union members deserve institutions that compound, that get a little better every year instead of starting over after every failed pilot and every retirement. Getting there does not begin with a tool, or with a demo, or with a coding agent that makes building look free. It begins with reading the whole sentence out loud, in the room, before anyone nods.

Next in this series: why the same AI that makes your vendor’s engineers 55% faster will make your BSA team slower, and what that gap tells you about every demo you are about to be shown.