Compare
Three ways to clear a backlog, and who does the work in each.
Hire a pod, buy coding tool seats, or send us user stories. Each one is right for somebody. Here is the honest view.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
$45,800 a month for a pod, in salary.
- 2
22 business days per feature in a pod.
- 3
Seats leave the process with you.
- 4
$5 per completed story here.
One feature pod costs $45,800 a month. That buys 9,160 completed user stories here.
Example US salaries for a designer, frontend engineer, backend engineer and QA engineer. $45,800 is direct salary only, before hiring, tools or manager time.
Hiring a pod
Four people, working one after another.
- $715,000 a year, fully loadedYou pay it whether the queue moves or not.
- 22 business days per featureDesign 5, build 8, QA 5, fixes 4.
- Three months to hireThen six weeks to ramp up, then notice periods.
- Edge cases get cutSmall asks lose to the sprint every time.
AI agents, working in parallel.
- $500 a month to start100 user stories at $5 each, prepaid. That is the minimum.
- 3 business days from approved PRDThat gives you back 19 days on every feature.
- Live the week you signNo recruiter fees and no bench time.
- Edge cases get builtEach one is its own $5 user story, so it finally makes the cut.
A coding tool needs an owner. We are the owner.
Seats are cheap because they are unfinished. The expensive part of AI engineering is the process around it, and that is the part we run.
| Who does the work | Claude Code / Codex seats | AgentCTO |
|---|---|---|
| Writing the PRD and edge cases | Your PM or lead | Included |
| Prompting, steering, re-runs | Your engineers, hourly | Included |
| UI and design decisions | Still a designer's job | Included |
| End-to-end QA and regressions | Manual, on your QA | Included |
| Accountability for delivery | Yours | Named account manager |
| Real cost | Seats + the salaries driving them | $5 per completed user story |
| Send your first user story | ||
| Send your first user story | ||
When the others are the right call.
We lose this comparison sometimes, and that is fine.
- 1
Hire when the work needs people in the room
If you need someone setting product direction every day, or running on-call for your systems, hire. We take requests and ship them. We do not replace your team.
- 2
Buy seats when you have spare engineering hours
If your engineers have time and enjoy driving agents, seats are great value. If those hours do not exist, a faster way to type does not create them.
- 3
Use us when the queue is the problem
You have a repo, a backlog that keeps growing and someone who can review pull requests. That is the shape we fit.
Count what your backlog costs you this month
- Every backlog has a cost, even when nobody writes it down. A feature waits for a designer. Another waits for an engineer. A small edge case gets cut to protect the sprint and never comes back. Those costs are real, but they rarely show up on a budget line.
- Start by writing down what waiting costs your product. Pick the three features that have been postponed longest. For each one, note who was meant to build it, how long it has sat, and what it would have changed for your customers.
- This is not a sales exercise. It is a way to see the size of the problem before you choose a fix. Some teams find that their queue is mostly small asks. Others find it is a few large features that keep losing to urgent work. Both need different answers, and the right option depends on which picture is yours.
- Once you know the shape of your queue, the three options on this page become easier to judge. You are not asking which option sounds most modern. You are asking which one clears the kind of work you actually have.
- The rest of this page sets out the options as honestly as we can. We include the cases where another option is the better call. That is the only way a side-by-side look is useful to you, because a list that always ends in our favour is just an advertisement.
- Keep your list of postponed features to hand while you read. Test each option against real items from that list, not against an abstract idea of a backlog. Real items will show you the differences that a summary hides.
See what each option costs in money and in time
The three options cost different things.
A hire costs a salary, plus the months it takes to find someone and bring them up to speed. Coding seats cost a fixed fee for each person, plus the hours your engineers spend steering the tool. Our model costs $5 for each completed user story, from a monthly minimum paid up front.
Money is only one part of the picture.
Time matters just as much. A feature that takes 22 business days in a traditional pod holds up everything behind it. A feature that reaches a pull request within three business days of your approval changes what your team can plan around.
The figures on this page come from the example salaries and timings in our own side-by-side figures. Treat them as examples, not as promises for your team. Your salaries, your stack and your review process will move the numbers.
The pod example uses four roles:
a designer, a frontend engineer, a backend engineer and a QA engineer. Example US salaries add up to $45,800 a month in direct salary. Our fully loaded figure for the same pod is $715,000 a year. Direct salary is before hiring, tools or manager time, so the two figures should not be read as the same thing.
Seats are a fixed cost for each person.
You pay for them whether or not a feature ships this month. That is simple to budget, and it is also why the output depends so much on how much time your engineers have to spare.
Time has a second form, and it is the one teams forget.
Someone on your side reviews the result, whichever option you pick. Plan that review time as part of the cost. A pull request that is quick to check is cheaper than one that takes a long afternoon, and that holds for every model on this page.
AgentCTO costs $5 for each user story that is completed.
The minimum is 100 stories a month, which is $500, and it is paid in full before work begins. Each completed story uses $5 of that balance. The minimum is the smallest commitment you make, and the price per story is what you pay for finished work.
Know what the money buys, and what it leaves out
A $500 minimum sounds small next to a salary.
That is a fair first reaction, and it is the wrong sum if you stop there. The minimum buys 100 completed stories, not a whole feature team with a year of salary behind it.
A feature is worth as many stories as its PRD lists.
A small change might be one story. A larger feature might be a dozen. The PRD lists every story, and you approve the count before anything is built. The cost of a feature is known before work starts, which is the part of budgeting that most teams find hardest to get from a hire.
On the arithmetic behind our figures, $45,800 a month buys about 9,160 stories at $5 each.
Treat that number with care. It is simple division. It is not a promise that a pod would produce that many stories, and it does not mean every story is the same size.
Money also leaves things out.
A salary pays for a person who can sit in a meeting, answer a customer and own a product over time. Our model does not replace that person. Your team keeps product direction, on-call duty for your systems and the final say on every merge.
The $500 minimum has its own limit.
It suits a queue. If your real need is one or two changes a quarter, a minimum of 100 stories a month is the wrong shape, and it is better to find that out now than after you pay.
A hire also carries waiting that does not appear in a salary.
There are three months to find someone, six weeks to ramp up, and notice periods if the person later leaves. Our model has no recruiter fees and no bench time. It still leaves your review time with you, and that is the point of the final gate.
Read the money as a question about shape.
Does your queue need a steady flow of small and medium items? Or does it need a few big items that a person must lead from start to finish? Your answer tells you which option gives you the most value for your situation.
Each option, side by side on what you control
Here is what each option gives you, in the same order, so you can read across the lines and hold your own week against each one.
Hiring a pod:
four people working one after another. Around 22 business days per feature in our example, split as design 5, build 8, QA 5 and fixes 4. Three months to hire, then six weeks to ramp up, then notice periods.
Coding tool seats:
a fast way to produce a first draft. Someone on your team still writes the PRD, steers the tool, makes the design calls and runs QA before anything is merged.
AgentCTO:
we write the PRD and list the stories. Agents build UI, frontend, backend and tests in parallel. A person runs manual QA. A pull request arrives within three business days of your approval, and you get a named account manager at no extra cost.
Agencies:
a team brought in under its own proposal, usually for a defined project. We do not have a price for them on this page, because each agency sets its own terms, and we would rather not guess.
Set your own numbers beside ours
Do not rely on our example alone.
Put your own numbers in. The method is simple, and it takes less than an hour with your queue list in front of you.
Count the features in your queue that you would like to ship this quarter.
For each one, estimate how many user stories it would need. A small change may be one story. A medium feature may need several. Add the stories up and multiply the total by $5. That gives you a rough cost for your queue under our model. The PRD will give you the real count, and you approve it before any work starts.
Then price the same queue with your own team.
Take the monthly cost of the people who would build it, and divide it by the features they would ship in a month. Your figure will differ from ours. That is useful, because it shows you where your own numbers stand.
Lay the two figures side by side.
Add the waiting time as well. Count the business days from approval to a mergeable change, for each model. A figure that is slightly higher but arrives three weeks sooner can still be the better answer for your product.
If the numbers clearly favour one option, you have your answer.
If they are close, the deciding factor is usually the wait, or the question of who you want to own the work. Those are judgments only your team can make, and that is how it should be.
Pick the option that fits how your team already works
The right option is the one that matches how your team really works, not the one that sounds most modern. A tool that your team cannot use well is not a bargain, however low its price.
If your engineers have spare hours and enjoy driving agents, coding tool seats can be good value. They give your people a faster way to draft code. Be honest with yourself about whether those hours really exist. A faster way to type does not create time that is not there.
If you need someone setting product direction every day, or running on-call for your systems, hire. Those jobs need a person in the room, and no model option replaces that person.
If your queue is the real problem, and you have a repository plus someone who can review pull requests, the shape of AgentCTO fits. You keep the decisions. We take the building and the testing off your hands, and you review the result the way you review any other pull request.
Many teams end up using more than one option.
They hire for direction, keep seats for their own engineers and send the backlog of small and medium features to us. That mix is not a failure of any one option. It is a sign the team has matched each job to the right owner.
Pick by the job, not by the label.
Write the job down. Name the owner you want for it. Then choose the option that fits that owner.
A useful test is to ask who would notice first if the queue stopped moving.
If the answer is a founder or a product lead, they need a clear say in what gets built. If the answer is an engineer, they need relief from the waiting. Match the option to the person who feels the pain.
Where each option wins, and where it loses
We would rather show you where we lose than let you find it later.
Each option below has real strengths, and each has a clear limit.
Hiring wins when you need a person who makes product calls, joins your planning every week and carries knowledge about your business. It loses on speed, on the cost of starting and on the time it takes to ramp a new person up to full output.
Coding tool seats win on cost per person when you have engineers with spare time.
They lose when those engineers do not have the time, because the work of prompting, checking and fixing still lands on them.
AgentCTO wins when the queue is the problem.
You get a PRD before any work, a pull request within three business days of approval, tests in the same change and a person doing manual QA. It loses when you have only a few changes a year, when nobody on your side can review code, or when you need someone to make product decisions for you.
Agencies win when you want a team to come in for a defined project, with its own people and its own process. They can be the right call for a one-off build. Set their proposal line by line beside ours, because each agency sells its work differently.
If you read this and conclude that another option is better for you, that is a good result.
We would rather you pick the right tool for the job than sign with us for the wrong reason. Plain reasons are the only ones that hold up in a year's time. Pick the option that fits the job, and be ready to change your mind if the job changes.
What happens to stories we do not use in a month?
We have not settled every detail of prepaid balances on this page, and we will not guess at them here. Ask us in writing before you pay. We will answer in writing, and that written answer is what applies to you.
It is a fair question, and it matters more than the price per story.
Ask it alongside the minimum, so you can judge the full commitment before any money moves.
What if seats are already enough for us?
Then keep them. Seats are a good fit when your engineers have time and want to use the tool. We are not trying to talk you out of a setup that works.
We would only ask you to check two things.
Does the work still reach a mergeable pull request on time? And does the review load stay manageable for your team? If both answers are yes, seats are doing their job, and you have no reason to change.
What if we need a hire and a delivery partner?
That is a common shape. A hire sets direction and owns decisions. A delivery partner clears the queue of small and medium stories. The two roles do not compete with each other, and many teams find they need both.
If you go this way, ask us how the PRD and the approval step fit with the person who owns your product. The approval is yours to give, so keep it with the right person on your side.
Will the first request feel slower than the rest?
- The first request carries the most setup, because access has to be agreed before work starts. Plan for that, and do not judge the whole model by the first week alone.
- Judge it over more than one request. The first one tells you how the PRD reads and how your team reviews a pull request. A second request tells you whether the pattern holds.
Why is the minimum higher than I expected?
The minimum is 100 stories a month, which is $500, paid in full before work begins. That is the commitment we ask for, and we state it in every place it matters.
If your queue is smaller than that, the minimum will feel high.
Say so early. We would rather tell you it does not fit than sign you up for work you will not use. A short conversation now is cheaper for both of us than a dispute later.
Is $5 per story a fair price?
- Judge it by what a story contains. Each story is a small, testable thing a person can check, with acceptance criteria you approved in the PRD. A completed story means its pull request meets those criteria, and nothing less.
- The price is only fair if the stories are the right size for your product. Check the PRD carefully before you approve it. If a story is too large to test in one go, say so, and the PRD can be changed before any work begins.
What if an agency would be cheaper for one project?
It may be. A single project with a clear end can suit an agency well, and we do not pretend otherwise. What matters is the shape of your work.
If your need is an ongoing queue of features rather than one build, an agency's project model may not match it well. Ask any agency how they would price your whole queue, not just the first project. Then ask us the same question, and set the answers against the same list of features.
Who is accountable when something goes wrong?
In a hired pod, the team and its manager are accountable. With coding seats, your own team is accountable for the result. With us, a named account manager tracks each request through to the merge, and your engineers decide what merges.
We do not ask you to trust us over your own review.
Your review is the final gate, and it stays with your team. If something goes wrong after a merge, the first step is the same as it would be for any change your team ships: find the cause, fix it and check it again.
Work out your queue this week, then decide
Take the list of postponed features from the start of this page.
Put a rough story count against each one. Add a note on who would review the work and how long a review usually takes on your side.
Then choose the option that clears that list at a cost and speed you can live with.
If that is us, use the button on this page to send your first user story. Include the feature, your stack and where the code lives.
We will send a PRD the same business day.
You read the stories and their cost, approve what is right, and a pull request arrives in your repository within three business days of your approval. Your team reviews it and decides what merges.
If the answer is still not clear, that is fine.
Send the queue list anyway. A first look at real items is often the fastest way to find out which option fits.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1How is this different from Claude Code or Codex?
Those are tools, and they need an owner. Someone on your team still writes the PRD, steers the agent, makes design calls and runs QA. We do all of that and hand you a tested pull request.
2How fast will I see results?
You get a written PRD the same business day you raise a request. After you approve it, the pull request lands within three business days. A traditional four-person squad takes about 22.
3Is this right for us?
It fits if you have a repo, a backlog, and someone who can review pull requests. It does not fit if nobody on your side can review code, because your team makes the final call on every merge.
Send the feature your roadmap has carried for a quarter.
We open the PRD the same business day. Three business days after you approve it, a pull request is in your repo. Judge us on the merge.
Minimum 100 user stories a month, $500 prepaid. No mail app? Write to udit@tinycheque.com.