Build, buy or integrate: a decision guide for community institutions

Every technology project at a community institution starts with the same question: should we build it, buy it, or connect things we already own? The answer is usually to buy and integrate, and the real skill is knowing the exceptions.

Start from what is different about you

Build only where the capability is specific to how you compete or how you work. Commodity functions, such as origination workflow, document storage, fraud screening and standard servicing, are almost always cheaper and safer to buy. They come with a vendor that maintains them, a support model, and a body of regulatory experience behind them.

Ask five questions about any candidate for building:

1. Is this a real point of difference for us, or just something we want a particular way?
2. Do we have people who can maintain it for at least five years, including after the person who built it leaves?
3. What does our core provider or an existing vendor already offer?
4. How hard will it be to connect to our core and other systems?
5. What does it cost to leave if it does not work?

Count the full cost

The price on a quote is a fraction of the cost. Add implementation, integration, testing, change management, staff training, vendor management, validation and monitoring, and the staff time of the people who run it. Building also carries the cost of owning it indefinitely, including security patches, documentation and examiner questions. Buying carries the cost of dependence on someone else's roadmap.

Your core provider is part of the answer

Many core providers and their marketplaces offer vetted connections to third-party tools. Using them can shorten diligence and integration, though it does not remove your responsibility to understand the product and its risks. Before you buy something new, ask what the core already does, what is on its roadmap, and how data moves between systems. Paying twice for the same capability is common.

Integration is where projects succeed or fail

The work that surprises people is the plumbing: getting data in and out of systems reliably, reconciling it, and handling errors. Decide early how systems will exchange information, whether through APIs, files or scheduled batches, who owns each interface, and what happens when one fails. Our piece on data readiness covers the groundwork.

When building makes sense

There are good reasons to build. The workflow may be truly unique to your institution. A small, well scoped tool may close a gap that no product fits. Or you may need connecting code between systems, which almost always has to be custom. In each case, keep the build small, document it, assign an owner and treat it like any other model or vendor in your inventory.

A real example from launching a lender

When we launched Kawasaki Motors Retail Finance, most of the technology was bought and integrated: loan origination, servicing, credit bureaus and payments, with outside counsel on each contract. The dealer application portal was built, because the workflow of enrolling a dealer and executing an agreement was specific to the business and no product fit. It went live in June 2025 and has run in production since. Buy the commodity, build the difference, and connect them carefully.

A one page decision memo

Before committing, write a single page that states the problem, the options considered, the estimated full cost of each, the main risks, the exit plan and the recommendation. It forces clarity, it gives the board a record, and it is what you will want to hand an examiner who asks why you chose what you did. When the question includes AI, add the questions from our diligence guide.

A practical first step

List your last three technology decisions and check whether each one had a written rationale and an exit plan. If not, start with the next one.