Book 23 · Patriola’s Guide to Claude
Build a Self-Deploying App
A deploy script that exits 0 and a deploy that succeeded are not the same thing. They become the same thing when you add the verify pass. This book builds the complete pipeline — app, deploy script, and verification — in one session with Claude.
A real app built and deployed in one session
Every deploy that reports success and isn’t is built the same way: a transfer that completed, a script that exited 0, and no check that the remote file matches the local one. The first time that happens you spend three days debugging a broken live site with nothing in any log to explain it. The second time you’ve already built the verify pass, and it catches the mismatch in thirty seconds before anyone sees the bad version.
This book builds a complete self-deploying web application from scratch, with Claude writing every component. The worked example is real: a mobile Voice Lab app — a recordings logger, a physiological-event counter, a clip-labeling interface, and a PHP API backend — deployed to a live shared host via paramiko SFTP. Every deploy script in the book runs on production today. The sha256 verification block, the backup-before-mutate discipline, the php -l syntax check over SSH before the file goes live, the separate verify script that confirms content markers after the transfer — each one exists because the failure it prevents has already happened once.
What you’ll learnNine chapters from blank project to self-deploying system
- the-app-youre-going-to-deploy — The architecture of the worked example: a PHP API backend, a JavaScript front end with multiple functional views, and the directory structure that the deploy system will need to understand. Defining what “done” means before writing the first line.
- building-the-api-backend-with-claude — Using Claude to build the PHP API in thin vertical slices: one endpoint at a time, tested at the CLI level before adding the next. The prompting pattern that keeps Claude’s output reviewable rather than monolithic.
- building-the-front-end-with-claude — Building the JavaScript front end the same way: one view at a time, each wired to the API before moving on. The iteration loop that catches integration failures early, when they are cheap to fix.
- the-deploy-script-sha256-all-the-way-down — Writing the first deploy script the moment the first component exists. Computing the local sha256 hash, uploading via SFTPClient, computing the remote hash over SSH, and treating any mismatch as a hard stop. The discipline of verify-before-done applied from day one.
- backup-before-you-mutate — Adding the backup step: download the current remote file before overwriting it. The naming convention, the cleanup window, and why “I can just re-upload” is not an acceptable substitute for a backup that was taken before the problem existed.
- remote-verification-trust-but-confirm — Running a separate verify pass after the transfer completes: re-downloading the remote file, checking content markers, and confirming that the version string in the live file matches the one that was deployed. The difference between “the upload finished” and “the site is running the version I just deployed.”
- wiring-the-loop-one-command-to-deploy-everything — Composing the individual component deploy scripts into a single orchestrator. The order of operations, how failures in one component stop the chain, and the summary output that makes it clear exactly what happened and in what order.
- what-claude-gets-right-and-where-you-still-have-to-look — An honest account of where Claude accelerates this workflow and where the human has to stay close. The classes of error Claude misses in generated PHP and JavaScript, and the lightweight review habits that catch them before they reach the host.
- making-the-deploy-permanent-git-hooks-and-discipline — Wiring the deploy orchestrator to a git post-commit hook so deploying becomes a side effect of committing. The configuration that makes it opt-in rather than automatic, and the deploy log format that gives you a record of every push without filling disk.
A preview
A deploy script that exits 0 and a deploy that succeeded are not the same thing. They become the same thing when you add the verify pass.
The first time a silent deploy failure costs you three hours, the verify pass stops feeling like overhead. It starts feeling like the minimum acceptable behavior for any script that touches a live host.Who it’s for
Advanced Claude Code users who ship real software to real hosts
This is not an introduction to web development. The reader writes Python without looking things up, has a shared web host, and is comfortable with SSH. The book explains how to build a complete self-deploying system — including the verification discipline that makes “deployed” mean deployed, not “the upload reported success.”
A longer excerpt is available to newsletter subscribers.
More from Patriola
New books in this series
One short email per book launch.