Build vs. buy: the real cost of an in-house decision engine

Every so often, the discussion comes back to the table: "we can build this ourselves". And it is true — a competent engineering team can build a rules evaluator in a few months. The right question is not whether it can be done, but what you are actually buying when you decide to build: not a development project, but a commitment to maintenance, governance and evolution for as many years as credit is part of the business.

The visible cost and the iceberg

The first version — the evaluator that takes a credit application and returns approve or decline — is the visible part, and the cheapest. Below the waterline is everything a real credit operation ends up needing:

• Policy versioning and rollback: knowing which rules were running on any given date, and going back in seconds.
• Decision traceability: a record of inputs, path and outcome, with the raw response from every provider.
• Integrations with credit bureaus and data sources: each provider with its own authentication, its timeouts, its fallback and its re-query cache.
• An editor the risk team can operate without filing tickets to development — otherwise the in-house engine turns IT into a permanent bottleneck.
• Batch processing, champion/challenger experimentation, model execution, permissions and segregation of duties, monitoring…

Each of those points is a project in itself. Added together, they are the reason in-house engines usually stall at version one: they decide, but they cannot be governed.

The cost that never shows up in the budget: time

While the in-house engine is being built, the credit policy keeps living where it already lived: in the core, in spreadsheets, or in code only two people understand. Every cutoff adjustment takes weeks; every campaign waits its turn in the backlog. The opportunity cost — the policies never tested, the segments never opened — appears in no budget, yet the business pays it every month.

And then there is key-person risk: an in-house engine is only as good as the tenure of whoever wrote it. With every departure from the team, part of the system turns into archaeology.

When building does make sense

There are legitimate cases: when decisioning is the central competitive differentiator and the institution has the engineering scale to sustain a dedicated platform team for years; or when very particular requirements (extreme latency, infrastructure constraints) rule out any product. If those conditions are not met — and at most Latin American institutions they are not — building means choosing the expensive road to arrive later at the same place.

How to decide with evidence

A serious comparison is made across dimensions, not by intuition: time-to-market, three-year total cost of ownership (team included), governance and auditability, risk team autonomy, and dependency on key people. We put that comparison together point by point in why uFlow, and the detail of what a governed engine must cover is in our guides for financial institutions.

The short conclusion: building an engine is easy; operating a governed engine for years is not. The smart decision puts your own engineering effort where the real business differentiator is — and solves the decision infrastructure with a platform that has already traveled that road.