Autonomous Delivery on a Live Consumer Platform Inside a Fortune 50 Enterprise

Client: Rocket Auto (subsidiary of Rocket Companies)

Team: 4 (1 tech lead, 3 full-stack engineers)

Stack: Next.js, React/Redux, NestJS/Node, TypeScript, Elasticsearch, MS SQL (RDS), AWS, Cypress/Percy

The Context

Trusted to Own Delivery on a Live Platform

Rocket Companies was standing up a consumer-facing used vehicle marketplace — Rocket Auto — while its core engineering teams remained fully committed to Rocket Mortgage. They needed a significant amount of engineering capacity that could absorb whole projects, decompose them independently, and ship to production without requiring hands-on oversight from their internal architects.

Their solution was a pod model: self-contained teams that received high-level objectives and owned everything from task breakdown through delivery— four engineers working across Rocket Auto’s full stack, shipping directly to rocketauto.com through their production pipeline.

Rocket was highly selective. The vetting process was rigorous but typical for us: individual technical evaluations of every engineer, background checks, corporate-provided hardware, and VPN access through their security infrastructure. They wanted senior people who could operate autonomously, and they structured the engagement accordingly.

The platform was a multi-tier web application: a React/Redux SPA on the frontend, NestJS/Node services on the backend (vehicles, users, lead dispatching), Elasticsearch for vehicle search and indexing, Microsoft SQL Server on RDS, Informatica ETL pipelines for data ingestion, and Terraform-managed AWS infrastructure. We worked across all of it.

Seller Distance

Geolocation Across the Search Stack

Rocket Auto needed to compute and display the distance between a buyer and each vehicle’s dealer — on the search results page, within vehicle detail views, and inside the featured inventory carousel.

The distance calculation itself was straightforward: Haversine against dealer coordinates already present in the Elasticsearch index. The actual challenge was the data architecture. Vehicle location data originated in Elasticsearch, but the vehicle entity as surfaced to the frontend did not carry geolocation coordinates. The search results page, the vehicle detail page, and the featured inventory carousel each consumed vehicle data through different rendering paths—some server-rendered, some client-rendered—and none included the information needed in their existing payloads.

On the frontend, we traced the data flow through Redux to understand how vehicle objects propagated into each rendering context. The detail page, for instance, read from the Redux store rather than making a separate API call—a design decision that was undocumented and only apparent from the code. We ensured the new distance attribute survived the full serialization path and rendered correctly in both Next.js server-side and client-side rendering contexts.

On the backend, we extended the NestJS vehicle search service with geocoding—resolving buyer locations from either a ZIP code or IP-based geolocation via MaxMind GeoIP2—and augmented the Elasticsearch query to return computed distances. This required understanding how the existing TypeORM entities mapped to Elasticsearch documents and how the ETL pipeline populated those documents from the relational store.

Vehicle Card Redesign

Mobile Responsiveness on a Live Product

A site-wide redesign of the vehicle card component required rewriting the CSS grid layout with responsive breakpoints across five viewport widths, building card hover animations, and implementing image aspect-ratio handling with fallbacks for browsers lacking aspect-ratio support — all deployed to a production site with real traffic.

The work uncovered a rendering issue on iOS: the featured inventory carousel, built with SwiperJS, would intermittently crash the page on certain devices. This is the kind of problem that only appears in production conditions. SwiperJS’s cssMode behaved differently in Safari than in Chrome. The carousel worked in desktop testing, worked in Chrome’s mobile emulator, and failed on actual iPhones. We evaluated several CSS containment and loading strategies before arriving at a configuration stable across Rocket’s target device matrix.

Search Filters

State Synchronization and Edge Cases

Interactive range filters for price, mileage, and year required custom slider-and-text-input components that remained bidirectionally synchronized—typing a value updated the slider, and dragging the slider updated the text field—with validation to handle inverted ranges and values exceeding API limits. A vehicle in the production dataset with over four million miles on the odometer surfaced a hard cap in the search API’s mileage parameter, requiring coordination between a frontend guard and a backend constraint.

We also built the mobile filter experience: a slide-out overlay panel consolidating the desktop sidebar filters into horizontally scrollable filter pills with a scroll-to-top control and loading states tied to the search results refresh cycle. The overlay required careful pointer-event management to prevent the backdrop from intercepting clicks on underlying page elements — a subtle interaction bug that would have been invisible in component-level testing but immediately apparent to a user.

Deployment Notification Tool

Greenfield Tooling for the Organization

Rocket Auto’s daily deployment process — scheduling releases, notifying stakeholders, tracking deployment state, coordinating incident management — was manual. We built the tool that formalized and automated it, designed for adoption across the entire Rocket Auto engineering organization.

The tool was a Next.js application with a React/MUI frontend and a Node.js API, deployed on AWS, with email notifications via Amazon SES. It managed the full deployment lifecycle: scheduling with affected service selection from Rocket’s internal application registry (AppHub), deployment state transitions (scheduled → started → validated or rolled back), configurable incident resolution, email notifications with deployment details, and a searchable deployment history.

The most instructive technical challenge was the PagerDuty integration. The tool needed to create incidents when deployments were scheduled, advance their status through the deployment lifecycle, attach structured deployment metadata (affected services, commit lists, contingency plans), and resolve incidents upon completion.

PagerDuty’s data model did not natively support this workflow. Incidents did not support arbitrary structured metadata, and certain fields could not be updated after creation. Rather than forcing the deployment lifecycle into a model that would not hold it, we designed a layered approach: incident lifecycle management through the REST API, deployment metadata persisted as structured status updates and notes, and a retrieval layer that assembled the complete deployment picture from multiple data sources. The result was a clean abstraction that insulated the rest of the application from the underlying API constraints — the UI presented a unified deployment object regardless of how the data was distributed across systems.

We added Cypress end-to-end tests with Percy visual diffing to protect the UI against regressions from MUI dependency updates, which had a pattern of introducing subtle visual breakage across versions.

Delivery Model

Rocket’s architecture group owned the product briefs, system-level decisions, and quality oversight. We owned everything between the brief and the shipped feature. This structure worked because it aligned with the trust model: Rocket needed teams that could absorb a high-level objective — “add geolocation to vehicle search,” “build a deployment management tool” — and deliver working software in production without creating coordination overhead for their internal team. Their architects stayed focused on system-level concerns. We handled the rest.

What This Demonstrates

We shipped features directly to a consumer-facing platform serving real buyers and dealers. We built internal tooling that the broader engineering organization adopted. We worked across a full-stack architecture — from Elasticsearch queries to React component rendering to greenfield application development — without specialization boundaries.

This is what a senior team operating inside enterprise constraints looks like: absorb the objective, navigate the codebase, ship through the pipeline, and free the client’s internal team to focus on the problems only they can solve.

“We gave BiTE high-level objectives and production access, and they handled the rest. They didn’t need hand-holding or architectural babysitting—they shipped.”