Honda Automobiles Shopping Tools

The engagement

Honda Motor Company partnered with RPA from late 2019 through 2023 to rebuild the entire shopping experience at automobiles.honda.com — five frontend products, sequenced one at a time as the contracts came through, each architected from scratch but each carrying the same engineering DNA: TypeScript discipline, MobX-state shape, custom React component libraries, hand-rolled data-driven filter engines that respect the data instead of dictating to it, strict WCAG 2.1 AA compliance, performance budgets measured in tenths of a second.

RPA’s leadership had a long history with INNOV8 from prior tenures at Genex and MXM — the same Honda + Acura people, three agency badges, same trust in the work. The five tools we built for Honda over the RPA tenure all sat on the consumer-facing shopping side: Build & Price (the configurator), Search Inventory (the dealer-stock filter UI), Dealer Locator (geographic search), Current Offers (financial-incentive surfaces), and Payment Estimator (the calculator). Each was its own statement of work under a multi-year master services agreement; each was led by Mike from architecture through implementation through accessibility hardening through launch handoff.

“We need to bring in the Wolf.”

That was RPA’s framing on the call when they brought us in for the first of the five tools. (Pulp Fiction reference: the calm fixer who shows up when the problem is too complex for the room. The room appreciated the candor.)

Mark Bieschke — CTO at RPA during the entire 2019–2023 Honda tenure, the primary stakeholder on every tool, and the source of the metrics that landed publicly — had been one of the people INNOV8 worked with at Genex and at MXM before RPA. Three agency badges, one continuous working relationship, the same trust in the work. (His LinkedIn recommendation lives on the recommendations page if you’re curious about the framing from the other side of the table.)

The 2019–2023 engagement carried forward two decades of accumulated knowledge about how buyers actually use a vehicle-shopping experience and where architectural shortcuts catch up with you later. The technical lineage was direct: the centralized state engine, the deep-linkable URL encoding, the data-driven filter pattern, the rules engine with conflict resolution — all surfaced first in earlier Acura engagements (2009 Acura.com redesign + Acura Build & Price) and re-implemented on the 2020+ Honda stack as each tool came online. The Honda shopping tools were the surface that got the public metrics; the discipline behind them was twelve-plus years deep.

The relationship is the work.

Build & Price (2019–2020)

The first of the five. Live at automobiles.honda.com/tools/build-and-price.

Honda’s existing configurator was antiquated, slow, not fully responsive, and didn’t match the new design system RPA had just put in place for Honda. Loading times were measured in multiple seconds on the primary entry points; mobile-first traffic was friction-heavy; conversion analytics showed buyers abandoning the configurator mid-flow before a single dealer-locator click ever fired. The BAP rebuild kicked off the four-year engagement.

The approach

One architect-engineer. Six months full-time. The BAP rebuild was a solo delivery — Mike from architecture through implementation through accessibility hardening through launch handoff. INNOV8 was the agency on paper; the work itself was one operator running the playbook.

The Build & Price tool is a state-graph problem masquerading as a form. A buyer’s selections — trim → exterior color → interior → packages → accessories → financing summary — compound at every step. Each choice ripples through derived state (price, eligible options, valid combinations, dealer availability) that has to stay in sync across breakpoints, deep links, and the “save my build” flow that lets buyers return later from a different device.

Underneath the UI sits Honda’s long-lived proprietary client-side rules engine — a JavaScript class that ingests model-year data and generates the validity-and-conflict rules for every option combination Honda’s product team publishes. INNOV8 didn’t build the rules engine itself (Honda’s team owns it; it predates our engagement). What we built is the UI + interaction orchestrator layered on top of the engine’s API: the conflict-resolution surface that catches a buyer’s incompatible selection mid-flow, the affordances that explain which trim or package needs to change, the deep-link encoding that keeps the engine’s state in sync with the URL, and the animation choreography that makes the cascading invalidations feel intentional rather than glitchy. The orchestrator pattern itself we’d solved before in prior-generation car configurators (Acura, Ford, Lincoln); the Honda engagement brought it forward on a modern stack, layered on Honda’s engine.

We built it on TypeScript + React + MobX, with SCSS Modules for component-scoped styling and Jest + Enzyme for the test layer. The stack matched what RPA’s team could read and extend after handoff — MobX over Redux because that was their existing experience; Jest + Enzyme over Testing Library for the same reason; SCSS Modules over styled-components for lighter compiled output and a bias toward semantic class names + the cascade. Picking what the team can run with is the senior call.

The architecture isolates the selection graph from the presentation layer so desktop, tablet, and mobile renderings share the same state model but ship breakpoint-appropriate UI. A custom URL-state engine encodes the full configurator selection into deep-linkable hashes, so any build is shareable + restorable from any device. Accessibility was treated as architecture: keyboard tab order, focus management on state changes, screen-reader narration of price + selection updates, and color-contrast adjustments to Honda’s brand palette were all designed in from the architecture review onward, not patched on at the end. RPA’s dedicated accessibility team — with the hardware + JAWS + screen-reader matrix to actually verify it — ran every major milestone through their audit pipeline alongside our own axe + Lighthouse runs.

The outcome

The rebuilt configurator launched mid-2020 and is still running in production today, untouched — six-plus years after the initial ship, serving fresh model-year data every year without architectural changes. The strongest signal sits in what happened next: RPA temporarily lost the Honda account in 2023, and another agency held it for three years before RPA won it back in April 2026. The code we shipped survived the entire agency transition. Whatever team took over inherited a frontend they didn’t need to rewrite.

The headline numbers:

• Largest Contentful Paint dropped from 4.2 seconds to 0.8 seconds across the configurator’s primary entry points, consistent across breakpoints — an order-of-magnitude improvement that moved the experience from “wait through the loader” to “interactive immediately.” Verified across Lighthouse, real-user monitoring, and synthetic tests.
• Estimated $4.2M in annual attributable revenue lift from the conversion improvements the performance + accessibility work unlocked. The configurator sits at the bottom of the purchase funnel; making it fast and usable on every device directly affects dealer-lead volume.
• WCAG 2.1 AA compliance verified by RPA’s dedicated accessibility team alongside automated axe + Lighthouse passes, across keyboard navigation, screen-reader narration of price + selection changes, focus management on state updates, and color contrast against Honda’s brand palette.
• Multi-breakpoint parity: the same state model, the same accessibility patterns, the same performance budget on desktop, tablet, and mobile — not three forked codebases pretending to be a single experience.

The four levers that brought the 4.2-second number down, in order of impact: a centralized state engine that eliminated render-cascade waste; deep-linkable URL state that turned every shareable build into a deterministic restore path with no probe queries on load; asset preloading + optimization keyed to the most-likely-next user action; and clean semantic HTML+CSS that browsers could parse without bailing into slow paths. None of those are 2020-novel ideas. The novelty is shipping all four together with the discipline to leave them in place six years later.

Search Inventory (2020–2021)

The second tool. Live at automobiles.honda.com/tools/search-inventory.

Search Inventory is the surface where a Honda buyer narrows the national dealer inventory down to the specific cars they actually want. Price range, number of seats, number of doors, exterior colors, drivetrain, fuel economy, packages, trims — any axis a buyer might care about, the tool can filter on. The engineering interest isn’t the filter UI itself; it’s the data-driven filter engine underneath.

The filter definitions don’t live in the application code. They arrive at runtime via AJAX-loaded JSON that the engine ingests and renders against — which means a new filter axis (a new exterior color category, a new financing-band filter, a new fuel-economy bracket) ships by updating the data contract on the backend, not by deploying frontend code. The engine renders whatever the data shape dictates, validates the active selections against the live inventory, animates the filter-card grid as cards drop in and out of the result set, and keeps everything ADA-compliant under the hood. Filter changes are fully animated; vehicle cards transition in and out of the result set with intent rather than appearing to flicker.

The backend APIs that surface dealer inventory weren’t part of the engagement — that work belonged to a different team under a different contract. Search Inventory was a pure frontend effort that integrated against the existing APIs. The challenge wasn’t the data plumbing; it was architecting a complex filter application that was fully responsive, strictly ADA-compliant, performant on mid-tier mobile devices, and flexible enough to accommodate filter definitions Honda’s product team would change month-over-month without a frontend deploy.

The filter engine pattern landed first on Search Inventory and resurfaced on Current Offers later in the engagement — same architectural shape, same engineering DNA running through both.

Dealer Locator (2021)

The third tool. Live at automobiles.honda.com/tools/dealership-locator.

Dealer Locator is the geographic-search surface — find Honda dealers within X miles of a zip code, see hours and contact details and services offered, drill into a dealer’s specific inventory. The dealer-detail page is full-featured: hours, contact, services, and an inventory link that deep-links back into Search Inventory, which reads the dealer’s id on load and pre-filters its dataset to the selected dealer’s stock.

The engineering anecdote worth telling lives in the mapping component. Maps surfaces in 2020 were a vendor-lock-in hazard: Google Maps, Bing Maps, Mapbox, Leaflet, MapKit — each with its own SDK shape, its own pricing model, its own geo-precision quirks. We architected the mapping component using the Adapter + Facade pattern over the third-party SDK, so the application code never talks directly to the vendor’s API surface — it talks to our own thin facade, and an adapter behind the facade translates to whatever vendor SDK is mounted underneath.

Lucky we built it that way. Mid-engagement, Honda needed to switch the entire mapping surface from Google Maps to Bing Maps — pricing, contract reasons, doesn’t matter. The swap was minimal effort: ship a new adapter, point the facade at it, leave the rest of the application untouched. The geographic-search UX, the dealer-detail surface, the URL-hash-based deep-link contract with Search Inventory — none of it knew or cared that the underlying vendor changed.

Other affordances: request-a-quote integration that surfaces a dealer-specific contact form without ever leaving the locator surface.

Current Offers (2022)

The fourth tool. Live at automobiles.honda.com/tools/current-offers.

Current Offers surfaces the active financial-incentive campaigns — lease specials, low-APR financing, model-specific incentives, special-program offers (e.g. financing programs for US military buyers). It’s the bottom-of-funnel surface that catches a buyer who’s narrowed their model selection on Search Inventory and is now comparison-shopping the way Honda is willing to sell them the car.

Current Offers is where the data-driven filter pattern from Search Inventory comes back — same architectural shape, fresh implementation, configured against a different data contract. Buyers filter offers by model, by purchase type (lease vs. finance vs. special program), and the purchase-type selection updates the available payment-range filter so a lease buyer sees lease-monthly-payment ranges while a finance buyer sees finance-monthly-payment ranges. The filter engine doesn’t care about the difference; it renders against whatever the data shape says is available.

The complexity that wasn’t in Search Inventory: offer lifecycle. Offers expire. Offers vary by region. Offers can be overridden at the dealer level. Current Offers integrates against the backend offer-management surface to surface current-pricing with the right expiration handling and regional accuracy — a Tampa buyer doesn’t see the Phoenix incentive, and a buyer comparing offers on Tuesday doesn’t see the special that ended Monday at midnight.

Payment Estimator (2023)

The fifth and final tool of the engagement. Live at automobiles.honda.com/tools/payment-estimator.

Payment Estimator is the calculator that turns “what does this car actually cost me per month?” into a concrete number. It ties together the model selection (from Build & Price), the dealer inventory price band (from Search Inventory), the active financial incentive (from Current Offers), and the buyer’s down-payment + term-length + credit-band inputs to produce an estimated monthly payment. It’s the surface where the whole toolbelt’s data starts to add up to a purchase decision.

Smaller scope than the four tools that preceded it — a calculator UI doesn’t carry the same architectural surface as a configurator or a filtered-inventory app. But it closes the loop: Build & Price spec’d the car, Search Inventory found where to buy it, Dealer Locator found a dealer to talk to, Current Offers surfaced the active incentive, and Payment Estimator answered the last question any buyer asks before they pick up the phone.

The same engineering bar — TypeScript, MobX, WCAG 2.1 AA, mobile-first responsive — applied here too. Five tools, four years, one engineering team, one client. The relationship is the work.