From a Nuutown prototype to a real Riviera directory
Every time I've moved, I've had to start from zero: find an accountant, a lawyer, maybe a doctor, someone to fix the washing machine. That's harder than it sounds when you don't speak the language well and don't know who to trust, and I've been through it more than once.
I'd actually designed a solution before. During my UX bootcamp I created Nuutown, a service directory and booking platform for expats. The research was solid and the prototype got good feedback, and then it sat there, because turning a prototype into a working product needed engineering support I didn't have. Riviera Locals is the same problem and the same audience, years later, with tools that let me build it myself.
Codex for the code, Claude for the words
The site runs on Supabase and Astro. This time I used Codex for the code, Gemini for research and data gathering, and Claude for writing, a split that came from noticing what each does well. Compared with the boulder gym directory, I trusted the tools more and cared about the design from the start, where earlier projects had been functional first and pretty later. The first version has filters by city and category, a profile page for every business, and a guide section written to rank for local searches.
When I got stuck on a design decision, I used the models more as a thinking partner than as a source of output. Describing a problem clearly enough to ask a good question about it usually got me most of the way to the answer (and sometimes the most useful reply was a request to be more specific).
Where the Riviera Locals listings come from
Living on the Riviera helped. I spent time in the regional Facebook groups where expats ask each other who to call for tax advice, which English-speaking doctor they trust and which plumber actually shows up. I saved those posts, pasted them into an LLM and had it pull out a first dataset, which was scrappy but good enough to start with.
After that, a crawler gathers listings and reviews, and an LLM reads the resulting CSVs for contact details, service area, languages spoken and signs of quality.
The hard part was avoiding false positives. To find businesses that serve English speakers, the system reads the reviews, and a review saying "they don't speak English" mentions English too. Telling those apart took careful prompting and a lot of iteration, because a wrong signal corrupts the data quietly until someone emails to say a listing is wrong. Working out what counts and where to draw the line was the part of the project I enjoyed most.
Searching the directory by place and by category
People search a directory two ways at once: "accountants in Nice" and "everything in Antibes". In Supabase that became separate tables for services, categories and locations, linked together, and once that model was right the filtering fell into place.
Categories also relate to geography differently. A plumber needs to be near you, while a tax accountant who works remotely can be anywhere, so the search follows rules per category instead of filtering on location alone.
Unlike the boulder gym directory, every business gets its own profile page, which gives Google far more specific pages to index. I'm curious how it reacts to that. Richer profiles with featured placement come later, and the data model already has room for them.
Building a directory for the community I live in
Search volume wasn't why I picked this niche. I wanted to build something useful for a community I'm part of, in the place I live.
Directories take time: you build the structure, add listings, wait for Google to catch up and refine as you go. The data system is good enough that improving it is a steady process rather than a rebuild. The open question is the business side: how local services find their way onto the platform, and what they get from being there.