A dealership platform the owner could run without me

The situation

An independent car dealership with a real inventory that changed weekly, and a web presence that amounted to photographs posted to social media. Buyers were searching, finding nothing, and phoning to ask what was in stock.

The brief was a website. The requirement underneath it, which came out only by asking what a normal week looked like, was that stock arrives and leaves constantly and the person who knows about it is the owner, on a phone, in the evening.

The requirement nobody states

Most small business sites die the same way. They launch beautifully, then the content goes stale, because updating it requires either a developer or a content system too fiddly to use on a phone at nine at night. Six months later the site lists cars that sold in March, and it is now doing active harm.

That is a design failure, not a client failure, and it is entirely predictable at the moment of building. So the constraint I set was: adding a car takes under two minutes on a phone, or the project has not succeeded.

That decision cascaded through everything. Photographs upload and compress without thought. Fields that can be derived are derived. Nothing is mandatory that a person standing next to a car cannot answer immediately. Marking something sold is one action from the list, not a form.

Why it is server rendered

The listings are the product. Somebody searching for a specific model and price range needs to find the actual listing, which means every listing needs a real URL serving real HTML with the price, the specification and the photographs in it.

A listing rendered by client side JavaScript is a listing a search engine can index in principle and struggles to rank on the attributes that matter. For a site whose entire job is being found, that is the whole game.

Each listing therefore has its own page, its own title and description built from the actual vehicle, and structured data describing it as a product with a price. The sitemap regenerates as stock changes, so a car added on Tuesday is submitted for indexing on Tuesday rather than whenever somebody remembers.

What I got wrong

I built a rich filtering interface first: multiple simultaneous filters, a price slider, live result counts. It was the most interesting part of the work and it was the wrong priority.

Watching real sessions, most people arrived from a search for one specific thing and wanted that thing. The filter was used by a minority, and the fastest path for the majority was a good search box and clean listing pages, which is where the effort should have gone first.

The general lesson, which I have applied since: build for the traffic you will actually get, not the browsing experience you imagine. Arrival from search is a different behaviour from browsing, and it wants different things.

Where it landed

Stock stays current, which was the actual objective, because the owner updates it without me. Listings get found. The phone calls changed character, from what do you have to I want to see the one on your site.

What I would do differently

I would have spent the filter time on the listing page instead, and I would have set up the measurement before launch rather than after, because the first month of search data is the most informative and I do not have it.