Every engineering leader I know has a build-versus-buy decision sitting in their backlog right now, and most of them are getting it wrong in one of two predictable directions. Either they are rebuilding a commodity capability that a vendor would have handed them for a fraction of the cost, or they are buying a platform that quietly becomes the load-bearing wall of their product and then discovering, eighteen months later, that they cannot change it. I have made both mistakes, and I have watched teams I respect make them too.
The framing of the question itself is part of the problem. We treat build versus buy as a single binary choice when it is really a portfolio of smaller decisions about ownership, control, time, and risk. In regulated fintech the stakes are higher than in most domains, because the thing you buy or build often touches money movement, customer data, or a compliance obligation that you cannot delegate away. What follows is the way I actually reason through these decisions, with the trade-offs I have learned to take seriously and the ones I have learned to ignore.
The Default Is Not Obvious
There is a comfortable myth in engineering culture that building is the brave, principled choice and buying is the lazy one. There is an equally comfortable myth in finance and procurement that buying is always cheaper because you avoid headcount. Both are wrong often enough that I distrust anyone who walks into the room with a strong prior in either direction. The honest answer is that the default depends entirely on where the capability sits relative to your core business.
The single most useful question I ask is whether the thing in question is a source of durable differentiation or simply a cost of doing business. If our customers would notice and care that we built it ourselves, that is a candidate for building. If the capability is table stakes that every competitor also has, the burden of proof is on building, not buying. A payments company should not be writing its own log aggregation stack. It probably should own its risk-scoring logic. The trouble is that the boundary between core and commodity moves over time, and a thing that was once a differentiator becomes a commodity as the market matures around it.
The Real Cost of Building
When teams estimate the cost of building, they estimate the cost of getting to a first working version. That is almost never the relevant number. The relevant number is the cost of owning the thing for its entire life, which includes the on-call rotation, the security patching, the documentation that nobody wants to write, the second engineer you need so the first one can take a holiday, and the slow accretion of edge cases that turns a clean weekend project into a system with its own folklore.
I have started forcing teams to articulate the total cost of ownership before we approve a build. Not a spreadsheet to the third decimal place, but an honest accounting of the obligations we are signing up for. A few categories I make people name explicitly:
- The ongoing maintenance burden, expressed in fractional engineer-years per year, not just the initial build cost.
- The opportunity cost of the senior people who will build it and then be unable to work on anything else.
- The compliance and audit surface the system adds, including who attests to its controls.
- The bus-factor risk if the one person who understands it leaves.
- The cost of keeping it current with a moving external standard, such as a card network mandate or a regulatory change.
Once you write these down, a surprising number of build proposals lose their shine. The initial estimate might have been three engineer-months, but the lifetime cost is closer to one engineer permanently, and that engineer is your best one. Suddenly the vendor invoice that looked expensive looks like a bargain for the time it gives back.
The Real Cost of Buying
Buying has its own hidden ledger, and it is just as easy to underestimate. The license fee is the visible part. Underneath it sit integration cost, the tax of adapting your data model to theirs, the recurring price increases that arrive once you are too embedded to leave, and the quiet erosion of your team's understanding of a capability you no longer operate yourselves. There is also the matter of the vendor's roadmap, which is theirs and not yours, and which will occasionally diverge from your needs at the worst possible moment.
The most expensive form of buying is the one that creates dependency on a capability you cannot replace. I have seen a company become so dependent on a single fraud vendor that the vendor's pricing power became effectively unbounded, because switching meant re-validating models against years of historical data and convincing a risk committee that the replacement was at least as good. The original decision to buy was correct. The failure was not building any optionality around it.
The question is never simply whether to buy, but whether you can leave. A vendor you can replace in a quarter is a tool. A vendor you cannot replace in a year is a dependency, and you should price it as one.
Control Where It Matters
In regulated fintech, control is not an abstract architectural preference. It is sometimes a legal requirement. When a regulator asks how a decision was made about a customer's money, the answer cannot be that a third-party black box produced a score we do not fully understand. That reality reshapes the build-versus-buy calculus for anything close to the regulated core.
I draw a hard line around the things we must be able to explain, reproduce, and defend. Decisioning logic that affects lending, eligibility, or anything that could be construed as adverse action tends to fall on the build side, or at least the heavily-owned side, even when a vendor offers something faster. The cost of building is real, but the cost of standing in front of a regulator and being unable to explain your own product is existential. For the supporting infrastructure around that core, I am far more relaxed, because nobody is going to subpoena our choice of monitoring vendor.
Speed and the Cost of Being Late
Time to market is the argument most often used to justify buying, and it is frequently the right one. If a capability is a prerequisite for entering a market and a vendor can get you there in weeks while building would take quarters, the math usually favors buying, because the revenue you capture by being early dwarfs the license fee. I have made this trade deliberately many times, accepting a worse long-term cost structure in exchange for getting to market before a window closed.
What I have learned to resist is letting speed become the only variable in the equation. Speed matters enormously when there is a real, dated window, such as a partner integration deadline or a competitive launch. It matters far less when the urgency is manufactured by an internal stakeholder who simply wants the thing now. I ask people to distinguish between a deadline that the market imposes and a deadline that we imposed on ourselves, because we will happily mortgage our architecture for the former and should rarely do so for the latter.
The Seam Strategy
The most durable decisions I have made are not pure build and not pure buy. They are buy-with-a-seam: integrate the vendor behind an interface we own, so that the vendor is replaceable without rewriting the systems that depend on it. This costs more up front than a naive integration, because you have to design the abstraction and resist the temptation to leak vendor-specific concepts through it. It pays for itself the first time a vendor relationship sours or a better option appears.
The discipline here is to keep the integration thin and the abstraction honest. The moment your wrapper starts faithfully reproducing every quirk of the underlying vendor, you have not bought optionality, you have just added a layer. The test I apply is whether a competent engineer could swap the implementation in a focused project without touching the callers. If the answer is no, the seam is decorative.
This approach also changes how the build-versus-buy conversation feels, because it removes the finality. We are not committing to a vendor forever; we are renting a capability while we learn whether it is core. Sometimes we start by buying behind a seam, discover the capability really is differentiating, and replace the vendor with our own implementation later, on our own schedule, with real production knowledge of what good looks like.
When the Honest Answer Is Build
There are situations where I will overrule the cost arguments and build anyway. The clearest is when a capability is genuinely the thing customers pay us for. If the way we score risk, price a product, or sequence a payment is what makes us better than the competition, outsourcing it is outsourcing our reason to exist. No vendor will ever invest in our specific edge the way we will, because our edge is not their business.
The second case is when no vendor solution actually fits, and the gap is in the part that matters. It is tempting to bend our requirements to match what the market offers, and for commodity capabilities that compromise is usually wise. For the core, bending the requirement means shipping a worse product. I would rather build something that fits than buy something that almost does, when the misfit lands squarely on the differentiating surface.
The third case is more subtle: when building teaches us something we need to know. Occasionally the act of building a capability forces a depth of understanding that we cannot acquire any other way, and that understanding compounds across the rest of the product. This is a real benefit, but it is also the most overused justification, so I hold it to a high standard and demand that the learning be specific and load-bearing rather than a vague appeal to engineering virtue.
Reversing the Decision Later
Almost every build-versus-buy decision is made once and then treated as permanent, which is exactly backwards. The market moves, vendors improve, our scale changes the economics, and the capability that was core last year becomes commodity this year. A decision that was correct when we made it can quietly become wrong without anyone noticing, because nobody owns revisiting it.
I have started attaching a review date to significant build-versus-buy decisions, the way we would to any other risk. Not a heavyweight process, just a calendar entry and an owner, with a short note about what would have to change for us to revisit. For a build, the trigger might be a mature vendor emerging that does it better and cheaper. For a buy, the trigger might be our volume reaching a point where the per-transaction cost exceeds what an in-house team would cost to run. Naming the trigger in advance turns a sunk-cost argument into a data-driven one, because we decided the condition before we were emotionally invested in the answer.
Conclusion
Build versus buy is not a single decision and it is not a permanent one. It is a recurring judgment about where your differentiation actually lives, what you can afford to own, and what you can afford to depend on. The teams that get it right are not the ones with a strong bias in either direction; they are the ones who can say clearly what is core and what is commodity, who price the full lifetime cost of both paths honestly, and who build seams so that today's decision does not foreclose tomorrow's options. Get those habits right and the individual decisions mostly make themselves, which is the closest thing to a shortcut I have found in twenty years of making them.