Side projects never ship for a reason that has nothing to do with the code. With an AI coding agent, writing the app is now the easy part; you can describe an idea on Tuesday night and have something working on localhost by Wednesday. The graveyard is full of projects that got exactly that far.
The missing step is the one between “works on my machine” and “has a URL”. It is made of account setup, a repository, deploy pipelines and secrets, and it is boring, slightly risky, and it arrives at the worst possible moment. This post is about why that step kills projects and how to move it to a place where it cannot.
The real reason side projects never ship
Setup friction lands at the exact moment enthusiasm is highest and patience is lowest, so it gets skipped, and a project with no deploy path never recovers from that.
Think about the order of events. You have an idea. You are excited. You open a terminal and start building, or you open Claude Code and start describing. Two hours later something works. Now, to get it in front of anyone, you need to:
- Create or choose a cloud account, and decide whether this project should share one with your other things
- Create a repository and push to it
- Work out how deploys will happen, which means a workflow, credentials, and a place for those credentials to live
- Find out that the credentials approach you picked is the insecure one, and read about the right one
- Set up a domain, or accept an ugly generated one for now
- Make a note to “do this properly later”
Every one of those is a small, unglamorous task with a small chance of going wrong. None of them are the thing you were excited about. So the natural move is to keep building on localhost, where the feedback loop is instant and nothing can break, and do the shipping part “once it’s ready”.
It is never ready. Readiness is not a property of the code. It is a property of having a deploy path, and you do not have one.
The localhost trap
Localhost feels like progress because the feedback loop is instant, but a project that only runs on your machine has no users, no feedback and no stakes, and those are the things that keep a project alive.
The trap has three parts.
Nothing is at risk, so nothing is urgent. A project on localhost cannot break for anyone. That sounds good, but urgency is what gets a project to the next session. If nobody will notice whether you work on it tonight, you probably will not.
Nobody can see it, so nobody can react. The single most motivating thing that can happen to a side project is a stranger using it. That cannot happen on localhost. Every week it stays there is a week of zero feedback, and zero feedback feels a lot like nobody caring.
The gap keeps growing. The longer a project lives on localhost, the more it accumulates: local-only config, hard-coded paths, a database that exists only on your laptop. Shipping it gets harder every week, which makes it less likely every week. The project is not dying because you lost interest. You lost interest because it was dying.
This is also why “I’ll clean it up and deploy it on the weekend” is a death sentence. The weekend version of you has less enthusiasm and the same friction.
The first-hour rule
Spend the first hour of any new project getting a hello-world version onto a real URL, with automatic deploys, before you build anything you care about.
The rule is simple: the first hour produces a URL, not a feature. You are moving the boring, risky setup work to the one moment in a project’s life when you have enough energy to push through it, and before there is any code to be precious about.
Once the URL exists, the project’s shape changes. Every push deploys. “Ship it” is no longer a project; it is a git command. The question stops being “when will I deploy this” and becomes “what should I build next”, which is the question you wanted to be answering all along.
The first hour also protects you from the other side-project killer: fear of pushing. If production is the same account as everything else, with the same credentials, a bad deploy can take out things you care about. So you hesitate, and hesitating is how the loop gets slow. Set production up so it is separate from dev and gated, and you can push with the confidence of someone who cannot break anything that matters.
What the first hour should contain
The first hour should give the project its own cloud account, a private repo, keyless deploys, a budget alert, and a hello-world page at a real URL. Nothing else.
Here is the list, in order.
-
A home that is only this project’s. Create a new AWS account for it, inside your AWS Organization, rather than piling it into an account you already use. It costs nothing, and it means the project has its own bill, its own permissions and its own blast radius. When the project dies, this is what makes the cleanup one step.
-
A private repository on GitHub. Push the scaffold. GitHub’s Free plan is $0 with unlimited private repositories, so there is no reason not to.
-
Keyless deploys. Wire GitHub Actions to the AWS account with OpenID Connect, so the workflow gets short-lived credentials on every run and there is no access key stored anywhere. This is the step most people do wrong under time pressure, pasting a key into repository secrets and promising to fix it. The keyless deploy setup takes the same time to do right.
-
A budget alert. Two minutes in the AWS Billing console: a budget with an email alert at a number you would notice. Do this before the first deploy, not after the first invoice.
-
A hello-world deploy. Push one commit that serves a single page at a real URL. Not the app. A page that says the project’s name. The point is to prove the whole path works, end to end, while the stakes are zero.
-
Rules for your agent. If you are building with Claude Code, Codex or Gemini, add a short CLAUDE.md or AGENTS.md that says how to run, how to test, and that production is off limits. It is a few lines, and it means the agent starts every session knowing the project’s shape.
After that, build. Every push goes to dev. Promoting to prod is a deliberate step. You will ship the first real feature within a day of starting instead of never, because shipping is now the default state of the project rather than a milestone.
A note on cost: with services that cost $0 when idle, which is most of the serverless ones, all of this runs at nothing while the project is small. AWS has no monthly fee and over 30 services have an always-free monthly allowance, so a side project with ten users will cost about what it costs to run on your laptop.
What to do when the project dies
When a side project dies, close its AWS account and archive the repo. If the project had its own account, that is the whole cleanup, and the bill goes to zero.
Most side projects do die, and that is fine. The failure mode to avoid is the half-dead project: nobody uses it, but a resource somewhere still bills a few dollars a month, and you are not quite sure which account it lives in or what else shares that account.
If you did the first hour properly, the teardown is:
- Close the project’s AWS account. Everything in it is deleted. There is no hunting for a forgotten resource, because the account boundary is the search.
- Archive the GitHub repository. The code stays, read-only, in case the idea comes back.
- Delete the budget alert, or let it go with the account.
That is it. Compare that with a project that shared an account with three other things: you are now reading billing line items, guessing which bucket belongs to which project, and hoping you do not delete something a live project needs. That kind of cleanup is unpleasant enough that people do not do it, and the half-dead project bills forever. It is one of the quieter reasons to avoid a surprise AWS bill by giving every project its own account in the first place.
Clean teardown also makes starting the next project easier, because you are not carrying guilt about the last one.
The honest version
Side projects do not fail because you are lazy or because the idea was bad. They fail because the setup step is boring and it lands at the worst time, so it gets deferred, and a project without a deploy path has no way to reach the one thing that keeps projects alive, which is someone using it.
Move the setup to the first hour, make it produce a URL, and keep production safe enough that pushing never feels risky. The projects that survive will not be the ones with the best code. They will be the ones that shipped on day one and kept shipping.
TigerSoup exists because that first hour should take a minute, not an hour. It creates the account, the private repo, the keyless deploys and the agent rules from a short form, and opens the project in Claude Code, Codex or Gemini. It is free for Mac, with no subscription, and everything it creates is in your own AWS and GitHub accounts.
