Changing the system while consumers kept using it
At Rocket Mortgage, my work included rebuilding a legacy loan-approval service as a .NET API on AWS and moving consumers away from older services. The work extended beyond implementing the replacement: consuming teams needed to keep operating while integrations changed.
The loan-approval rebuild reduced the user workflow from approximately 60 seconds to approximately 5 seconds. That is a workflow measurement, not a claim about an individual API request or a benchmark of .NET itself.
Compatibility and coordination
I owned API contracts used by more than ten consuming teams. For many changes, I coordinated directly with those teams and implemented backward-compatibility logic so migrations could happen piecemeal.
That separates two responsibilities that are easy to collapse into “built an API”: changing the implementation, and managing the interface other teams rely on. A replacement service was only part of the migration; consumer adoption also had to be coordinated.
Retiring the old underwriting path
In the underwriting-information domain, I moved consumers to new services and retired the old path. The outcome was not simply another service running alongside the legacy implementation: it included removing the dependency that consumers had previously used.
This work is described separately from the loan-approval rebuild. The public summary does not assume that every migration belonged to one initiative or followed the same implementation.
Integrating document generation
The team also maintained an on-premises solution that produced document webforms. My change integrated the existing in-house document service and sent documents through that service instead.
The contribution here was the integration and the replacement of the team-maintained path. It was not the creation of the company’s shared document platform, and this account does not attach an unverified document-volume number to it.
Reliability and observability
Vendor outages exposed failure paths that could stop progress for another vendor. Those paths were triaged and fixed, and we created a standard playbook for handling vendor outages. I also built Dynatrace dashboards with custom OpenTelemetry metrics that tracked why loans were sold to particular vendors.
These were separate pieces of operational work: fixing the failure paths, making the response repeatable, and exposing decision information. This summary does not imply an automatic failover mechanism or a measured period with no recurrence.
Evidence and scope
This summary covers engineering responsibilities and outcomes. Employer source code, service names, and internal architecture are not published here.
The public description stays at the level of responsibilities, compatibility decisions, and outcomes. It does not infer a queue topology, retry policy, reconciliation algorithm, or deployment strategy from the technology names alone.