CarpHD
- Data intensive
- UI/UX case study
A cross-platform automotive platform offering advanced dealer services and buyer tools.
Who it was built for
Built for
CarpHD
An automotive platform that earns from dealers. Research and comparison tools bring buyers in; quote requests and service bookings are what dealerships pay for.
The brief
Car ownership is spread across a dozen websites, none of which know what the others said. Holding research, purchase and maintenance in one place is what makes the audience worth anything to a dealer.
What we delivered
Specifications that can actually be compared
Live dealer inventory
Quote requests to verified dealers
Ownership after the sale
Where the growth comes from
Attention early, revenue later
Dealers pay for intent, not clicks
Maintenance keeps the account alive
The business analysis
CarpHD is a two-sided business wearing the clothes of a consumer product. Buyers get research and comparison tools free; dealers pay for quote requests and service bookings. That means every consumer feature is really an acquisition cost, and the only question worth analysing is whether the audience it buys is worth more to a dealer than the audience a classifieds site already sells them. The answer turns on intent, and intent is measurable in a way that traffic is not.
- Lifecycle stages held in one account
- 6
Model · Counted from the flow documented in this case study.
- Account lifespan the maintenance features buy
- Years
Model · Structural claim about the product's retention mechanism.
The showroom stopped being where decisions are made
Cox Automotive's buyer journey research records the average vehicle buyer visiting just two dealerships, down from 2.7 in 2016 1, and the whole purchase process taking about 14 hours 19 minutes from research to close 2. Both numbers say the same thing. The shortlist is decided before the buyer is in the room, so the commercial value has moved to whoever is present while it is being formed.
Dealerships visited per buyer
- 2.7
- 2.0
- 2016
- Latest
Intent, priced properly
The revenue event is a quote request. Everything before it is unpaid, and everything after it is retention. Ranking the funnel by what a dealer would pay for each signal makes the design of the product legible.
| Signal | What it tells a dealer | Commercial value |
|---|---|---|
| A page view | Someone is curious | Close to nothing, and infinitely available elsewhere |
| A saved comparison | Two specific models are on a shortlist | Moderate, and a good retargeting trigger |
| A configured comparison | Trim, budget and priorities are settled | High — the buyer has done the hard thinking |
| A quote request | A named buyer wants a price on a specific vehicle | The billable event |
| A service booking | An owner is spending money on a car they already have | Recurring, and it keeps the account alive |
Where the platform's revenue potential sits by lifecycle stage
- The single billable moment. Everything upstream exists to produce it.
- Recurring dealer revenue, and the reason the account does not go dormant after purchase.
- Paperwork handled in the portal is a referral surface as well as a convenience.
- The most-used part of the product and the least directly monetisable.
Model · Our weighting of the six lifecycle stages in this case study by dealer willingness to pay. Illustrative — no revenue data was shared with us.
Live inventory is a trust problem disguised as an integration
The most damaging thing this product can do is show a car that has already been sold. It costs the buyer a wasted enquiry, costs the dealer a bad conversation, and costs the platform the credibility it charges for. WebSocket synchronisation between dealer management systems and the consumer front end is in the build because inventory accuracy is the marketplace's only real asset.
The ownership lifecycle, and where it bills
Research
Compare
Request a quotedecision
- ↳ Vehicle already sold → surfaced before the request, not after
- ↳ No verified dealer in range → request held rather than sent badly
Paperwork
Own
Resell
The stack, by responsibility
Consumer clients
- Next.js 14
- React Native
- TypeScript
- Tailwind CSS
Comparison state
- Jotai
Application services
- Node.js
- Express
Specification normalisation
- Vehicle specification providers
- Normalisation parsers
Inventory edge
- WebSockets
- Redis inventory cache
- DealerTrack
System of record
- MongoDB
What we would watch
| Risk | Why it bites | Early indicator |
|---|---|---|
| Cold-start on the dealer side | Buyers will not request quotes nobody answers, and dealers will not pay for a platform with no buyers. Two-sided liquidity is the first hard problem | Quote requests with long or no response times in specific regions |
| Specification data licensing | Normalised comparison depends on several third-party vehicle data sources, each with its own commercial terms | Comparison coverage gaps appearing by market rather than by model |
| Inventory staleness | A sold car shown as available damages both sides at once, and the damage is asymmetric — the dealer forgives it, the buyer does not | Quote requests against vehicles that are no longer in stock |
References
The ownership lifecycle
Research
Recommendations against lifestyle and budget, specs parsed for thousands of models.
Compare
Side-by-side technical comparison, processed in parallel so it stays fast.
Quote
Best-price requests routed to verified dealerships.
Paperwork
Loan and insurance documentation handled inside the portal.
Own
Mileage and health tracked, maintenance predicted from real driving data.
Resell
Depreciation tracked to flag the sensible window to sell.
Who it is for
Prospective buyers
Current owners
Enthusiasts
Reference
Recommended case studies
Want the version of this built for your business?
Fifteen minutes with the people who shipped it. No deck, no account manager.