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.