BringVan

The problem

Finding a mover in the UK means searching a town name and landing on a page of paid ads or a directory that has never heard of your postcode. Comparing firms is guesswork, and the good local operators are invisible unless they buy their way up.

The demand is intensely local: people search "removals in <town>", not "removals". That shape of demand rewards a site that has a real page for every town, which is a content generation problem before it is a product problem.

What I built

A directory whose surface area is generated rather than authored: nested routes produce a page per country, per location and per moving company, with a sitemap index assembling the lot and structured data on every company page.

Search resolves what someone types against a locations endpoint rather than a geocoder, so "Oxford", "OX1" and "Oxfordshire" all settle onto a canonical location slug. That slug is what filters the movers query, alongside rating and price band.

The commercial signal is contact attribution: every phone, email, maps and social click is recorded against the mover and the source it came from, which is what makes the directory measurable rather than decorative.

Decisions I'd defend

Search does not fail silently. When someone types a place the system cannot resolve, the query is sent with a flag marking the location unresolved, so unserved demand is recorded rather than discarded. Over time that is a map of where to recruit movers next.

Location resolution deliberately went through an autocomplete endpoint rather than a postcode geocoder. A geocoder returns coordinates; what the directory actually needs is the canonical slug of a place it already has a page for, and matching to that up front keeps every downstream URL stable and indexable.

Where it is now

Live, with real movers listed and the generated location and company pages indexed.