A build, buy or partner test you can run in one meeting
Most institutions are not bad at buying software. They are bad at articulating what they need before the demo starts, which is a different problem with a different fix.
The demo looks impressive because the vendor arrived with a definition of the problem and you did not. Theirs wins by default, and six months later you own a tool that answers a question you would not have asked.
Keys and a key hole
Write down what would make you say no
Before the next demo, write one page. Not requirements in the procurement sense, just plain sentences about what you would need to see in order to decline.
If you cannot write that page, you are not evaluating anything. You are shopping, and shopping ends with a purchase because that is what shopping is for.
This single step catches more bad decisions than any scoring matrix I have seen, and it takes twenty minutes.
Four questions, in this order
The first question: is the problem stable? If what you need will look materially different in eighteen months, buying locks you into somebody else's roadmap and building locks you into maintaining a moving target. Partnering is usually right when the answer is no.
The second: is it differentiating? If a competitor could buy the identical capability tomorrow and be at parity with you, that is a buy, and you should buy the cheapest adequate version rather than the best one. Save the money for the part that does differentiate.
The third is: can staff it? Not whether you could hire for it in theory, but whether you have somebody today who will own it on Monday. A capability with no named owner degrades to shelfware within two quarters regardless of how good the underlying product is.
The fourth is: what happens when it breaks? Building means you fix it. Buying means you wait in a support queue. Partnering means somebody has a contractual reason to care. For anything sitting close to member-facing decisions, that difference matters more than feature lists suggest.
Large door and smaller entrance
What the answers usually say
In my experience with institutions under a billion in assets, the honest pattern is narrower than the framework implies.
Building is right far less often than teams want it to be, because the constraint is rarely the software and almost always the people available to maintain it. Buying is right for most infrastructure, and the mistake there is buying the expensive tier for a commoditizing capability. Partnering is right for the specialized work that shows up a few times a year, where hiring is not justified and buying does not fit the shape of the problem.
The budget line nobody writes
For every dollar you put into tooling, plan on roughly three for change management.
Most budgets have this backwards. The license is visible and easy to approve. The work of getting people to change how they actually do their job is nobody's line item, so it goes unfunded, and then the tool underdelivers and gets recorded as a technology failure.
It was not a technology failure. It was an unfunded one, and the distinction matters because the next budget cycle will draw the wrong lesson from it.
So the last question, and the one I would put to any 2027 line with software in it: what is the number next to this for teaching, redesigning the workflow, and giving somebody protected time to sit with people while they change how they work?
If that number is zero, the tooling number is optimistic.
Have more questions, let’s talk
Elias Kruger, MBA, is the Managing Principal of Long-Range AI Consulting LLC, where he provides advanced analytics strategy and AI-powered business transformations tailored for midmarket sectors, including community banks, credit unions, and fintechs. His career spans over 22 years of continuous reinvention across finance, data science, and enterprise AI leadership, notably serving as a Vice President at Wells Fargo where he co-led an internal analytics consulting program of over 60 analysts. As a diagnostic-first practitioner, Elias designs customized human-empowering AI-enabled solutions ranging from multi-agent orchestration, RAG-powered workflows to predictive modeling that drives operational efficiency and valuation increases. He is a frequent speaker at major industry conferences like Finnovate.