Skip to content

← Back to list

What CamperRoute is

I set out to organise a camper trip. I ended up designing a product with three modes. This post explains why three were necessary.

3 min read

I set out to plan a one-week camper trip. I ended up designing a product with three clearly separated modes. This post explains why one wasn’t enough.

The context

Planning a camper trip with today’s tools means opening ten of them at once. A map to draw the route. A wild-camping app to find places you can sleep without anyone knocking. Another for diesel prices. A Google Maps list for sights. A notebook to remember the grey-water tank only lasts four days. A Telegram group to check whether that mountain pass clears 3.2 metres.

None of these tools know the user is driving a motorised home — something with height, weight, length, water needs, dumping needs, restrictions in city centres, and a different idea of what “a day” looks like. A day by car can be three towns; a day in a camper is usually one.

The tools that do know are directories — Park4Night, ACSI, Caramaps. They show you where things are. They don’t plan anything for you. The route still lives in a spreadsheet.

The decision

I broke the trip into three phases and treated them as three products that share a model, not as three screens of the same one:

  • Plan. At home, with coffee, on a big screen. Maps full-bleed, AI suggesting POIs, days you can drag.
  • Drive. In the cab, sun on the screen, one hand on the wheel. PWA, geofence, handoff to a real navigation app (Waze or Google Maps).
  • Recall. Back home, dog asleep. Trip telemetry turns into an editorial blog, exportable to PDF, with the photos in the right place.

Each phase is run by a different brain, even when it’s the same person. The planner doesn’t read while driving. The driver doesn’t drag days around. The one recalling doesn’t want to see candidate overnight zones on the map — they want to see where they actually slept.

Diagram of CamperRoute's three modes (plan, drive, recall) connected by a shared data model: route, days, POIs, narratives, telemetry.

Why commit to all three at once. The temptation was to ship planning first and leave the rest for later. No. Each mode validates the others. If planning asks for a value trip mode can’t capture, planning is fantasy. If trip mode captures something planning doesn’t understand, it’s surveillance. If recall needs something neither has stored, it’s a separate journal. Forcing all three to speak about the same thing kills half the technical debt before it even exists.

What CamperRoute is not

To be explicit:

  • Not a GPS. It doesn’t navigate you. It detects that you’ve arrived and hands the next destination off to your usual navigation app. There are apps that do that ten times better than anything I could write; my product talks to them, it doesn’t compete.
  • Not a social network. Your route is yours. If you want to share it, you do so with a signed link that expires — not by pinning it to a wall by default.
  • Not a generic planner. The unit is the camper day, not the tourist day. A 14-day, 1,200-km route makes sense; a 14-day, 8,000-km route doesn’t.
  • Not a mandatory cloud service. Once you’re on the road, the trip runs as an offline PWA. Sync happens when signal returns, not at every step.

What’s next

In the next post I explain why planning and trip mode had to be two visually distinct experiences, not a preference inside the same screen. One is a table next to a map. The other is a single big card with three buttons. Sharing the code is easy. Sharing the chrome would have broken everything.