5.4
Deploy It, Then Break It
Why this exists
Right now your thing exists on your laptop, where the only person who can be let down by it is you. Putting it on the internet changes that, and the change is the point of this lesson.
Everything in Level 6 assumes you know what it feels like to have something live that you're responsible for. This is where you get that, on something small enough that it doesn't matter.
The idea
Live means someone else can be affected by your mistake. That's the whole difference, and it changes how you work.
The deploy itself is easy — it's a command, and Claude will walk you through it. The lesson isn't the deploy. It's what happens after.
Because once it's live, three things become true that weren't before:
- Your local copy and the live one can disagree. "It works on my machine" starts being a sentence you say.
- Breaking it is visible. Not to many people, on this project. But visible.
- You need a way back. Which you already have — that's what the commits from 5.2 are for.
So the loop that matters, and the one you'll use for the rest of your career:
change → check locally → ship → check live
That last step is the one people drop. Something can work perfectly on your machine and fail live, because live is a different place with different settings. Checking locally is not checking. Checking live is checking.
And then you're going to break it on purpose, which sounds silly and isn't. There's a specific fear that comes with having a live thing be wrong, and it's much better to meet that fear on a toy project on a Tuesday than for the first time on something real at 7am. Break it, sit in it for a second, fix it, ship the fix, confirm it's better.
Once you've done that, you know the recovery loop works. That's a different kind of confidence than being told it works, and it's the thing Level 6 stands on.
Do
- Ask Claude Code to deploy your project. Let it recommend a host and follow it — this is exactly the kind of thing to let it propose.
- Open the live URL. Use the thing, live. Not your local copy.
- Note anything that behaves differently live than locally. Write it down.
- Commit and note where you are — this is your known-good point.
- Break it on purpose. Make an obviously wrong change and ship it.
- Open the live URL and confirm it's broken. Sit with that for a moment.
- Fix it by going back to your known-good commit and shipping again.
- Confirm live is healthy. Write in
deploy.md: the URL, how long the fix took, and what you'd check first if it broke again tomorrow.
Step 6 is the one people skip because it feels pointless. It isn't. The feeling of something being live and wrong is information, and you want to have met it before it matters.
Done when
That's Level 5. You've built something, found its defects yourself, put it live, broken it and fixed it. Next level is doing that for a system you didn't build — which is the actual job.
Never do
Never ship without checking live afterwards. Local is not live. The gap between them is where the phrase "works on my machine" comes from, and it's a phrase that has never once helped anybody.
Never break something live without a way back. You had a commit here. In Level 6 you'll be working on things where the way back matters far more — and the habit has to already exist by then.