02 / CarMax / Developer experience

Keep building. Even without a backend.

Frontend development should be able to move forward while backend work is still in progress. I designed and implemented Demo Mode for the CarMax Auto Finance frontend, including an in-app response configurator that gives developers and QA control over the endpoints the interface calls.

Organization: CarMax
My role: Senior Software Engineer
Focus: Developer experience

A CONTRACT. TWO WAYS TO BUILD.

React frontend

OpenAPI contract

Mock responsesMSW / Demo Mode

Live servicesBackend APIs

Simplified workflow

Inside Demo Mode

One experience. Every response under control.

The customer-facing account stays visible while the developer drawer maps every frontend request to a configurable mock. Engineers and QA can choose response scenarios, status codes, query-string overrides, and response latency without waiting on a live service.

Open Demo Mode

CarMax Auto Finance Demo Mode account dashboard with a simulated vehicle, payment amount, and account balance — 01 / Product surfaceA realistic account state, ready on demand.
The visible Demo Mode label and simulated account data make the environment clear and repeatable for development, QA, and product reviews.

CarMox Response Configurator drawer listing payment API endpoints and their configured HTTP response codes — 02 / Endpoint catalogThe frontend’s API surface in one drawer.
Responses are grouped by domain, so a developer can find and adjust the exact request the current interface makes.

Expanded Demo Mode response handler showing selectable success and error scenarios for a payment endpoint — 03 / Scenario controlSuccess, failure, and edge cases without backend setup.
Each handler can expose named mocks, HTTP outcomes, latency, and request-aware response behavior for fast, reproducible testing.

Screens show a simulated Demo Mode account. Names, account values, and payment data are mock content.

Start from an agreed contract

I used Mock Service Worker to provide realistic mock responses aligned to an agreed OpenAPI specification. That common contract kept the mocked experience connected to the API the team was building.

Implemented API mocking with Mock Service Worker.
Aligned realistic responses to the OpenAPI specification.
Enabled frontend work without a live backend.

Put response control inside the product

A developer control in the header opens the CarMox Response Configurator beside the customer experience. The drawer organizes every frontend endpoint by domain and makes its active response visible, so engineers can change a scenario while seeing the exact interface it affects.

Selected named success, validation, and failure responses per endpoint.
Adjusted response latency to exercise loading behavior.
Supported query-string overrides for shareable, reproducible scenarios.

Make it useful beyond development

Demo Mode supported more than writing components. The team used it for QA scenario testing and stable product demonstrations, giving the same environment a role across development and review.

Supported daily frontend development.
Provided mock scenarios for QA testing.
Supported product demonstrations independent of backend availability.

Build a shared way of working

The team adopted Demo Mode for daily use. Frontend and backend development could proceed in parallel, while QA and product stakeholders could use the mocked experience for their own work.

The outcome

Adopted team-wide for daily development, QA scenarios, and stable demonstrations without a live backend.

Next project