Before anything could go live, the site needed two homes: a server on the internet, and a copy on my laptop where I can break things safely.
In short:
- I host on Hostinger because it’s cheap and runs WordPress, but the plan has no SSH, which made automation harder.
- A full copy of the site runs on my Mac with Herd, so I never experiment on the live site.
- The theme is a block theme in its own Git repository, with a rules file Claude reads every session.
What does a WordPress host need?
WordPress isn’t just files. Every time someone opens a page, the server runs code (PHP) and reads from a database (MySQL) to put the page together. So a host has to offer both, plus a disk that keeps files, because WordPress saves uploads and plugins to it. Hosts like Vercel and Netlify are built for static sites and small functions, so they don’t fit and can’t run WordPress.
Why Hostinger
I went with Hostinger because it’s cheap and good enough. It runs PHP and MySQL, has a simple control panel (hPanel) and lets me copy files to the server over FTP.
Cheap plans cut corners, though, and you only notice once you try to automate things. Mine has no SSH, which is a way to log in to the server and type commands on it. Without it, I can’t run WordPress’s command line tool (WP-CLI) on the live site, and every job that would normally be one command needs a workaround. That shaped a lot of what comes later in this series, especially part 4.
For a personal, experimental site where I don’t mind a few workarounds, that trade is fine, and I’d pick it again. For a more serious project I’d pay a bit more, because it’s worth it, and look for a plan with SSH or a built-in way to deploy from GitHub.
A copy on my laptop
The live site is where real visitors are, so it’s the last place I want to experiment. Instead, I have a full copy of WordPress running on my Mac.
I use Herd, a free app that runs PHP sites on a Mac. Any folder I put in ~/Herd becomes a local website, so ~/Herd/inesmedemai opens at https://inesmedemai.test in my browser. Only my laptop can see it. The database comes from MySQL, which I installed on the Mac separately.
Herd, Local and wp-env all do this job. If you’re new to this, Local (also known as Local by Flywheel) is a friendlier choice: it sets up PHP, the database and WordPress for you with a few clicks. The tool isn’t the hard part.
The first time, I set it up step by step with Claude. Then I asked it to turn those steps into a skill, so the next site is one prompt. A skill is a set of written steps Claude follows when a job comes up. Mine goes from an empty folder to a working WordPress connected to a fresh database, then stops and asks me for the site title and admin details before installing. It also records the two snags I hit along the way, so I won’t hit them again.
Same pieces, different data
Both copies have the same three pieces: WordPress itself, my theme, and a database. The first two match. The database doesn’t.
- On my laptop: placeholder posts and test pages. I can wipe it whenever I like.
- On the live site: my real posts and pages.
That’s the two one-way streets from part 2 in practice. The theme moves from my laptop to the live site, and real content only ever comes down, when I need it for testing.
Starting the theme
The theme lives in its own folder inside the local site, and that folder is its own Git repository, with a private copy on GitHub. Only the theme is in Git. WordPress itself and the database aren’t, because they aren’t mine to keep a history of.
Here’s the reasoning. WordPress itself (its core files) is the framework, and it’s maintained by someone else. I never edit those files, because every WordPress update would overwrite my changes. The database holds the content, which lives on the live site (see part 2). That leaves the theme as the one part of the code that is mine to change, and that’s why it’s the only part in Git. It’s simply how you work with WordPress: you build on top of it and leave the framework alone.
It’s a block theme, the modern kind of WordPress theme. An older theme is mostly PHP template files. A block theme is mostly:
theme.json: one file with the design system: colours, fonts, spacing, layout widths.- Templates and parts: the page layouts, and the pieces they share like the header and footer, built from blocks.
- Patterns: ready-made sections, like the home page hero, built from the same blocks.
I started it on 14 September, with my brand assets in one folder. Claude and I went through them one at a time: colours, then fonts, then sizes and spacing, then the header. By the end of that first day the theme had my colour palette, my font, a type and spacing scale, a header with navigation, and a dark mode toggle.
As we went, Claude wrote the steps down as a second skill, including the corrections I made along the way. The biggest one: always build a block theme, never fall back to an old-style PHP theme, even for a small site. The next time I brand a theme, it asks the same questions in the same order, and doesn’t repeat the same mistakes.
The rules file
The most useful file in the theme folder isn’t code. It’s CLAUDE.md, a plain text file that Claude Code reads at the start of every session in that folder.
Mine says things like: use the colours and sizes in theme.json rather than typing in a colour code; my font comes in two weights only; commit only when I ask, and never push without asking, because a push puts the change live. Without it, Claude picks a different way of building WordPress each time, because there are many. Writing down the right way once fixes that.
When Claude gets something wrong twice, that’s a rule worth adding.
Skills I used
These are the skills I used for this part. A skill is a set of written steps Claude follows when a job comes up.
wordpress-fresh-install: goes from an empty folder to a working local WordPress connected to a fresh database. It stops and asks for the site title and admin details before installing.wordpress-theme-branding: turns that fresh install into a branded block theme, asking for colours, fonts and logo step by step.
Next in the series: how a change gets from my laptop to the live site, and why my cheap plan made that tricky.
