You are reading an article about building a blog, on the blog, which was built using the same process the article describes. Take a moment. Breathe. We're going to be fine.
The premise: I wanted a personal blog. I had a phone, a GitHub account, and Claude Code open in a browser tab. I had no laptop nearby and a stubborn conviction that this should work. Two hours later I had a deployed site with real typography and zero npm packages. Here's what I learned, in the order I learned it, including the embarrassing parts.
The part where I thought it would be easy
It was easy. Suspiciously easy. I described what I wanted — magazine-style layout, warm colour palette, two specific Google Fonts, no JavaScript frameworks, deploy to Cloudflare Pages — and Claude Code just... did it. Cloned the repo, wrote the HTML and CSS, committed, pushed. I reviewed the diff on GitHub mobile and said "looks good."
This is the moment you feel slightly smug. Don't feel smug. The next part is humbling.
The part where I was too vague
"Make it feel more like a magazine" produced something that felt more like a dentist waiting room pamphlet. Generous line spacing, yes. Tasteful, no.
The problem wasn't the AI. The problem was me. "Magazine" means about four hundred different things. When I switched to specifics — "left-aligned text block, 680px max, serif headings that feel editorial not academic, off-white not white, one accent colour used sparingly" — the result was immediately right.
Vague prompts get you technically correct results. Specific prompts get you what you actually wanted.
This is the core skill. Not writing code — articulating intent. Which, it turns out, is also just good design thinking. The AI just made the cost of imprecision visible immediately rather than six commits later.
The phone constraint is actually good, actually
Here's the counterintuitive part: the phone made this better. On a laptop I would have opened the browser inspector, nudged padding values manually, gotten lost in tab rabbit holes, and spent forty minutes on a detail that didn't matter. The phone doesn't let you do that. You describe, you review, you decide. The loop is coarser but you move faster through decisions that actually count.
Typing on a phone also forces brevity. Short sentences. No rambling setup before the actual instruction. Claude responds well to this — it's essentially how good prompting works anyway, and the keyboard punishes you immediately if you don't do it.
If you're on iOS, use a hardware keyboard if you have one. If not: tap the microphone, speak your instruction, then edit the transcript before sending. Surprisingly efficient for longer descriptions. Works in portrait, oddly.
The agents.md trick
After the first session I asked Claude to write an agents.md file — a
plain-English document that tells any future AI working in this repo what the rules
are. Don't touch the font stack. Don't introduce build tools. Articles go in
/articles. Footer nav has these five links. Always push to main.
This is the move that makes the whole thing durable. Without it, the second session starts from scratch and you spend the first ten minutes re-explaining decisions you already made. With it, context is free. New sessions, same standards.
It also functions as a design document. Writing it forced me to articulate why the choices were the choices. That's worth doing regardless of AI.
What I'd tell someone starting now
Start with the constraint, not the technology. Decide what you won't do — no framework, no CMS, no build step, whatever — before you decide what you will. The AI will happily introduce complexity you didn't ask for if you leave the door open. Close it early.
Write your first prompt like you're briefing a competent contractor, not a search engine. Not "make a blog" but "I want a static HTML blog with no dependencies, a warm off-white background (#fdf6ee), DM Serif Display for headings, DM Sans for body text, and a single burnt-orange accent colour. No JavaScript unless absolutely necessary. Here's the folder structure I want."
Review every diff before you approve it. Not because it'll be wrong — mostly it won't be — but because you should understand your own site. The act of reading code you didn't write teaches you things. This is part of the point.
AI coding from a phone is less about convenience and more about removing the excuses. The gap between wanting a thing and having a thing is just specificity.
This article was written in the same session I described above. I told Claude what I wanted to say, reviewed the draft, made adjustments, and it's here now. That's the whole pitch. It works, it's fast, and the quality ceiling is exactly as high as your taste allows it to be.
Anyway. You could have a blog by this evening. The question is what you'd put in it.