Projects / Connected Dealership Platform
A connected dealership platform
How dealership operating experience shaped shared records, reusable components, and software across the guest journey.
- Status
- Earlier application · Beaverton Toyota
- My role
- Operating concept and architectural direction; implemented with developers
- Stack
- Angular · Java and Spring Boot · MongoDB
- Integrations
- PBS · VinSolutions/Cox · Chrome Data
On this page
The guest experiences one dealership
Earlier work · Beaverton Toyota
The application I designed grew from a practical problem: departments were working with parts of the same guest relationship, while information and responsibility stopped at their boundaries. The goal was to make the work visible and carry information forward.
This is my earlier, independently owned application. It is separate from the Cam Clark Opportunity App. My subsequent work draws on the experience and architectural concepts developed here.
My role
I defined the operating concept, connected workflows, and architectural direction, and worked with developers on implementation. The design reflects my dealership leadership and computer-science background. Development was a collaborative effort; this account does not attribute every line of the historical code to me.
How the work connected
Prepare and recognize the guest
Appointment and service information helped the team prepare before arrival. License capture supported guest information entry, while the showroom board made arrivals and consultant activity visible to managers.
Present choices consistently
Reusable vehicle, trade, payment, ownership-product, and accessory components supported a guided purchase conversation. Internal workspaces and guest-facing presentation had different purposes and interfaces.
Carry the promise into fulfillment
Accessory selections were tied to the deal and exposed to Parts for tracking and follow-through. They were designed as inputs to a connected workflow, rather than an isolated accessory catalog.
Make performance understandable
Salespeople could review production, ownership-product results, goals, and compensation information. This was earnings visibility and a handoff to payroll, rather than payroll processing itself. The documented ownership index related credited products to credited vehicles.
The engineering behind the experience
- Angular: modular employee workspaces and guest-facing presentation, with reusable interface components.
- Java and Spring Boot: application services, integration logic, and domain behavior.
- CalculationCommon: shared models, repositories, and calculation-related utilities used across services.
- MongoDB: application records and operational persistence.
- PBS, VinSolutions/Cox, and Chrome Data: integration components connecting dealership and vehicle information.
- AWS, Google Cloud build workflows, and GitHub: infrastructure, delivery, and source management.
These choices describe the historical application. Future versions can preserve the operating concepts while choosing a different technology stack.
What the evidence establishes
Archived documentation, interface images, and source review show the modules and integration implementations described here. The review found PBS read and write implementations and CRM integration code. It does not establish that every implemented endpoint was connected to a live screen or successfully executed in production.
The detailed technical archive remains separate from this public overview. Customer records, credentials, and internal operational materials are not part of this case study.
What carries forward
Shared records, reusable components, visible responsibility, and a coherent guest experience remain central to my work. Ford Journey is a design exploration of those concepts; it is not a claim that a new production platform has already been delivered.