Principal Architect UI/UX. The longest single chapter of the software career, and the one where the web components platform work took shape.
Cox Automotive's suite of products spans 15+ years of acquisitions and internal development. The result is a portfolio of applications built on a wide range of technology choices — different frameworks, different eras, different teams. Keeping that portfolio coherent while continuing to ship is a real architectural challenge.
The question that drove the web components work: how do you build new UI capabilities that work across all of it without picking a winner from the existing stack?
The answer was Web Components. As a browser-native standard, they work in any HTML context — React apps, legacy jQuery apps, server-rendered pages, anything with a DOM. No framework dependency, no build alignment required.
The initial champion case was Micro Frontends: shipping discrete, independently deployable UI features as web components that could be embedded into existing legacy applications without those applications needing to change their stack. A team could ship a new feature as a web component; the legacy host app just dropped in a custom element tag.
This framing — framework agnostic by design, because we have no choice — was the key that made the case internally.
Embedding a web component in a legacy app solves the rendering problem. It doesn't solve the communication problem — the component still needs to coordinate with the host app and with other components that might be on the page.
The solution was a simple pub/sub event bus using mitt.js. The choice of mitt was deliberate: its footprint is negligible (under 200 bytes), it has no dependencies, and it works anywhere JavaScript runs. Dropped into window as a shared channel, it gave both the legacy host app and the embedded micro frontend a way to publish and subscribe to events without either side needing to know anything about the other's internals.
This pattern — components communicating through a lightweight shared bus rather than direct coupling — became foundational to the architecture and carried forward into the autos suite, the funnel apps, and later the MCP action-state work.
As the micro frontend work matured, the framing evolved toward Composable UIs — an extrapolation of the same ideas at a higher level of ambition. Instead of one-off web components embedded in legacy apps, the goal became building UIs assembled from a library of composable, interoperable parts. Each part is a web component. Each communicates through the event bus. The whole can be assembled differently for different contexts without rewriting any of the pieces.
Web components remained the right primitive here for the same reason: composition only works if the pieces are interoperable, and interoperability requires framework agnosticism.
During the same period, Cox Automotive invested in building an Enterprise Design System — a shared visual and component language intended to bring coherence across the product portfolio. The Design System needed to be framework agnostic to some degree, given the same stack diversity that drove the micro frontend work.
The early technical decisions for the Design System were shaped in part through consultation and advisory input, including:
The role was consultant and advisor rather than primary implementor — influencing technical direction at decision points rather than owning the build.
The Cox chapter established the platform patterns that run through all the subsequent framework work: web components as the composable primitive, event bus as the communication layer, Tailwind as the styling system. The autos suite, funnel, sudoku, and tinker reference apps are all built on this foundation — and the YAML-driven UI platform is its logical continuation, pushing the composable/declarative approach further than any framework-specific solution could reach.