An MVP that survived contact with a regulated market
An early-stage lending startup in Bengaluru
A founding team with ten weeks of runway before a funding conversation, needing a working lending product rather than a prototype.
- Client
- An early-stage lending startup in Bengaluru
- Industry
- Finance
- Duration
- 10 weeks
- Team
- 3 engineers, 1 designer
- Year
- 2025
The situation
The team needed a product real enough to onboard actual borrowers before a scheduled investor conversation, not a clickable prototype.
Lending in India carries KYC, consent and data-retention obligations that cannot be deferred to version two.
The founders had a broad feature list covering three borrower segments, which was not deliverable in the time available.
No in-house engineering team existed, so whatever shipped had to be maintainable by a team hired later.
What we did
Cutting scope to one borrower segment
The most valuable work in the first week was removing two of the three segments. Building one journey properly produced something demonstrable; building three partially would have produced nothing usable. This was the most contested decision of the project and the one that made the deadline achievable.
Compliance built into the first version
KYC via a licensed provider, explicit consent capture with timestamp and purpose, and data retention rules were part of the initial build. Retrofitting consent into an existing lending flow means reprocessing every record already collected, which is far more expensive than doing it once at the start.
Boring, conventional architecture
A Next.js application against PostgreSQL, deployed conventionally. No microservices, no event sourcing, nothing that would require specialist knowledge to maintain. The team they hired afterwards needed to understand the codebase in days, and unusual architecture is expensive precisely at handover.
Audit trail from day one
Every state change on a loan application is recorded immutably with actor and timestamp. In a regulated domain this is not a feature to add later — it is the record of what happened, and it cannot be reconstructed retrospectively.
The parts that were actually hard
Problem
The KYC provider's sandbox behaved differently from production, particularly around partial verification failures.
How we handled it
We built an abstraction over the provider with a deterministic fake for testing, and handled partial-failure states explicitly rather than assuming success or failure. Two of those states only appeared in production and were caught because the abstraction made them easy to add.
Problem
Credit decisioning rules changed three times during the build as the founders talked to lenders.
How we handled it
We moved the rules out of code into a versioned configuration with a simulation mode, so the founders could change and test criteria without an engineering release. This turned a recurring disruption into a self-service task.
What shipped
- Borrower onboarding with KYC, consent capture and document upload
- Configurable, versioned credit decisioning with simulation mode
- Loan origination, disbursement tracking and repayment schedule
- Operations dashboard for application review and exception handling
- Immutable audit trail across every application state change
Outcomes
- Shipped in ten weeks with real borrowers onboarded before the investor conversation
- The decisioning configuration was changed several times post-launch without engineering involvement, which was the point of building it that way
- An in-house team took over the codebase and shipped their first independent feature within a fortnight
Outcomes are described qualitatively where no clean measured baseline existed before the work started.
Built with
Services involved
Have a problem shaped like this one?
Tell us what you are dealing with. We will come back with a scoped estimate and an honest view on whether we are the right fit.