Speed of iteration is the one advantage a new project has, and most new projects give it away in the first week. Incumbents have money, users, data, and a sales team. You have none of that. What you have is the ability to learn faster than they can, and only if your loop from idea to deployed URL to real feedback is short enough to run many times a day.
This post is about what speed of iteration actually means, why it matters most at the very start, what quietly slows the loop down, and how to get it under an hour.
What speed of iteration actually means
Speed of iteration is cycle time: how long it takes to go from “I have an idea” to “a real person has used it and I know what happened”. It is not how fast you can type, and it is not how many features you can list.
The loop has three parts:
- Write. Turn the idea into a change in the code.
- Ship. Get that change onto a URL someone else can open.
- Learn. Watch what happens and decide what to do next.
Most people only optimise the first part. They pick a faster framework, a better editor, or an AI coding agent, then wonder why the project still feels slow. The answer is usually that the writing step was already the short one. A change that takes twenty minutes to write and two days to ship has a two-day cycle time, and the twenty minutes are a rounding error.
If you want a single number to track, it is the time from a commit landing on your main branch to that change being live on a URL you can send to someone. Everything else in this post is about shrinking that number.
Why it matters more at the start
At the start, you know the least you will ever know about the problem, so each loop is worth more than it will ever be again. A new project is a stack of guesses: who the user is, what they will pay for, which feature matters, what the thing should even be called. Every loop replaces a guess with a fact.
The maths is blunt. If your cycle time is a week, you get about fifty lessons in a year. If it is an hour, you get fifty lessons in a week, with time left over. The second project is not fifty times smarter, because not every loop teaches something. But it finds the wrong guesses far earlier, and wrong guesses are what kill new projects.
Incumbents cannot copy this. Their loop is slow for structural reasons: approvals, compliance, a release train, ten teams sharing one production system. Their speed of iteration is capped by their size. Yours is capped only by how you set the project up, which is the one thing you control completely on day one.
The four things that slow the loop
Four things turn a one-hour loop into a one-week loop: setup friction, fear of production, manual deploys, and shared infrastructure. None of them show up as a line item, which is why they survive.
Setup friction
Setup friction is every hour spent before the first real change ships. Creating a cloud account, locking it down, splitting dev from prod, writing access policies, wiring deploys, scaffolding a repository. Done properly, this takes a seasoned team days. Done quickly, it gets skipped, and the skipped parts come back as the next three problems.
The trap is that setup feels like progress. It is not a lesson about your users. It is a tax paid before the first lesson, and the longer it takes, the more likely the project stalls before it is paid. There is a new project setup checklist that lays out exactly what has to exist before the loop can start.
Fear of production
Fear of production is what happens when a deploy might break something that matters, so you deploy less often. You batch changes to “make the deploy worth it”, which makes each deploy bigger and riskier, which makes you batch more. The loop stretches from hours to weeks without anyone deciding it should.
The fix is not courage. It is structure: production that is gated so nothing reaches it by accident, and small reversible changes so a bad one is cheap to undo. That is the whole argument in why dev and prod should never share an AWS account.
Manual deploys
Manual deploys mean a human has to remember a sequence of steps, so shipping becomes a chore that waits for a quiet moment. The quiet moment arrives on Friday afternoon, when nobody should be deploying anything.
If a deploy needs a person, it happens when the person is free. If a deploy happens on every push to main, it happens every time there is something to ship. The second version is also safer, because the steps are written down in a workflow file and run the same way every time. Doing this without pasting long-lived keys into your repository is covered in keyless deploys with GitHub Actions and OIDC.
Shared infrastructure
Shared infrastructure means a mistake in one project can take down another. One AWS account for everything you build sounds tidy until a test script deletes the wrong table, or an experiment runs up a bill that lands on the same invoice as the thing that pays rent.
Once that has happened to you, you become careful. Careful is slow. The alternative is one isolated account per project, so the worst a mistake can do is break the thing you were already working on. There is a longer case for this in why every project should have its own AWS account.
How to get the loop under an hour
A loop under an hour needs four things in place before the first feature: deploy on every push, a production you are not afraid of, small changes, and an account boundary around the project. Here is what each one looks like in practice.
| Requirement | What it means in practice | What it removes |
|---|---|---|
| Deploy on every push | A GitHub Actions workflow runs on merge to main and ships to a live URL | Manual deploys, Friday deploy dread |
| Safe production | Prod is gated behind main or an approval; branches deploy to dev | Fear of production |
| Small reversible changes | Each change is one idea, revertable with one commit | Batching, big risky releases |
| Isolated account | The project has its own AWS account; nothing else lives there | Shared infrastructure blast radius |
Deploy on every push. Write the deploy as a workflow, not as a document. Push to a branch, it deploys to dev. Merge to main, it deploys to prod. If you can only remember one rule, it is this one.
Make production boring. Production should be the place changes go when they pass, not the place you nervously copy files to. Gate it with a branch rule or a required approval, and give it its own credentials so a dev workflow physically cannot touch it.
Keep changes small. One idea per change. If it breaks, revert one commit. If it works, you learned one thing and you know which thing. Big changes teach you nothing, because you cannot tell which part mattered.
Put a wall around the project. One AWS account for this project, with no monthly fee and nothing running until you deploy something. AWS bills by the request or the second, so an isolated account for an idea costs nothing until the idea does something. Then when a mistake happens, and it will, it stays inside the wall.
None of this is novel. What is new is how much of it you can have on day one. Setting it up by hand still takes days. TigerSoup does the same setup in a couple of clicks: an isolated cloud account, a private repository, and keyless deploys wired from GitHub, so the loop exists before you write the first line of real code.
Where AI coding agents fit
AI coding agents compress the writing step, which means setup and deploys become the bottleneck faster than they used to. If an agent can write a feature in ten minutes but the deploy takes a day, your speed of iteration is a day, and the agent did not help.
It also makes the account boundary more important, not less. An eager agent with production credentials and a vague instruction is a new kind of outage. The agent should be able to ship to dev freely and reach prod only through the same gate a human would use. The practical version of that is in how to keep AI coding agents away from production.
Measuring it
Measure speed of iteration as the time from a commit on main to that change being live on a URL. Write the number down. Then make it smaller.
You do not need a dashboard for this. Open the commit, open the deploy log, subtract. If the answer is minutes, you are in good shape. If the answer involves the phrase “once I get around to it”, you have found your bottleneck, and it is not the code.
A few related numbers worth glancing at:
- Deploys per week. If it is one, something is being batched. Find out what.
- Time from idea to first commit. If it is long, the setup tax is still being paid.
- Time to revert. If a bad change takes an hour to undo, changes will get bigger and rarer to compensate.
The pattern in all of them is the same: the loop is only as fast as its slowest step, and the slowest step is almost never the writing.
Closing
Speed of iteration is the only advantage a new project has, and it is decided by setup, not by effort. A project that can ship in an hour will learn faster than a project that ships in a week, and it will find its wrong guesses while they are still cheap to fix.
TigerSoup exists to make that first hour short. It is a free Mac app that sets up a new project properly: its own AWS account, a private GitHub repository, and keyless deploys that are safe to run on every push. The loop is there before you start, and nothing it sets up costs a cent until you run something.
