From quarterly releases to daily deploys for a growing lender

The challenge

The client lends to small businesses and had grown its loan book quickly on a single Ruby on Rails application. That application handled applications, credit decisioning, servicing, collections and reporting. It ran on a handful of hand-configured virtual machines that only two people fully understood.

Releases happened roughly once a quarter, after a weekend code freeze and a long manual test script. A change to a pricing rule could take six weeks to reach customers, which the credit team found hard to accept when competitors adjusted rates weekly.

Two other pressures arrived at once. A new funding partner required stronger evidence of change control and access management. And infrastructure costs had climbed steadily without anyone being able to say which product or team drove them. The engineering team was capable but fully occupied keeping the platform running. They needed an outside view on what to fix first, and help doing it without pausing lending.

Our approach

We started with a three-week assessment rather than a rebuild proposal. Two senior engineers interviewed the credit, operations and finance teams, walked through the codebase and infrastructure, and mapped every release step. The output was a ranked list of risks and a phased, costed plan.

The plan rested on a few decisions:

1. Keep the monolith, shrink it gradually. A full rewrite would have frozen product work for a year. Instead we used a strangler pattern: new capabilities and the most change-heavy domains move into separate services behind the existing application.
2. Fix the path to production first. Before extracting anything, we put the existing application into a repeatable pipeline with automated tests, so every later change was safer.
3. Make compliance a by-product. Change history, approvals and access reviews should come out of the tooling, not from screenshots gathered before each audit.
4. Measure cost per product. Every resource is tagged by product and environment from the first day in the new account structure.

The client's engineers paired with ours throughout. By month four, they were leading service extractions themselves.

What we built

We built a new AWS landing zone with separate accounts for production, staging and shared tooling. Networking, identity and guardrails are all defined in Terraform and reviewed through pull requests. Access runs through the client's identity provider with short-lived credentials, and production changes require an approved pipeline run rather than console access.

The monolith moved onto Kubernetes (EKS) with no functional changes, then gained a CI/CD pipeline in GitHub Actions. That pipeline runs unit and integration tests, dependency scanning and database migration checks on every change, then deploys with automated rollback.

We then extracted the two domains that changed most often. The first was pricing and credit decisioning, rebuilt as a Go service with versioned rule sets that the credit team can review before release. The second was loan event publishing: the monolith now writes events to an outbox table that is relayed to Kafka, so downstream reporting and servicing tools no longer query the production database directly.

OpenTelemetry tracing, Grafana dashboards and alert runbooks cover every service. An append-only audit log records each deployment, approval and privileged access session, and exports straight to the evidence pack the funding partner requested.

The results

Within eight months the team moved from quarterly releases to deploying to production several times a week, and pricing changes now reach customers in days. Deployments are routine enough that the weekend code freeze was dropped entirely.

Infrastructure spend fell by around 28%, mostly from rightsizing, scheduling non-production environments and retiring the old virtual machines. Because every resource is tagged, finance now sees cost per product each month.

Audit preparation that used to take three weeks of screenshots and spreadsheets now takes about two days, because the evidence comes straight from the pipeline and audit log. The client's engineers own the platform today. We stayed on for a short support period, then handed over runbooks, architecture notes and the remaining extraction roadmap.