A new project setup checklist is worth having because the first hour of a project decides how safe, how contained and how cheap it will be for the rest of its life. Most setups quietly skip one or two of those properties, and you only find out when something leaks, breaks, or costs money.
This checklist covers eleven items, grouped under the four things a project foundation has to get right at once: safe, contained, ready to scale, and cheap to start. Each item has a short what and why, and links to a deeper post. Work through it once by hand to understand it, then never do it by hand again.
The checklist at a glance
The full list, so you can tick it off as you go.
| # | Item | Property |
|---|---|---|
| 1 | Own AWS account, created through AWS Organizations | Contained |
| 2 | Private GitHub repository | Safe |
| 3 | Keyless deploys from GitHub Actions (OIDC) | Safe |
| 4 | Dev and prod separated, prod gated | Contained |
| 5 | A budget alert before anything runs | Cheap |
| 6 | Services that cost $0 when idle | Cheap |
| 7 | Realistic Free Tier expectations | Cheap |
| 8 | CLAUDE.md and AGENTS.md rules files | Safe |
| 9 | Guardrails that keep AI agents away from production | Safe |
| 10 | A first commit that already deploys | Ready to scale |
| 11 | An iteration loop under an hour | Ready to scale |
Safe
Safe means there are no long-lived secrets to leak and no way to break production by accident. Four items get you there.
2. A private GitHub repository
What: Create a private repository on GitHub before you write real code, and push to it from day one.
Why: Your code is backed up, versioned and shareable the moment you need it to be, and GitHub’s Free plan costs $0 with unlimited private repositories and 2,000 minutes a month of Actions. There is no reason to keep a project only on your laptop. The reasons to use GitHub for a new project, even a solo one go well beyond backup.
3. Keyless deploys from GitHub Actions
What: Connect GitHub Actions to AWS with OpenID Connect, so the workflow gets short-lived credentials for each run instead of an access key stored as a secret.
Why: A stored access key is a permanent credential sitting in a place that gets copied, forked and logged. With OIDC there is nothing long-lived to leak; AWS hands the workflow temporary credentials that expire within about an hour. The keyless deploys guide walks through the trust policy that makes it work.
8. CLAUDE.md and AGENTS.md
What: Add a short rules file for AI coding agents to the repository root: how to build, how to test, what never to touch.
Why: If you build with Claude Code, Codex or Gemini, the agent reads these files at the start of every session. Without them, every session starts from zero and the agent guesses your conventions. What to put in CLAUDE.md and AGENTS.md is short, and the file should be too.
9. Guardrails for AI agents
What: Make it structurally impossible for an agent to deploy to production, rather than asking it nicely not to.
Why: Agents are eager, fast and literal. A rules file sets expectations; a gated production environment enforces them. The post on keeping AI coding agents away from production covers the difference between the two, and why you need both.
Contained
Contained means a mistake in one project cannot spill into another, and neither can a bill. Two items.
1. Your own AWS account, via Organizations
What: Create a fresh AWS account for the project inside an AWS Organization, rather than adding resources to an account you already use.
Why: The account is the only hard boundary AWS offers. Permissions, quotas, billing and blast radius all stop at the account edge. When the project dies, you close one account and the bill goes to zero. One AWS account per project explains why tagging a shared account is not the same thing.
4. Dev and prod separated, prod gated
What: Give development and production their own accounts, or at minimum their own stacks, with production behind an explicit approval step.
Why: Most production incidents in small projects are someone, or something, running a dev command against prod. If the two cannot see each other, that class of mistake disappears. Why dev and prod should never share an account covers the cheap way to do it from day one, and how to add the split later if you start with one environment.
Ready to scale
Ready to scale means the foundation does not need rebuilding when the project grows. Two items, both about habits rather than infrastructure.
10. A first commit that already deploys
What: The first commit contains the scaffold, the deploy workflow, a README and the rules files, and it ships to a real URL.
Why: If commit one deploys, every later commit does too, and you never have a “we should set up deploys” task hanging over the project. The first commit is also where the conventions get set: folder layout, environment names, how secrets are handled. Getting it right once beats fixing it in every project after.
11. An iteration loop under an hour
What: From idea to deployed change in under an hour, every time, from the first week.
Why: Speed of iteration is the only real advantage a new project has over established ones. A slow loop means fewer experiments, and fewer experiments mean you learn less before the money or the enthusiasm runs out. The loop is fast when deploys are automatic, production is safe to push to, and nothing requires a human to copy a key.
Cheap to start
Cheap to start means $0 while the project is still an idea, and bills that grow only with real use. Three items.
5. A budget alert before anything runs
What: In the AWS Billing console, set a budget with an email alert at a number you would notice, before you deploy anything.
Why: It takes two minutes and it is the difference between finding out about a runaway resource on day one or on the invoice. The guide to avoiding a surprise AWS bill has the exact settings, and why per-project accounts make the alert useful instead of noisy.
6. Services that cost $0 when idle
What: Choose serverless and pay-per-request services, so an empty project with no traffic costs nothing.
Why: AWS has no monthly fee; you pay for what you use, by the request or by the second. Over 30 services include an always-free monthly allowance that never expires, and AWS Lambda alone gives you one million requests a month for free. Pick those and a quiet project stays at $0. Why AWS is a good place to start a project goes into which services behave this way.
7. Realistic Free Tier expectations
What: Know what the Free Tier gives you and, more importantly, what it does not.
Why: New AWS accounts get $100 in credits at sign-up and can earn up to $100 more. But an account that uses AWS Organizations, which you want for item 1, moves to the Paid plan and stops earning credits. Plan on always-free allowances and $0-idle choices rather than credits. The AWS Free Tier in 2026, explained has the full picture, including the Free plan’s six-month limit.
The usual way versus the fast way
Done by hand, this checklist takes days. Automated, it takes under a minute, because every item is a known step with a known correct answer.
| Step | By hand | Automated |
|---|---|---|
| Create and lock down a cloud account | Half a day, more if it is your first Organization | Seconds |
| Split dev and prod | Half a day | Seconds |
| Write access policies and guardrails | A day, plus the day you spend debugging them | Seconds |
| Wire keyless deploys from GitHub | Half a day, mostly reading trust policy docs | Seconds |
| Scaffold the repo and push the first commit | An hour | Seconds |
| Total | Days, even for a seasoned team | Under a minute |
The by-hand column is not a knock on anyone. These steps are genuinely fiddly, and the documentation for each assumes you already understand the other four. The point is that none of it is creative work. It is the same careful setup every time, which is exactly the kind of thing that should be done for you.
This matters most on the projects that never get a proper setup at all: the weekend idea, the client experiment, the thing your agent half-built on a Tuesday night. Most side projects never ship because this checklist happens, if it happens, when enthusiasm is highest and patience is lowest.
How to use this checklist
Do it by hand once, for a project you do not care much about, so you understand what each item is protecting you from. After that, automate it or use something that has.
TigerSoup is the automated version: it runs every item on this list for a new project from a short form, in under a minute, and opens the result in Claude Code, Codex or Gemini. It is free for Mac, with no subscription, and everything it creates lives in your own AWS and GitHub accounts.
