Overview

A multi-year initiative to scale a cloud-native, serverless loan management platform on AWS for a student and consumer debt company. Wrote Architecture Decision Records, led cross-team coordination across 70 engineers, and built a data-driven scaling roadmap covering FinOps, security posture, CI/CD improvements, and organizational architecture.

Context

A Fortune 1000 student and consumer loan servicer had built a cloud-native, serverless system to manage millions of loans, and was expanding it into a software-as-a-service platform for major financial institutions. The growth target was concrete: the platform needed a credible, executable plan to support millions of active loans while meeting contractual SLAs and holding per-loan costs within a strict ceiling.

I was engaged through AspirationalX to provide deep technical expertise and project management for the scaling initiative. The architecture and the teams were strong. The problem was not weakness — it was that nobody could yet say, with evidence, where the system would break first.

Working with solution architects, domain experts, and product managers, we identified five specific threats to scaling:

  1. Data inaccuracies that generated excessive manual rework
  2. Timeouts cascading across services and compounding errors
  3. Inconsistent observability tooling that made troubleshooting slow and unreliable
  4. Data inconsistencies introduced by retries and parallel processing
  5. Batch processes that could fail to meet volume and SLA demands

The System

The work was less about writing code and more about building a system that could turn an ambiguous mandate — “make sure this scales” — into prioritized, verifiable execution across roughly 70 engineers:

  • Discovery before prescriptions. I reviewed the architecture, the AWS footprint, and the observability stack, and ran interviews and knowledge-sharing sessions with the engineering teams. Scaling blockers were documented as findings with evidence, not opinions.
  • Risks quantified in business terms. Each threat was validated with technical and business stakeholders and expressed in terms of performance, cost, and contractual compliance — the units leadership actually makes decisions in.
  • Architecture Decision Records. I drafted and promoted ADRs to codify serverless and AWS practices, so decisions survived beyond the meeting where they were made and new teams inherited reasoning, not just rules.
  • A dedicated solution-architecture backlog. Scaling initiatives were organized into workstreams in their own tracked project, with dependencies and timelines mapped, so the effort competed for attention as a first-class program rather than a side quest.
  • A steady coordination cadence. Recurring cross-team check-ins three times a week kept alignment and momentum, backed by dashboards, point-in-time assessments, and regular reporting for leadership.

Outcomes

  • A structured, tracked roadmap to millions of active loans was defined and actively executed — with scaling threats addressed before they became production incidents.
  • Executives gained continuous visibility into progress, risks, and outcomes, which changed the conversation from reassurance to evidence.
  • Engineering and product teams aligned on shared priorities, reducing wasted effort across the program.
  • The ADR layer became durable infrastructure: decisions and their reasoning remained legible to teams that joined later.

Artifacts

The working artifacts from this engagement — the ADRs, the dashboards, the scaling roadmap — belong to the client and stay there. The trade-off is simple: showing you a client’s dashboard would prove the work and disprove the judgment. What you can check instead: the engagement came through AspirationalX, my consulting record is publicly verified at Upwork’s highest tier (Expert-Vetted), and the methods described above are documented in the open in From Ambiguity To Operational Systems.

Patterns Worth Reusing

  • Map the system before fixing it. The highest-leverage early deliverable was not a fix — it was a validated list of where the system would break first, in cost and compliance terms.
  • Codify decisions, not just solutions. ADRs turned individual judgment into organizational capability. That is what makes scale survivable without heroics.
  • Make progress legible. Dashboards, cadence, and point-in-time assessments converted a high-stakes, ambiguous program into something leadership could trust and teams could act on.
  • Scaling ceilings are organizational and technical at once. Every one of the five threats had both an architecture component and a process component. Solving either alone would not have worked.