Build vs Buy, Honestly

By Sean Hsieh, Founder & CEO, Runline

Every build-versus-buy conversation I have with a credit union eventually reaches a question the room does not want to ask, so I ask it. It is not “how big is your budget.” It is not “how large is the institution.” It is this: do you employ software engineers who can own a production system for the next twenty-four months, on call, or do you have an IT department?

Those are different questions, and the honest answer to the second one, at most credit unions, is IT. I have said it before in this series and I will say it plainly one more time, because the whole decision turns on it: IT and software engineering are both essential, both hard, and not the same discipline. IT keeps the institution running on systems other people built. Engineering builds and owns systems, through the chasm and out the other side, and then lives with them forever. The build path requires the second discipline. Buying exists precisely so that institutions with the first can still reach the far side.

That is the decision, stated honestly. The rest of this piece is how to make it well, whichever way it goes, because there is a real path on both sides and I am not going to pretend otherwise.

What actually gets you across

Start with the part that is the same on both paths. Across the credit unions that make it, and the enterprises McKinsey counts among its six percent, the same five disciplines show up. They are, not by accident, the exact inverses of the four ways the build dies.

Audit before you build. Shadow the people who do the work for weeks, not days, and map the real workflow, the seventeen undocumented steps and all. This is the discipline that beats the first failure mode, and it is unglamorous, human, and non-negotiable. You cannot automate a process you have never actually watched.

Decompose until most of it is deterministic. The teams that succeed do not throw everything at the model. They write mostly ordinary code, with a model call placed exactly where genuine judgment lives and nowhere else. Anthropic’s own guide to building effective agents puts it in one line: find the simplest solution possible, and only add complexity when you must. Most durable production agents are mostly code with a few model calls in the right places. Boring, and it works, and it beats the second failure mode on cost, latency, and hallucination at the same time.

Put everything on one orchestration layer. The teams that avoid sprawl give every agent exactly one place to live: a shared spine with identity, logging, policy, and governance built in, so a new workflow lands as configuration on the foundation instead of as another island nobody can see. This kills the third failure mode, and it is the hardest one to retrofit after the sprawl has already set in.

Stay model-agnostic. The teams that survive model churn never hard-wire themselves to one model. They route, and they choose models by evaluation, so a deprecation is a configuration change instead of an outage. This beats the first half of the fourth failure mode.

Treat the infrastructure as a living thing. The teams that last fund an ongoing function to keep the whole system current, with evaluations that catch drift and people who stay close to the labs. This beats the second half of the fourth failure mode, the one that quietly kills the six-month initiative.

Those five are what the six percent do. Notice that only one of them, the second, is really about the model at all. The other four are about the substrate around it. That is the tell that has run through this entire series: the model was never the hard part.

Path one: build the substrate yourself

Now, the two ways to actually get those five disciplines. I want to be genuinely fair to the first, because for the right institution it is the correct answer.

Everything you need is available. Anthropic’s guide is free. The orchestration frameworks are open source. The evaluation tooling exists. A capable engineering team can assemble the routing layer, the policy layer, the observability layer, and the eval harness, and stand up a real single spine. You will spend something like eighteen months building what a platform ships as substrate, and at the end you will own it outright and your team will understand it in its bones. That is worth a great deal, and I would never talk a capable team out of it.

The strongest case for this path comes from the people who actually walk it. Matt Pocock, demonstrating his own AI-coding workflow in 2026, argued that when there is “no clear winner” and the tooling changes monthly, you should “own as much of your planning stack as you possibly can,” because if you do not own it, the day it breaks you will not know how to fix it. He is right. He is also a world-class engineer who hand-built his own agent-orchestration framework to make his workflow run, which is exactly the bar this path sets: not “can we use these tools,” but “can we own the whole stack, and keep owning it.”

Here is the honest cost of that path, stated plainly so no one discovers it in month nine. It takes engineers, plural, senior, who can own it for the full twenty-four months with a real on-call rotation, not a side project stacked on top of their day jobs. If you have three or more of those people and can keep them, the open-source path is real for you, and you should take it with your eyes open. If you do not, the open-source path does not fail on day one. It fails on the timeline of the third and fourth failure modes, at the sprawl or the model shift, about eighteen months in, by which point your engineering capacity has quietly become a maintenance crew for last year’s decision. That is not a knock on anyone. It is arithmetic.

And the senior engineers this path needs are not sitting idle waiting to be hired. Netflix’s Chief Product and Technology Officer, Elizabeth Stone, running one of the most sought-after engineering organizations on earth, said it plainly in 2026: “I still find great engineering to be scarce, great data science to be scarce, great creativity to be scarce.” If Netflix has to compete hard for that talent, a credit union in a mid-size market is not going to assemble and hold a three-person senior team for a twenty-four-month infrastructure build by wishing for it. The scarcity is not a knock on your institution. It is the labor market you would be hiring into, and it belongs in the decision.

Path two: stand on a substrate that exists

The second way is to stand on a foundation where those five disciplines are already built and kept current, and to spend your people’s time on the workflows instead of the plumbing. That is what a platform is, when it is done right: not a tool you bolt on, but the far side of the chasm, pre-built. The audit discipline embedded in how a workflow gets deployed. The deterministic decomposition enforced by the architecture instead of by individual willpower. One spine, so sprawl has nowhere to form. Model-agnostic routing underneath, so deprecations are absorbed before they reach you. And a team whose entire job is keeping the infrastructure current, its cost spread across every institution on it. You still own your workflows, your data, and your decisions. You just do not own the pager for the substrate. That is the entire point.

The choice, without flinching

So the choice is not “build good, buy bad,” or the reverse. It is a match between the discipline the far side requires and the discipline your institution actually staffs. Build, if you have the engineers and the will to own the substrate for years. Buy the substrate, if your people’s time is better spent on the work your members feel than on a routing layer they will never see. Both are honest. Only one of them is honest for you, and the way to tell is the question I opened with, answered without flinching.

The one answer that is not available is the third one, the one I hear most often in the rooms where nobody finishes the sentence: wait. Wait for the models to get good enough that none of this is necessary. Wait for a vendor to ship the magic button. Wait until it is clearer. The models are already good enough, as this whole series has argued, and the clarity is already here: the value is on the far side of the chasm, and the far side is reached by discipline, not by waiting. The institutions that pick a path, either path, and execute it will compound. The ones that wait for the decade to make the decision for them will find that it did, and not in their favor.

Pick a path. Then, whichever one you picked, the last piece in this series is about what waits on the other side, and why it is worth the crossing: an institution where control is finally real, and every build makes the next one easier instead of harder.