Three projects, one stack.

What RogerLe.com, RLMotorhome, and CamperBudget have in common under the hood — and why we built them that way.

From the outside, the three projects we run look like three different businesses. RogerLe.com is a web hosting company that's been online since 1996. RLMotorhome is our travel hub — videos, photos, recipes, a journey map of every road we've taken. CamperBudget is a SaaS we're building for fellow motorhome travelers who want an honest way to see what life on the road actually costs. Hosting, travel, software. Three audiences. Three pricing models. Three problems.

Look under the hood and they are the same machine.

Each runs on AlmaLinux. Each is served by nginx. Each speaks to a MariaDB database through PHP-FPM. Each is deployed as a tar.gz archive, extracted by hand on the server, set to nginx:nginx, and reloaded. We could have made three different choices. We didn't. There's a reason — and the reason is the post.

A small surface, on purpose

When you run more than one project, the temptation is to pick the right tool for each one. A static site generator for the marketing pages. A framework for the SaaS. A CMS for the blog. Each tool is reasonable in isolation. Together, they become a maintenance bill that grows faster than the projects themselves.

We chose the opposite. One stack across all three. Vanilla PHP. Vanilla JavaScript where possible. No build pipeline. No package manager pulling in updates we didn't ask for. The trade-off is that some things are slightly slower to write the first time. The reward is that nothing breaks on its own.

The first time you deploy a vanilla PHP app, you wonder why you ever did anything else. The fiftieth time, you stop wondering.

What's shared

The substrate looks the same from every angle:

• AlmaLinux 8. Stable, RHEL-compatible, predictable updates.
• Nginx as the web server. Reverse proxy where we need it, static serving where we don't.
• PHP 8.3 with PHP-FPM, running as nginx:nginx. No exceptions.
• MariaDB. Each project has its own database. The schema lives in version control alongside the code.
• Vanilla PHP, vanilla JS, CSS variables. No frameworks unless one clearly earns its place.
• tar.gz deployment. Roger packages on his laptop, scp delivers, four commands install it. There is no CI/CD pipeline because the deployment is small enough not to need one.
• bcrypt, CSRF tokens, timing-safe comparison, 24-hour session timeouts. The same security primitives, used the same way, in every admin panel.

The admin paths are even named the same. /rladmin/ on all three sites — not /admin/, because that's where the bots knock first.

What's different

The shared stack is the substrate. The projects on top of it are distinct.

RogerLe.com is a hosting business, so it has a billing system, a helpdesk, and a public-facing site that reassures people who are about to put a year of email on our servers. RLMotorhome is a travel hub, so it has a journey map, a photo gallery, a recipe section that Le maintains, and embedded videos from our YouTube channel. CamperBudget is still in active build, but its centre of gravity is a spreadsheet replaced by something better — entries you can make at a fuel pump in three taps, that work offline.

We don't pretend the projects are uniform. They aren't. Each one has its own audience, its own pacing, its own visual language. What they share is the part the user doesn't see.

Why this works

The honest answer is that we are two people. Roger writes the code. Le tests it on her MacBook Pro and tells us when something is too small to read. There is no team to onboard. There is no codebase to keep three engineers in sync on. There is one operator, one tester, and a great deal of help from the Awesome Crew — our name for the Claude instances we work with — but the buck stops at the same kitchen table either way.

One stack means one set of habits. We can move from a RogerLe.com bug to an RLMotorhome feature to a CamperBudget question without changing how our hands move. The cost of context switching, which is the real tax on a small team, is close to zero.

It also means the projects can help each other. A pattern we figured out for the hosting admin found its way into the journey log. A CSS token system that emerged for RLMotorhome is now the base for CamperBudget's design. Nothing is wasted because nothing is foreign.

The deeper reason

A few days ago, Roger wrote a post on his personal site called Production from a Parking Spot. The thesis was that the office moves and the infrastructure doesn't — and that the discipline of working from a motorhome makes the infrastructure better, not worse.

This post is the same thesis from a different angle.

Three projects, one stack, because the makers are two people, and the people are sometimes parked under trees with weak signal, and the only way any of this works for thirty years is if we choose simple things on purpose.

The stack is the easy part. The discipline is the work.

Tech · Sunday, 17 May 2026 · Agen, France