Building a Website from My Phone with Claude Code + Telegram

I built 0xkaz.com almost entirely from my phone. My machine runs at home in KL. I was in a café in KL, or traveling in Baguio or Abu Dhabi — opening Telegram, typing what I wanted, and watching the site change.

The mechanism is Claude Code's Telegram channel plugin. You run Claude Code on a machine at home, install the plugin, point it at your repo, and from that point your Telegram chat becomes a terminal. Claude can read files, edit code, run shell commands, and deploy — all triggered by a message. Location stops mattering.

How the loop actually works

The setup is straightforward. Install the plugin, configure your bot token, and set TELEGRAM_STATE_DIR in .claude/settings.json to a directory inside the repo rather than ~/.claude/. That one setting matters: it keeps the bot state version-controlled alongside the project instead of floating loose in your home directory.

{
  "env": {
    "TELEGRAM_STATE_DIR": "/path/to/repo/.claude/channels/telegram"
  }
}

From that point, the interaction is just messaging. I'd send “add a dark mode toggle to the nav” and Claude would read the relevant components, make the edits, and reply with what it changed. I'd send “deploy” and it would run the build and push to Cloudflare Pages.

Skills make it one-command

The real productivity gain came from creating skills — small SKILL.md files that define slash commands for common operations. I have /commit, /push, /deploy, and /feedback. Each one tells Claude exactly what to run and what to report back.

Sending /deploy from Telegram and getting back a live URL two minutes later, without touching a laptop, doesn't get old.

The feedback form got built this way too

The most satisfying part: the feedback form at the bottom of each article on this site was designed, implemented, and wired up entirely through Telegram. I described what I wanted — Cloudflare Worker receiving submissions, D1 for storage, Resend for email confirmation, Telegram notification back to me when someone submits — and Claude built the whole stack. Wrangler commands to create the database, migration SQL, the Worker code, the form component in Next.js, the wiring between them.

That took a few back-and-forth messages across an afternoon. Async. I'd send something, close Telegram, come back an hour later, read the result, send the next instruction.

What works well

Full async development. This is the actual unlock. You don't have to sit there watching a terminal. Send the message, go do something else, come back to results. For side projects where you have 20 minutes here and there, this changes the math completely.

No context switching.One thread. Claude maintains context across the session — it remembers that we're using Tailwind v4 syntax, that the deployment target is Cloudflare Pages, that the Worker is in /worker and the site is in /site. I don't re-explain the project structure every time.

Ship-it decisions are frictionless. “Commit and push this.” One message. Done.

What to watch

No visual feedback. You can't see the rendered site in Telegram. For layout and CSS work this is a real limitation — Claude can make confident but wrong decisions about spacing and responsive behavior without a browser to check. Complex UI changes need a laptop eventually.

Session limits. Long tasks — especially multiple shell commands in sequence — can hit context limits or time out. For anything complex, ask Claude to commit frequently.

Credentials need care. .claude/settings.json is where environment variables live. Sensitive tokens belong in .claude/settings.local.json (gitignored), not in the tracked file.

Is it worth it?

For a side project running on Cloudflare's stack, yes, clearly. The infrastructure overhead is already low — no servers to SSH into, everything is wrangler deploy — and the Telegram interface removes the laptop requirement for most operations.

What surprised me is how much of software development is actually amenable to this. Reading logs, querying databases, deploying, committing, adding features described in plain language — that's most of what I do on a side project. The parts that don't work (visual QA, complex debugging with browser devtools) are genuinely the minority.

The site you're reading this on was built this way.

How close to fully automated?

Close, but not there. The loop handles execution well — once you know what you want, Claude can build it. The part that still requires a human is direction. What feature to add next, whether a design choice feels right, whether the copy says the right thing. These are judgment calls that drift if you hand them off entirely.

The risk isn't that Claude does things wrong — it's that it does things confidently in a direction you didn't quite intend. Catching that requires enough technical understanding to read a diff and recognize when something is off. You don't need to write all the code, but you need to know what good looks like.

Think of it as a skilled contractor who needs clear briefs. The less specific your direction, the more the output reflects Claude's defaults rather than your intent. Technical fluency makes your briefs better.

Notes from building 0xkaz.com.