Scaling a Fintech Lending Platform

FinEdge had grown from a scrappy startup into a regional lender processing roughly 1,200 loan applications a week, but its original platform — a single monolithic PHP application written four years earlier — had not grown with it. Every new loan product, compliance rule, or partner integration meant editing the same tangled codebase, and a single deploy could take an engineer most of a day to ship safely. Worse, the manual underwriting workflow meant applicants routinely waited three to five business days for a decision, and FinEdge was watching qualified borrowers abandon the funnel for faster competitors.

The technical debt had become a business risk. During peak campaign periods the platform would buckle under load, with database lock contention causing timeouts and, on two occasions, multi-hour outages during exactly the windows when application volume — and revenue — was highest. The underwriting team was drowning in repetitive manual reviews of low-risk applications that a rules engine could have cleared instantly, leaving little capacity for the genuinely complex cases that needed human judgment.

On top of all this, FinEdge operated in a regulated lending environment, so any rebuild had to preserve a complete, tamper-evident audit trail of every decision, maintain strict data residency, and stay fully operational throughout the migration. There was no appetite for a risky big-bang cutover that could interrupt live lending.

We approached the project as an incremental strangler-fig migration rather than a rewrite-from-scratch, so FinEdge kept lending the entire time. We stood up a new Laravel API alongside the legacy system and progressively routed individual capabilities — application intake, document handling, underwriting, disbursement — to the new services as each was hardened and proven in production.

The centrepiece was an event-driven approval engine. Each application emits events onto a queue, and a configurable rules engine evaluates credit-bureau data, income verification, and fraud signals to auto-approve, auto-decline, or flag for human review. Roughly 70% of low-risk applications now clear without anyone touching them, while underwriters get a prioritised queue of only the cases that need expertise.

The architecture and engineering decisions that made this work:

• PostgreSQL as the system of record with append-only audit tables, giving regulators a complete, immutable history of every decision and who or what made it.
• Redis-backed queues and caching to absorb traffic spikes and decouple slow third-party verification calls from the applicant-facing request path.
• A real-time Vue applicant dashboard with WebSocket updates so borrowers see their status change live instead of refreshing and guessing.
• Infrastructure on AWS with autoscaling, blue-green deploys, and infrastructure-as-code so the platform scales elastically during campaigns and deploys are routine rather than risky.

We worked in two-week iterations with the FinEdge team embedded in planning, shipping behind feature flags so each new path could be validated against the legacy system before taking real traffic. By the final cutover, the monolith was already handling only a fraction of the workload, making the switch a non-event.