The changes you have in the air
The rate does not move however many changes you brief. This page owns the other half: how much change one month actually carries, what order it ships in, and what slows one down.
The rate is uncapped. The calendar is finite.
Three places on this site say the price does not cap. None of them say how fast a change actually ships. This page does.
How many changes you brief to the agent
The iteration add-on is a flat monthly line, however many changes you brief in a month.
Checks are not metered
Every change runs the same pipeline of checks, on every plan, as many times as it needs to. There is no per-check fee and no cap on how many run in a month.
A deploy itself has no separate charge
Shipping a change is part of every plan, as often as you need it. There is no per-deploy fee and no cap on how many ship in a month.
Every one of those is true, and none of them promises a delivery time. A flat rate fixes what a change costs, not how many calendar days it takes to ship. That is what the rest of this page sets out.
An agency or freelancer on retainer: Changes queue behind whatever else that person or shop is billing hours to this week, and the retainer is priced for their time, not for the size of any one change. Here, the rate is flat and the work is not queued behind anyone else's invoice — see Compare for the rest of that comparison.
The unit the flat rate carries
The iteration add-on prices a small copy or config change, briefed and reviewed start to finish. Not every ask is that size.
A briefed change
A single, clear ask — a small copy or config change, briefed and reviewed start to finish. It goes in, an agent opens a pull request, a person reviews it, and it ships.
A briefed change that needs a decision
The same ask, but the answer to "what should this actually do" is not yours yet. The clock on the change does not start until that call is made.
A rebuild
A new design, a new feature set, or a change to the shape of what runs. This is CustomLabs build work, not a briefed change — see the examples below.
Still a briefed change
A resize looks like more room. Often the real fix below is smaller than it looks.
An unindexed query
A slow query run on every page load can look exactly like a compute shortage. Adding the missing index is usually a smaller fix than a bigger tier.
An unresized image
Serving a large photo at a small width burns transfer and memory for no visible gain. Resizing it at build time often does more than moving up a tier would.
A background job with no backoff
A job that retries immediately, over and over, can make the whole instance look short on room. Often the real fix is a short wait between retries.
A cache that never gets used
Recomputing the same answer on every request costs headroom. Caching it once usually saves more than moving up a tier ever would.
A rebuild, not a resize — CustomLabs, quoted
Changing the shape of what runs is a design conversation, not a briefed change.
A queue between two services
When one part of the app has to keep working while another catches up, that is a queue to design, not a bigger instance.
A read replica
When read traffic alone is the bottleneck, a second database built for reads is a rebuild, not a resize.
A second region
Running compute closer to a second cluster of users is a new deployment to design, not a tier to move up to.
One pipeline, one main branch, one review
There is no second lane. Two changes that touch the same files cannot both be in flight, so one finishes — reviewed, merged, and shipped — before the next one starts.
Every change resolves to exactly one of three outcomes before the next one takes its place on the same branch:
Approve
The change is correct. Merging it sends the same pipeline that built staging to production.
Ask for a change
Say what is wrong, in plain language. The agent reads the note and updates the same pull request.
Close it
The change is not needed after all. Closing it drops the branch — nothing merges, and nothing ships.
You do. We do not re-rank your work.
A change ships in the order you brief it. There is one exception, and it has its own page.
A flagged dependency does not wait behind whatever else is in the queue — it moves to the front, briefed and shipped through the same pipeline as any other change:
- 1
A routine scan flags a dependency
The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.
CustomHosted
- 2
It's triaged as application-level, not infrastructure
A library your own code imports isn't ours to patch silently — it can change how the app behaves.
CustomHosted
- 3
Briefed as a change
Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.
CustomLabs
- 4
An agent opens the pull request
The upgrade lands as a real pull request against the repository, with the test suite run against it.
CodeHerder
- 5
A human reviews and merges
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
CustomLabs
- 6
It ships through the same pipeline
The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.
CustomHosted
- 7
You're told it's done
A note confirming what changed and that it merged, in the same shape as every other note on this site.
CustomHosted
Outside that one case, we do not decide what matters most to your business. See Patching for the security lane in full.
Six things that add time, each with a route out
Not the pipeline. Almost always one of these.
| What slows it | Why | Owner | Route out |
|---|---|---|---|
| A brief that needs a decision | The agent cannot guess the answer to a genuine product call. The change waits until you make it. | You | Brief a change |
| A red check | A failing check stops the change before it reaches a reviewer. Fixing what it flagged comes first. | CodeHerder | Checks |
| A change that needs a second environment | Some changes need to be clicked through somewhere that is not production first. That standing rehearsal has to be ready before the change can be checked. | CustomHosted | Environments |
| A change that is really a rebuild | A briefed change assumes the shape of the app already exists. Changing that shape is a design conversation first. | CustomLabs | Custom |
| A third-party dependency | Waiting on someone else's API, library, or approval is not this platform's clock to control. | CustomLabs | Outside services |
| A change that needs a data migration | A schema change takes a snapshot first and ships inside the same deploy — safer, but not instant. | CodeHerder | Databases |
One real project, measured
Every figure below is read from this repository's own merge history. It is an observation of one project, not a promise about yours.
- Calendar window measured
- 2026-07-07 → 2026-10-03 (89 days)
- Days with at least one change shipped
- 84 of 89 days (94%)
- Median changes on a day something shipped
- 1
- Longest stretch with nothing shipped
- 2 days
| Month | Days a change shipped |
|---|---|
| July 2026 | 25 |
| August 2026 | 31 |
| September 2026 | 25 |
| October 2026 | 3 |
No per-change turnaround and no changes-per-month guarantee is published above — see The honest limits for why.
One flat line, until it is a rebuild
Brief a change in plain words. An agent opens a pull request, a person reviews it, and the same pipeline ships it.
- Agentic iteration — CodeHerder
- $25/mo flat
That line covers every size of ask in "What one change is" above, except a rebuild. A rebuild leaves the add-on behind and becomes a Custom quote instead.
Said plainly
No posted turnaround, no second lane, and no backlog tool run for you.
No posted per-change turnaround
There is no promised number of hours or days for one change. We have not measured a delivery time we would stand behind, so we do not post one.
One change in the air at a time
There is no second lane. Two changes that touch the same files cannot both be in flight, so one finishes — reviewed, merged, and shipped — before the next one starts.
No backlog tool run on your behalf
We hold the order you give us. We do not run a project-management board, a ticket queue, or a prioritisation meeting for you — that stays yours.
In flight, answered
The questions a buyer actually asks about pace, order, and volume.
01Is the iteration add-on really unlimited?
The iteration add-on is a flat monthly line, however many changes you brief in a month. The rate is uncapped, but the calendar is finite. See "Uncapped is not unlimited" above for what that means in practice.
02How many changes can I brief in a month?
As many as you want to write. How many actually ship in a month depends on their size and order, not a posted number — see "This site's own cadence" above for what one real project looks like.
03How long does one change take?
There is no promised number of hours or days for one change. We have not measured a delivery time we would stand behind, so we do not post one.
04Can I brief two changes and have them both worked on at once?
There is no second lane. Two changes that touch the same files cannot both be in flight, so one finishes — reviewed, merged, and shipped — before the next one starts.
05What if I brief ten things at once?
All ten go in. They still ship one at a time, in the order you gave them, unless a security patch needs to go first — see "What sets the order" above.
06Can I mark a change as urgent?
You can tell us it is urgent, and we will reorder around it. There is no separate rush fee and no automatic priority queue — the order is a conversation, not a setting.
07Do you use a backlog or ticketing tool I can log into?
We hold the order you give us. We do not run a project-management board, a ticket queue, or a prioritisation meeting for you — that stays yours.
08Is this different from an agency retainer, where changes queue behind other clients?
Yes. That is the retainer's own trade-off. Changes queue behind whatever else that person or shop is billing hours to this week, and the retainer is priced for their time, not for the size of any one change. Here the rate is flat, and your changes wait on no other client's invoice.
In flight connects to
- The Loop
The commercial arc this page sits inside — build, iterate, run, and why an agent in the loop makes the iterate step faster.
- Brief a change
What to say in a brief, so the change that goes in the air is the one you actually meant.
- Review
The pull request itself, who decides, and what happens to a shipped change that turns out wrong.
- Checks
The pipeline that gates every change before it reaches a reviewer — whose checks they are, and what a red one stops.
- Billing
The invoice this page never re-derives from — the flat line that stays flat, however many changes you brief.
- Limits
Every limit this site publishes, collected in one place — including the three this page owns.
Ready to brief the first one?
Describe the change the way you'd explain it to a person — the same quote channel starts the loop.