I read a post on LinkedIn last week discussing how purveyors of software should make decisions, and it was mapped out with a nice decision tree. I agreed with it in four seconds, which should have been my first warning.
Two questions, drawn as a tree. Is it your core differentiator? Build it. If not, is it critical when it fails? Buy it. If it isn’t core and it isn’t critical, go ahead and build it; have fun. The line underneath it: AI made it possible to build anything. That doesn’t mean you should. And this was the theme of the week. Both in the upcoming episode of my podcast (the Signal - check it out every week on Tuesday at 9 am.) - ok, no more plugs.
I should disclose something before I go further. I sell software to lenders. Many of you already know this, but if you're a first-time reader, that is my business. So when a framework says “buy the critical things you don’t differentiate on,” I am exactly the guy who benefits from you believing it, and you should read the rest of this with that in your pocket. Hold me to the tree, not to the conclusion.
Because here is what happened when I stopped nodding. I ran the tree against the last twenty years of my actual working life, most of it inside institutions with regulators attached, and it kept giving me answers I couldn’t defend. Not wrong answers. Incomplete ones.
The tree is a startup tree. It is correct as a startup tree. In a bank, it stops one node too early.
THE DIAGNOSIS
Start with what the comment section proved, because it is the most interesting thing about that post and the author didn’t write it.
I had AI count: twenty-four separate people, out of roughly sixty who commented, independently wrote the same sentence in different words. One said it cleanest: AI has lowered the cost of building; it hasn’t lowered the cost of ownership. Another said it sharpest: AI made writing code cheaper; it didn’t make understanding old code any cheaper. A third: the cost curve shifted, the ownership curve didn’t.
That is not a hot take. That is a field observation with a sample size, and it arrived in a comment section instead of a research paper, which is where most of the useful data about this era is currently sitting.
Why this matters is that every IT team and software vendor worries about the same thing. Let’s play this out with a person named Samantha. She’s been at your company for a decade. In fact, she built half the system, then left, and nobody knows how it works.
What left with Samantha was not the code. The code is still sitting right there, readable, running. What left was the ability to explain why it works that way. Nobody wrote that down.
Hold that thought, because it is the whole article.
Ownership isn’t who wrote it. It’s who can explain it.
Now put that sentence inside a federally regulated institution and watch what happens to the tree.
THE MISSING BRANCH
Three things are true in a Canadian FI that the tree doesn’t account for. None of them are my opinion. OSFI has already written all three down.
One. Buying doesn’t move the risk. It moves the code.
Guideline B-10 covers third-party arrangements, all of them, not just the ones you call outsourcing. The transition ended May 1, 2024. The operative sentence is one line long:
The FRFI is ultimately accountable for managing the risks arising from all types of third-party arrangements.
So the “Buy” leaf on that tree is not an exit door. You still own the risk. You have relocated the source code and kept the accountability, which is a real trade with real advantages, and it is not the same trade as making the problem go away. In some ways the decision is closer to build vs rent. Rent has its own risk profile, its own pricing power problem, its own roadmap dependency. I sell rent. I’d still rather you knew that’s what you’re buying.
Two. “Critical if it fails” is not a gut call in a bank. It’s a filled-out form.
E-21 requires institutions to identify their critical operations and set tolerances for how long each one can be disrupted. Sections 1 and 2 have been in force since August 2024. Full adherence and operationalization is expected September 1, 2026, which is two and a half weeks from now.
That means the second node of that tree already has an answer sheet inside every FRFI in the country, and if the E-21 work was done properly, it is already filled in. Most operators I talk to have not connected those two things. The resilience binder and the build-versus-buy conversation happen in different rooms, run by different people, on different floors. Same problem as last week’s letter, different pillar.
Three. If it’s model-shaped, it’s in scope no matter who built it.
E-23 applies to all types of models regardless of the technology used, explicitly including AI and machine learning. Released September 2025, effective May 2027 after an eighteen-month transition. A weekend build does not escape it. Neither does a vendor’s. Nobody gets to argue their thing isn’t really a model because it was assembled from a chat window.
Put those three together, and the tree needs a third question. Here it is.
Is it your core differentiator? Build.
Not core, critical when it fails? Buy.
Not core, not critical? Can a second person explain how this works to an examiner in 2029?
Yes: build it.
No: you are not choosing between build and buy. You are choosing whether to create an undocumented dependency inside a regulated institution.
I’d call that last one the examiner test, and I picked it deliberately over the two obvious alternatives. Back to the LinkedIn post, one commenter wanted a node about complexity and maintenance load, which is reasonable. Somebody else wanted one about security exposure. Both are downstream of the same thing. If you can explain a system to a hostile third party five years from now, you already have the documentation, the boundaries, and the second owner. If you can’t, you don’t have a system. You have a person, and people leave.
Samatha leaves. The examiner still shows up.
THE COUNTERARGUMENT, GIVEN ITS BEST SHOT
The strongest pushback in that thread came from two people who build for a living, and they are not wrong, so I’m not going to pretend they are.
Their argument: why does everyone assume the cost of operating isn’t falling on the same curve as the cost of building? AI compresses maintenance too. It reads the code, writes the tests, generates the docs, handles the dependency bumps. For a non-core process where a vendor charges per seat plus an AI premium on top, a small internal team can now genuinely beat a multi-year commitment. The break-even moved.
That’s true. It has moved, and it will keep moving, and a blanket “buy your non-core critical systems” is lazier than the framework it claims to defend. One more version deserves a line: at small enough scale the right answer is building something small enough to throw away, so the Samatha problem can never reach you in the first place.
Here is where I’d push back.
In a regulated institution, the binding constraint was never maintenance labour. AI does compress that, genuinely and permanently. The binding constraint is accountability and evidence, and B-10 does not get cheaper because your agent writes better code. The examiner still needs a human who can explain the decision. E-23 still applies to the thing you generated. Nobody has automated the person who has to sit in the room and answer for it, and I don’t think anybody is going to.
Compliance is the shape of the product, not an obstacle in front of it. That is the part of the cost curve that hasn’t moved.
THE NUMBER
Twenty-four of roughly sixty commenters, independently, arriving at one sentence: building got cheaper, owning didn’t. Without putting two and two together until I wrote this article @Reuven Gorsht and I talked about it, so it’s a soft number and I’ll call it that. But the count isn’t really the point.
Here is the point, until that framework and discussions points to regulated industries the entire conversation that’s happening only talks about the cost of ownership as engineering time. In banking, insurance, defence and healthcare it isn’t. It’s the second cost, the one that shows up years later when somebody who doesn’t work for you asks how the thing works and won’t accept “Samatha built it” as an answer.
That gap between how the tech industry reasons about ownership and how a regulated institution has to is, more or less, why this letter exists.
MONDAY MORNING
Take one internally built system, the one nobody wants to touch. Not the whole inventory. One.
Ask three questions about it, which I’ve adapted from that comment thread in that post last week:
Can we state the boundary of this system in one paragraph? Do we know the failing case that will send us back into it? Is there a second person who could change it next quarter?
Two no’s and you don’t have a build-versus-buy decision to make. You already made it, quietly, some time ago, and you’re now maintaining a system whose real documentation is one person’s memory. Whether you replace it or write it down is a smaller question than knowing which one you’re in.
Then go find whoever owns your E-21 critical operations list and read it next to your application inventory. Those two documents are supposed to describe the same institution. In most places, nobody has ever put them on the same table.
That’s the week.
Credit where it belongs: the tree isn’t mine, and neither is the best line in this letter. I only added the branch.
Hit reply and tell me about the system nobody wants to touch. Names off, pattern on. The best replies become episodes.
— Chris