Building a Blog I Can Run From My Phone
I wanted a blog I could run entirely from the Claude app on my iPhone. Here is how Railway, a Claude-written MCP server and GitHub made it possible, set up on a train standing still outside Grums.
I wanted to find out whether I could build a blog, or really any small web application, that I could run entirely from the Claude app on my iPhone. Not just write posts on my phone, but manage content, change the site and ship new code, all through conversation. Getting there would take a computer. Once the foundation was in place, I wanted to leave the laptop at home.
This site is the result. Here is how it came together.
Five hours on a train that barely moved
The foundation was laid on the train home to Gothenburg from Karlstad, after swimming the Vansbro race. It was the start of my vacation, and I had something I rarely get between work and kids: a few hours entirely to myself.
The train made it about 30 kilometres, to Grums, and then stood still for more than two hours. A 2.5-hour journey turned into five. Around me, people were rebooking plans and calling home. I barely noticed. I was deep in a flow, laptop open, and every minute of delay was another minute to build.
Step one: somewhere to run things
A blog needs a home, somewhere to run code and store data. I opened an account on Railway, a cloud platform that runs applications and databases without you ever managing a server. Projects and services can be created and redeployed with very little ceremony, which is exactly what an experiment like this needs.
Setting up the account and a first project with a PostgreSQL database took minutes. The interesting question was what came next: how would Claude, living in an app on my phone, actually reach it?
Step two: asking Claude to build its own bridge
The answer is MCP, the Model Context Protocol. It is an open standard that lets Claude use external tools, and anyone can build a server for it. An MCP server sits between Claude and your system and defines what Claude is allowed to do there.
So I asked Claude to write one. I described what I needed: access to the blog database, the ability to inspect tables, read content and make changes. Claude wrote the server. I deployed it to its own dedicated service on Railway, separate from the blog itself, and added it to the Claude app as a custom connector behind a sign-in.
That moment is worth pausing on. The AI wrote the tool that the AI then used to manage my system. From then on, "show me all published articles" or "update the About page" was a sentence I typed on my phone, not a task saved for when I was back at a computer.
It did not work on the first attempt. An early version kept crashing and restarting. Rather than patch it endlessly, I removed it and had it rebuilt properly. That is the rhythm of building this way: fast iterations, and a willingness to throw things away.
Step three: GitHub, and closing the loop
Claude could write code, but the code needed a home that Railway could deploy from. I set up a GitHub repository for the blog. Then I found the piece that tied everything together: Claude can work with GitHub directly through its API.
That changed the workflow completely. Instead of copying code out of a chat and into files, Claude could commit changes straight to the repository, and Railway picked them up and deployed them. Conversation, code, deployment and live site, all without leaving the app.
It also pushed the design in a useful direction. Everything that changes often, articles and pages like About, lives in the database rather than in the code. Updating text is a database change Claude makes through the connector, visible immediately with no deployment at all. Code changes go through GitHub. Content changes never have to.
What I took away from it
When the train finally rolled into Gothenburg, the building blocks were in place: a hosting platform, a database, a custom MCP server and a code repository, all reachable from a single app on my phone. A few things stood out.
The hard part was not the code. Claude wrote most of it. The hard part was deciding what should exist: which pieces, how they connect, what the AI should be allowed to touch and what should stay out of its reach.
Simple beats standard. My first version was packaged the conventional way, in a Docker container, and it was heavier than a blog needs. A lighter setup deployed faster and was easier to understand.
Speed creates its own risk. When building is this easy, it is tempting to skip documentation and lose track of what runs where. Being able to explain your own system a month later matters more than how fast you built it.
And the biggest one: all of this is available to anyone today. A few years ago, a setup like this would have needed a developer and a free weekend. I built it on the first afternoon of my vacation, on a train standing still outside Grums. Now I run it from my phone.
I have rarely been so happy about a delay.