Running a business from a van

I'm writing this from Spain, a couple of weeks into running my business from a campervan while on parental leave with my wife and our baby.

The van is a self-built Ford Transit we call the Hoff, after its number plate. It's 4.86 metres long, which matters later. It's not a big space, and it's not a quiet office. It's also where most of my work has happened since the end of August.

This isn't the story of the agents that build things while I sleep. It's the practical side: what broke when the office became a van, and what I changed. Most of it turned out to be about one thing. My whole setup quietly assumed a laptop that was always on, plugged in and connected. A van has none of those.

Why a van

The short version: we wanted to travel while our baby is small, and I wanted to keep building. I'm on parental leave, so the business isn't my full-time job right now. But AI Ops, my consultancy, and the products under the Remyn brand still need decisions, and I wanted to find out whether a one-person business with a lot of AI behind it could keep moving from the road.

My working model is simple. I make the decisions and review the results. A set of AI agents does most of the carrying out. That only works if the agents can keep going without me sitting at a desk, which is exactly what a van tests.

The test trip: Croyde, 21 to 24 August

Before committing to weeks abroad we did a long weekend in North Devon, the first family camping test.

The van didn't make it easy. It had a battery fault that wouldn't clear, and we made the whole round trip on a jump-starter as a backup. That's the kind of thing you want to discover a few hours from home, not on a Spanish hillside.

On the work side, the weekend was quiet, because the setup was still running on my Mac at home. That was about to become the problem.

The lid that stopped everything: 4 to 7 September

In early September we went camping again, and I closed my MacBook for the weekend.

At the time everything ran on that Mac: the program that connects my AI to WhatsApp, the AI session that answers there, and the scheduled jobs that send me a daily brief. When the lid closed, all of it went to sleep.

From the evening of 4 September to the afternoon of 7 September, 112 messages went unanswered over 66 hours. The briefs stopped too. Nothing was lost, because WhatsApp keeps every message, and when I opened the lid it all came through at once. My setup then had to work back through the gap and fill in what it had missed: 110 entries in one pass.

My first instinct was to treat it as a bug, but it was the setup working exactly as designed, on a machine that was designed to sleep when you close it. I wrote the root cause down plainly: Mac closed, so everything that lives on the Mac sleeps. The cheap fix for a weekend was to say in the chat beforehand that the AI is off until the lid opens, so the silence is expected.

The real fix needed a bigger decision.

The Mac stays off

On 21 September, two days before we sailed, I set the test for the trip in one line: "I want me and [my wife] to be able to have the same functionality or better functionality as we do currently with the Mac, but just with the Mac off. That's the simplest test."

That sentence did a lot of work. It meant every tool, every scheduled job and every connection had to run somewhere other than my laptop. The list of what the Mac did became the checklist: each item either works without it, has a named replacement, or announces itself as a gap. "Or better" never makes up for something that got worse.

I also withdrew an option I'd been tempted by, keeping the Mac awake in the van as a fallback. There is no version of this plan that needs the Mac on. If something only works with the laptop open, it doesn't work.

Where everything went instead is a small rented server I call the box. It costs a few pounds a month, runs all the time, and I reach it from my phone. How we built it is its own story, and one I'll write up once it's settled. For the van, what matters is that the always-on parts left the laptop.

The ferry that looked full

The trip itself nearly didn't get booked properly.

My assistant was doing the legwork on ferries to northern Spain. It checked availability for the sailing we wanted and reported it full all weekend. That was a real problem: we had a narrow window, and the alternatives were worse.

On the Monday morning it turned out the sailing wasn't full at all. My assistant had taken the van's length from an old reference document that said 6 metres. At 6 metres there was no space. At 4.86 metres, the van's real length, there was. I told it so in fairly plain terms, it re-checked, and we booked Plymouth to Santander on 23 September, back from Bilbao on 17 October.

The lesson I logged is one I'd give anyone using an assistant for bookings. For any physical fact that decides a booking (vehicle size, weight, passport dates), ask the person once and write the answer down with where it came from. A document is not the owner. It's very easy for an AI to find a plausible number in your files and use it with complete confidence.

It also drifted for a while towards planning a different trip altogether, south to Portugal, when I'd said the aim was the Basque Country. Same root: it filled a gap with something plausible rather than checking.

Working on a hotspot

In Spain the connection is my phone's hotspot. That's fine until I walk away with the phone.

On 1 October a check on the Mac's network showed it failing to look up web addresses in 382 out of 382 samples. The likely cause was simple: the hotspot dropping whenever I left the van with my phone in my pocket. When the Mac lost its way to GitHub (where my code lives), the box had to take over the agent factory, and the first handover ran on out-of-date settings. That needed fixing too.

The practical consequence is that I can't treat any single connection as reliable. The box has a proper wired connection in a data centre. My phone has whatever signal the campsite has. The setup has to cope with me disappearing for hours, and it increasingly does.

The phone is the way in

On 28 September I was abroad on a hotspot and an agent proposed restarting the service that connects my phone to the box. It was a sensible fix for a real fault. It was also the only way I could reach my setup at all. If the restart had gone wrong, I'd have been locked out from a campsite with no laptop to fix it.

I put a hold on it: "don't do anything with the phone server at the moment." The hold stood until I lifted it.

That's a decision I'd recommend to anyone working remotely with AI. Know which single thing you depend on to get in, and protect it. Fixes to that one thing wait until you're somewhere you could recover from a mistake.

The video that never arrived

On 26 September I filmed a walkthrough of the van with commentary and sent it to my AI on WhatsApp, asking for screenshots every few seconds. I sent it twice. Neither arrived. Photos from the same phone that morning came through fine.

The next day a short clip of about ten seconds did arrive, which narrowed it down: there was a size limit somewhere, and anything over it was being dropped with a vague "unreadable" message instead of a reason. The fix that followed lets large files save properly with their real type, but the lesson was the message. A tool that drops your file should say it dropped it and why. "Unreadable, please resend" sends you round in circles.

The factory came back to the Mac, briefly

Not everything moved off the laptop in one go, and I'd rather be honest about that. The agent factory (the set of agents that builds and reviews work for me) moved to the box on 27 September. Two days later it moved back to the Mac, because only 3 of its 11 routes to AI models worked on the box. The rest needed repairs that would have eaten the whole cycle.

So for a while, the Mac was off for everything except building, and on for that when we had a good connection. That's not the clean picture I wanted. It is the real one, and the gaps are on a list being worked through.

What I'd tell anyone trying this

If you want to run your work from the road, here's what I'd do from day one, based on what broke for me.

1. Find out what stops when your laptop sleeps. Close the lid for a weekend at home and see what goes quiet. That's your list.
2. Move the always-on parts off the laptop. A small rented server costs a few pounds a month. Anything that needs to answer, send or run on a schedule belongs there.
3. Set one plain test. Mine was "same or better, with the Mac off". It turns a vague worry into a checklist.
4. Protect the way in. Know the one thing you use to reach your setup from your phone, and don't let anything change it while you're away from help.
5. Give your assistant real facts for bookings. Vehicle size, dates, documents. Write them down with where they came from, and check what it used before you trust a "no availability".
6. Expect the connection to drop. Design so that you disappearing for hours means work waits, not breaks.
7. Make failures say what they are. A message that something didn't arrive is useful. A vague error is worse than nothing.

Two weeks in

It's working, mostly. The decisions come to me on my phone, I answer them over coffee or between naps, and work carries on. Some days the connection is bad and nothing much happens. Some days a fix I thought was finished turns out not to be. That's the shape of it.

The test isn't over. We're here until mid-October, and the further we go, the less the laptop matters. That was the point.

If you're thinking about running more of your own work from somewhere that isn't a desk, I'm happy to compare notes.