BRUT, the website of a truck that changes address every week

BRUT sells fried bites, crispy outside and melting inside, three recipes and a single sauce, from a truck that parks in a different spot around Tours every week. A customer’s first question is not “what is it?”, it is “where are you this week?”.

The brief came down to four verbs: tell people where to find the truck, make them hungry, collect sign-ups to announce the dates, collect reviews. One constraint shaped everything: I was leaving to spend a year abroad. The founder had to be able to change a date, a price or a photo without me, and without breaking anything.

A home page that reads from top to bottom like a visit to the truck: a video, the ritual (grab, dip, bite), the three recipes, the menu, the locations, the newsletter, the contact. Three versions of this page were built side by side so the client could choose; the third one won.

A showcase site, but one whose entire content lives in a database. The equation to solve: pages as fast as a static site, and editable like a CMS, without paying for a CMS.

The admin is half of the project, and the half the founder uses every week. It comes down to two screens: a dashboard to see how things are going, and content editing to change what visitors see. It uses the site’s visual identity, so that he feels at home rather than in a back office.

The dashboard: everything at a glance

At the top, four figures with their thirty-day trend: newsletter sign-ups, messages received, customer reviews, average rating. Below, the activity day by day, the three forms stacked; clicking a figure isolates its curve. All the calculations are done by the database, one query per block: nothing is counted again in the browser.

Three forms, a single path. Every submission goes through Vercel BotID, an invisible honeypot field and a minimum filling time, then is written to Neon before anything else. Sign-ups are then copied to Brevo, after the visitor has their answer; unsubscriptions come back through a webhook, and a nightly job resyncs everything. There is only one list of subscribers, wherever people sign up.

Reviews come in through a QR code stuck on the truck. The page it opens is neither in the navigation nor in search engines: two minutes, a rating, the recipes tasted. The button to Google reviews is shown to everyone, whatever the rating: Google requires it, and it is more honest.

• +
  A video that really starts.

  Two encodings (HEVC for Retina screens, H.264 as a fallback), a version turned a quarter turn for phones in portrait, a blurred poster image. And an iOS bug tracked down: a video element without a source in the server render made the native play button appear.

• +
  Photos prepared by hand.

  1,600 px wide for dense screens, sRGB profile, mozjpeg compression: a 254 MB source video became about fifteen megabytes.

• +
  Functions in Frankfurt,

  next to the database, rather than in the United States by default.

• +
  Two audits before calling it “done”.

  Performance and security first (a critical vulnerability fixed by a Next.js update, security headers), then a regulatory audit: a complete privacy policy, a consumer mediator, the service providers named.

• +
  Local SEO.

  Structured data for a food establishment and its menu, generated from the content, and a sitemap dated from the last publish.

A food truck’s site is read standing up, on a phone, with the kind of 4G you get in a car park. So I measured it in bad conditions: Lighthouse, an emulated mid-range phone, simulated slow 4G, three runs per page in production, and the median. Then I lightened what was heavy, and measured again.

For what goes beyond the admin, I prepared a handover to someone who does not code. A file of instructions for a coding assistant: speak without jargon, announce before acting, one question at a time, always suggest the admin before touching the code, and never put anything online without an explicit “yes”. All it takes is to open the folder and write “put it online” or “change the price of the box of 5”.

Behind it, the safety net: documentation with one page per topic, a log where each request fits on one line, and 137 tests (unit tests, then journeys on desktop and phone) run on every push, plus smoke tests on the live site after each production release.

My goal: making my clients autonomous.

• +
  Show rather than describe.

  Three versions online side by side settled in a day what a meeting would not have settled.

• +
  The simplest often wins.

  An image instead of an interactive map, bold instead of a rich text editor.

• +
  The client’s feedback is the roadmap.

  The log holds dozens of them, each recorded on one line with the files it touched.

• +
  Documentation is part of the deliverable.

  It is what makes the site autonomous, much more than the code.

• +
  Measure before optimising.

  Three runs, a simulated slow phone, and leads dropped when the gain cost more than it brought.

Photos, video and map: their authors, credited on the BRUT site.