I Stopped Running My Side Project on My Computer
Every change Claude Code makes goes straight to the live app. Here's why that's not as reckless as it sounds.
I’m building Article Forge — a place where I centralize my content creation across multiple platforms. It’s clearly a personal project for now. From day one, I told Claude to deploy every time it finishes something.
I haven’t run my project on my own computer since.
That sounds irresponsible. It’s not — and I’ll explain why. But first, let me tell you what actually happens now: I describe what I want. Claude Code writes the code, saves it, and sends it to the server. A minute or two later, the change is live on the internet. Not on my laptop. On the actual app, at the actual URL, for anyone to see.
Why Would Anyone Do This?
Because I was wasting hours on a problem that doesn’t exist yet.
When you build a side project, there’s a ritual everyone follows: set up a “local development environment.” That means running your app on your own computer first, testing it there, and only then putting it on the internet for real.
This makes total sense when you have users. You don’t want to break something for real people while you’re experimenting.
But my app had zero users. The only person using it was me. I was carefully protecting a production environment that nobody visited.
And here’s what that “protection” actually cost me:
I kept every setting in two places. Every password, every API key, every connection string — I had to copy it into my local setup AND into my hosting platform. Every time I added a new service, I’d forget to update one of them. The app would crash online even though it “worked on my machine.”
I never knew if my app actually worked until I deployed it. My computer and the server aren’t the same thing. Different operating system, different versions, different everything. I’d build something locally for a week, finally deploy, and spend half a day fixing things that only broke on the server.
I was testing a deployment process I’d only use once a week. Every time I deployed, something went wrong — because I only did it rarely. The less you deploy, the scarier it gets. The scarier it gets, the less you deploy. It’s a trap.
What I Did Instead
I set up three things. Took about 15 minutes.
First, I connected my code to a hosting platform that auto-deploys. I use Render.com, but there are many options. The deal is simple: every time new code appears in my repository, the platform rebuilds and redeploys the app automatically. I don’t press any buttons.
Second, I put all my settings directly on the server. Instead of keeping a settings file on my computer that mirrors what’s on the server, I just... set them on the server. One place. One source of truth. If the app needs a new API key, I add it once. Done. Render even has an API for this — you can manage everything without clicking through dashboards.
Third — and this is the part that changed everything — I told Claude Code to ship every change immediately.
Claude Code is an AI tool that codes in your terminal. You tell it what you want, it writes the code, edits files, runs commands. Think of it as a developer sitting next to you who does exactly what you ask.
There’s a special file called CLAUDE.md that acts as its instruction manual. Claude reads this file before every session. I added one simple rule:
After every change, save the code, and send it to the server. Don’t ask me. Just do it.
Here’s roughly what that looks like:
## Deploy workflow
After every code change:
1. Stage all changed files
2. Write a clear, descriptive commit message
3. Commit and push to main
Never ask me whether to commit. Just do it.
Every push triggers an automatic deploy.
From that moment, every change Claude Code makes goes live within a couple of minutes.
Not “when I decide to deploy.” Not “after I test it locally.” Every. Single. Time.
Isn’t This Reckless?
For a product with real users? Absolutely. Don’t do this if people depend on your app.
But for a side project in its first month? Your only user is you. The worst thing that happens is your app shows an error for five minutes until you fix it. And you fix it faster, because you made one small change — not fifty.
Think of it as building a treehouse. You don’t need building permits, safety inspections, and an architect. You need a hammer, some nails, and the willingness to rebuild the roof if it leaks. Once you invite the neighborhood kids over, different story.
The moment someone signs up for your product, you stop doing this. You add proper safeguards, a staging environment, code review. But until then? Your real app IS your testing ground. Own it.
The Part I Didn’t Expect
I expected this to save me time. It did. But the bigger change was how I started thinking about building.
When every change goes live in minutes, you stop planning big features. You make one tiny change, check if it works on the real app, and decide what to do next. Instead of building for three hours and then deploying, you build in three-minute chunks.
My changes got smaller. My decisions got faster. And my app got better — not because the code improved, but because I was looking at the real thing 50 times a day instead of a simulation on my laptop.
It’s the difference between writing an entire essay and then publishing, versus writing one paragraph, publishing, seeing how it reads, and adjusting. You ship paragraphs, not essays.
Want to Take This Further?
I put together a free 5-email series that goes beyond the basics:
My actual CLAUDE.md instruction file — with notes explaining every section and why it’s there
Render.com setup from zero — connecting your repo, setting env variables, and managing it all through the API
How to deploy from your phone — Claude has a feature called Dispatch that lets you send coding tasks from your couch. Yes, really.
When and how to add safety rails once your project gets its first real user
Five emails over five days. Built and delivered through Drippery — the tool I’m building as my own side project.