# Blogging from the car: an MCP server on my Raspberry Pi

My blog had a problem: I almost never wrote on it. Not for lack of ideas — I
have plenty of those. The issue was *when* the ideas showed up. Usually I'm in
the car, or away from my desk, with my phone in reach and no keyboard anywhere
near me. I can talk. I just can't type.

So instead of trying to change my habits, I built something that fits them. Now
I record a voice note, dictate it into a conversation on Claude.ai, and that
conversation ends with a published post on this site. The whole path — idea,
voice, conversation, post — happens without me opening a laptop.

There's a second reason, too. English isn't my first language, and writing posts
in it is good practice. So the workflow doesn't just publish what I say: it
corrects my English and explains *why* each change was made. Publishing and
studying, same step.

## The stack

Everything is TypeScript.

The front-end is Next.js. The back-end is Node with Express. The architecture is
a monolith, but organised as a monorepo: front-end and back-end live as separate
sub-projects, each with its own `package.json` and its own `node_modules`, with a
root `package.json` on top to manage them both.

Nothing exotic. That's deliberate — I wanted something I could still understand
six months from now.

## Getting the Pi online

The server runs on a Raspberry Pi that's part of a small private cluster I keep
at home, built from my own machines.

Exposing it to the internet is handled by Cloudflare Tunnel, which also manages
the DNS. No open ports, no port forwarding, no dynamic DNS scripts to babysit.
The tunnel dials out; nothing dials in. For a machine sitting on my home network,
that trade-off is easy to accept.

## Why I vibe coded it

I built this by vibe coding, and the reason is simple: time. I don't have much of
it, and this is a personal project that has to fit into the gaps of a working
week.

That works because of experience, not instead of it. I already knew these
technologies and how the implementation should look, so when code comes back I
can read it and tell whether it's right. That's the part people skip when they
talk about vibe coding: the speed is only safe if you're able to review what you
just shipped.

## The refactor I didn't plan for

Originally this site was front-end only. That's all it needed to be.

The MCP integration changed that. To make it work properly the site needed a real
back-end with real endpoints — not a workaround bolted onto a static site. So I
grew the project into one and refactored it completely.

That refactor wasn't in my plan, and it was the right call anyway. Adding one
feature exposed a structural limit I'd been ignoring.

## What I'd tell you before you start

Know exactly what you want before you start describing it. Vibe coding will
happily build the wrong thing very quickly.

And don't file the checks and the tests under chores. For me they aren't — they're
where the actual experiment lives. The point of a project like this is to find out
what the technology can really do, and you only find that out by testing it
properly.