A 45-person lending platform in Pune spent eleven months and nearly two crore rupees building an AI credit decisioning model. At the end of it, not a single live loan application had passed through the system.
The company was growing. Disbursals had tripled in eighteen months. The founder — technical background, former product manager at a larger NBFC — had a clear thesis: if they could replace the manual underwriting layer with an AI-scored decision, they could cut time-to-disbursal from four days to under six hours and move upmarket into ticket sizes the current team couldn't process at volume.
The thesis was sound. The execution was not.
They hired a small data science team, licensed a feature store, and began building a credit scoring model against three years of historical loan performance data. The model performed well in backtesting. F1 scores were strong. The team built dashboards. The dashboards looked good in board decks. Eleven months in, the founder called me.
The model was still in a notebook. It had never been connected to the loan origination system. The origination system was a vendor platform with a closed API and a six-week integration queue. Nobody had talked to the vendor.
"We built the model correctly. We just built it in the wrong direction — toward accuracy, not toward the system it needed to live inside."
The first thing I did was not look at the model. I asked to see the integration documentation for the origination platform. There wasn't any, because nobody had requested it. I asked who owned the relationship with the vendor. The answer was the founder, who hadn't spoken to them in eight months.
The second thing I looked at was the data pipeline. The model had been trained on historical data extracted manually from the loan management system each month. In production, it would need to score applications in near-real time — within seconds of submission. The pipeline that existed could not do that. It had never been designed to.
Third: the model had been built to predict default probability, which is the right problem. But the underwriting team made decisions on a matrix that weighted default probability alongside loan-to-value ratio, employment type, and bureau vintage in a way that was partly documented and partly institutional knowledge carried by two senior underwriters. The model output a number. The number had no defined mapping to an approval or a decline. That mapping — the most important part of the whole system — had never been written down.
The model wasn't the problem. The model was, in fact, quite good. The problem was that eleven months of investment had been directed entirely at the model and not at the system the model needed to become part of. There was no integration path. There was no inference pipeline. There was no decision logic. There was no handover plan for the underwriting team. There was, in short, no way for the model to ever touch a borrower — and nobody had noticed, because the dashboards were convincing and the demo environment was clean.
The first conversation was hard. I told the founder that three of the four planned workstreams — the expanded model, the bureau integration, the bureau score blending — needed to stop immediately. Not pause. Stop. The team had been building complexity into a system that had no foundation. Adding more capability to something that couldn't ship was not acceleration. It was debt.
We scoped one use case: a fraud flag in the underwriting queue. Not a full credit decision — that was too large a change to integrate safely in the time we had. Just a flag. If the model identified a high-risk pattern — document inconsistency, income-to-EMI mismatch above a threshold, bureau thin file combined with high requested tenure — it surfaced a warning to the underwriter. The underwriter still made the decision. The model assisted.
This was achievable in eight weeks because it required no changes to the vendor platform. The flag lived in an internal workflow tool the underwriting team already used. The inference pipeline was simpler: batch scoring every fifteen minutes against the queue, not real-time. The decision logic was co-authored with the two senior underwriters over three sessions — we wrote down, for the first time, exactly what combinations of signals warranted a flag. That document became the ground truth for the model's output mapping.
We shipped to a cohort of thirty loans in week eight. The underwriting team used it without being asked to change anything about how they worked. The flag appeared. They looked at it. They acted on it or didn't. That was the whole product.
Twelve months later, the full credit decision model is in production — built on the integration foundation we laid in those eight weeks. The vendor API is now live. The inference pipeline handles real-time scoring. The decision logic, having been written down once, has been refined through two calibration rounds with the underwriting team.
The founder asked me, at the end of the engagement, why nobody had caught this sooner. The honest answer is that the signals were there — the notebook that was never containerised, the vendor who was never called, the integration that was never scoped. But each of those was a technical signal in a room where technical signals were being interpreted as progress. Nobody was in the room asking the only question that mattered: what does this system need to do before it can touch a live borrower, and have we built any of that yet?
The model was not the problem. The model was never going to be the problem. The problem was that the organisation had funded a demo and called it a product — and nobody wanted to be the one to name that in a room where eleven months of work was on the table.
The expensive version of this lesson cost ₹1.8 crore and eleven months. The cheap version is a single conversation, in week one, about what it takes to get from a notebook to a system that a borrower actually touches — and whether the team has the path to do that before they write the first line of model code.