Pricing
$5 per completed user story. Starting at 100 stories a month, prepaid.
The minimum is $500, paid in full before work begins. There are no seats to count, and every story is listed on the PRD before it is built.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
$5 per completed user story.
- 2
Minimum 100 stories a month.
- 3
$500 prepaid before work begins.
- 4
Named account manager included.
A sample month
100 prepaid user stories at $5 each comes to $500, paid before work begins. Need more? Your PRDs show the count before you approve.
Send your first user storyThe whole delivery chain, inside one price.
No extras to add on and no seats to count.
Counted up front
The PRD lists each user story, so you know the most a request can cost.
Completed means accepted
A story is complete when its PR meets the acceptance criteria you approved.
Tests included
Unit, integration and browser tests ship in the same pull request.
A person included
A named account manager comes at zero extra cost.
Manual QA included
A person checks the feature before your team sees it.
No lock-in to your code
Everything lands in your repo as ordinary pull requests.
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 | ||
100 stories is a real commitment.
It suits a team with a queue. It does not suit a handful of changes a year.
- You have more requests than your team can ship.
- Someone can review pull requests each week.
- You can pay $500 up front to start.
- You would rather pay for outcomes than for time.
Pay for finished work, not for the hours it takes to finish it
- Most software budgets are built around people. You hire a designer, a frontend engineer, a backend engineer and a tester. Each one has a salary, and each one is paid whether the queue is moving or not. When the queue stalls, the money keeps going out. That is the usual picture, and most budget owners know it well.
- Our price works the other way round. Each completed user story uses $5 of your prepaid balance, and the $500 monthly minimum still applies. A story is completed when its pull request meets the acceptance criteria you approved. A story that does not meet the criteria does not use your prepaid balance.
- This changes how a budget feels. You stop asking how many people you need for next quarter. You start asking how many finished stories you want and what each one is worth to your product. Those are questions you can answer in a meeting, with a list in front of you.
- It also makes the cost of an idea visible before you commit. A request that splits into six stories costs six times $5 when completed. A request that splits into one story costs $5. You can compare the two in a few minutes, and you can decide which one to approve.
- Think of it as buying parts instead of buying a workshop. A workshop has rent, tools and staff whether you use them or not. Parts arrive when you order them, and each one has a price on the box. You still need a clear list of what to order, and the PRD is that list.
- The rest of this page explains how the count works, what the price covers, how it compares with the usual options and what questions people ask first. Read it with one real request in mind. The numbers will make more sense when you can picture the list.
- A hired team is paid while it learns your codebase, waits for decisions and fixes its own mistakes. Those hours are real, and they are paid whether or not a feature lands this month. Under the completed-story rule, work that does not finish does not use your prepaid balance. That is the main difference to hold on to as you read the rest.
What the price covers, from the first request to the merged change
The price covers the whole path from your request to a pull request in your repository.
An agent writes the PRD. Agents build the change, and they test it. A person clicks through the feature against the criteria you approved. Your engineers then review the pull request and decide what merges. Nothing on that list is a separate charge.
The PRD is included.
It lists every user story, the criteria each story must meet, the edge cases and the count. You read it before you approve anything. Because the list is written before the build, you can see the most a request can cost before any work begins.
Tests are included.
Unit tests, integration tests and browser tests ship in the same pull request as the code. You do not buy them as an extra, and you do not have to ask for them on each request. They are part of what a completed story means.
A person checking the feature is included.
Manual QA is done by a human against your criteria before the pull request is raised. That check is part of the price, not an optional add-on, and it is one of the reasons we can describe what a completed story has been through.
A named account manager is included at zero extra cost.
That is a real person who tracks each request from the first email through to the merge. You do not pay for that help as a separate line, and you do not need to chase a ticket queue to find out where your request stands.
There are no seats to buy.
The price does not depend on how many people in your company look at the work or how many people in your team review it. Adding a reviewer does not change the price. Adding a story does, and only when that story is completed.
Think about what you would otherwise pay for.
Each item on the list is a job someone on your team would otherwise do or pay for, such as writing the tests, checking the screen and tracking the request. Those jobs still exist. The price covers them inside the completed story, so you do not have to add them up later.
The price also covers the handover into your repository.
Work lands as ordinary pull requests, with the code, the tests and the description in place. Your team can read, change or merge them in its own tools, and everything lands in your repo as ordinary pull requests.
The PRD, with every story and its count.
Tests in the same pull request as the code.
A person checking the feature by hand.
A named account manager at zero extra cost.
No seats to count.
How the count works, so you can add up your own bill
Start with the PRD.
It lists each user story in plain words. Each story has a short description of what the user can do and a set of acceptance criteria. Count the stories, and you have the number that the price rule uses.
Multiply the count by $5.
That is the cost of the request if every story is completed. For example, a request with four stories costs $20 when all four are completed. A request with six stories costs $30 when all six are completed. These figures are samples to show the rule. Your own count comes from your own PRD.
The minimum is 100 user stories a month.
That is $500. The minimum is the smallest monthly amount you can buy. It is the same $5 rule, with at least 100 stories prepaid each month. How unused prepaid stories are handled is settled in writing before you pay.
Prepayment means a balance of at least $500 is paid in full before work begins.
The PRD shows how much of your prepaid balance the request will use if every story is completed.
Completed means accepted by the criteria.
A story is completed when its pull request meets the acceptance criteria you approved in the PRD. A story that does not meet the criteria does not use your prepaid balance. The criteria are written before the build, so the finish line is clear to both sides.
Your team still makes the final call.
Completed means the pull request meets the criteria. It does not mean your engineers have to merge it. A story counts as completed only when its pull request meets the criteria you approved.
Keep a simple record of each request.
Note the count from the PRD, the stories completed and the total for the month. A short table in a shared file is enough. Your finance lead can then check the number against the list without asking anyone to rebuild the math.
When you read a PRD for price, look at the criteria before you look at the count.
A story with vague criteria may look cheap, but it is hard to call completed. A story with clear criteria costs the same $5, and it is much easier to say whether it is done.
Count the user stories in the PRD.
Multiply the count by $5.
Minimum 100 stories a month, which is $500.
Paid in full before work begins.
A story is completed when its pull request meets the approved criteria.
A budget that stays predictable when the queue changes
A predictable budget helps you plan.
You know the cost of each completed story, so you know the cost of any mix of stories you approve. If your product needs ten small changes this month and two large ones, the PRD tells you the count, and the count tells you the price. There is no surprise hiding in an hourly rate.
A predictable budget also helps you say no.
If a request costs more than the value you expect from it, you can cut stories, split the work into a later month or drop it. Those choices are made before the build, while they are cheap to make.
A predictable budget helps your finance lead.
The question is always the same: what did we buy, and what did it cost? The answer is a list of completed stories, each with its price. That is easy to check and easy to explain to people outside the product team.
A predictable budget also keeps the focus on the product.
Your meetings can talk about what the product should do, instead of how many people are needed to do it. The question moves from who is on the team to what is worth building next.
Prepayment makes the budget clearer still.
The money for the month is set aside before the work starts, so the plan does not depend on a payment that might be late. You know the number at the start, and you know the work it covers.
The honest limit is that you need enough requests to reach the minimum.
A team with only a few changes a year will find the 100-story minimum too large. That is a fair reason to look at other options, and we would rather say so now than after you pay.
Plan the queue in months, not in single weeks.
A steady flow of requests is easier to price than one large burst. If you expect at least 100 completed stories across the month, the minimum is simply the floor of the plan, and it never feels like a penalty.
Budgets also work better on a regular rhythm.
A short review each month, comparing the stories completed with the stories approved, shows where the queue is slow and where it is steady. That review takes minutes, and it gives you a clear reason to adjust the next month's requests.
Set against a hire, a pod and an agency, in plain numbers
A hired pod is the first comparison most teams make.
Our site uses a four-person feature pod as an example: a designer, a frontend engineer, a backend engineer and a QA engineer. The example uses US salaries, and it puts the direct salary cost at $45,800 a month. That figure is direct salary only. It does not include hiring, tools or the time a manager spends on the team.
The same site puts a pod at $715,000 a year, fully loaded, and says that cost is paid whether the queue moves or not. It also puts a typical feature at 22 business days in a traditional squad, made up of design 5, build 8, QA 5 and fixes 4. These are the figures on our comparison page, and we give them here as stated there. Check them against your own numbers before you rely on them.
The usual alternative to a hire is a coding tool.
Seats for a coding tool usually cost less than a hired pod, and they can speed up drafts. The catch is the work around the draft. Someone still has to write the criteria, run the tests, check the screen and review the change. If that someone is your team, the tool saves typing and costs review time. Our price includes those steps in the completed story.
An agency is the other common route.
An agency usually prices a block of work, and changes to the block are negotiated. The total can grow as the scope grows. Ask the agency what it checks before a change reaches your reviewers, and what it charges when the work is late or unclear. Hold those answers up against the completed-story rule on this page.
The honest comparison depends on your work.
A hired pod suits a steady stream of hard problems that need someone every day. A coding tool suits a team that already runs strong checks and wants faster drafts. An agency suits a whole area you want handed over. A story list suits a queue of clear requests, where you want to pay for finished pieces and count them before you approve.
Whatever you choose, run the same test.
Take one real request, count its stories, price it at $5 each and compare that with the cost of the other route for the same work. The numbers on one request will tell you more than any table on a page.
When you compare, count the costs that do not appear on a price list.
For a hire, that means recruiting time, onboarding and management time. For an agency, it means the time spent agreeing the scope. For a coding tool, it means the review and test time that stays with your team. Put those next to the price, and the picture is more honest.
Hard questions about pricing, answered in full
What counts as a completed story?
A story is completed when its pull request meets the acceptance criteria you approved in the PRD. The criteria are written before the build, so the finish line does not move. Each completed story uses $5 of your prepaid balance.
Can I see the full price before I pay?
Yes. The PRD lists every story before any work begins. You can read the stories, count them and multiply by $5. The PRD lists the stories before any work begins. Payment is made in full before work begins.
What if I am below the minimum?
The minimum is 100 user stories a month, which is $500. If you need less than that, tell us what you have in mind. We will be straight with you about whether the minimum fits your queue. We would rather say no now than sign you up for a plan you will not use.
What happens if a story is not accepted?
A story that does not meet its acceptance criteria is not completed, so it does not use your balance. Your engineers can send a change back, and a story counts as completed only when its pull request meets the criteria you approved.
What if we want to change a story after approval?
Tell us as soon as you see the need. Ask us how the change is counted before any work begins on it, and we will answer in writing. Nothing changes quietly, and the count stays visible to you.
What happens to stories I do not use?
Ask us before you pay. How unused prepaid stories are handled is settled in writing before you pay, and that written answer is what applies to you. We do not want you to rely on this page for that answer.
Is there a seat fee or a per-user fee?
No. There are no seats to buy and no per-user charge. The price is per completed user story, with a minimum of 100 a month.
Who do I talk to about the bill?
You talk to your named account manager, who is a real person at zero extra cost. You can also write to us using the button on this page, and a person will answer.
Do you charge for changes to the criteria after approval?
Ask us how a change to an approved PRD is counted, and get the answer in writing before you approve.
Can we pause a request and restart it later?
Tell us before you pause. Ask how the stories already approved are handled, and get that answer in writing before you decide. We do not want a pause to be a surprise on either side.
See the count for your own request before anything is built
- The simplest next step is to count your own request. Write down the change you want in plain words. Split it into the user stories you think it needs. Count them, and multiply by $5. You now have the rough cost of the request, before you have paid anything.
- Then send the request to us with the button on this page. Include the change in plain words and any detail that matters, such as who uses the feature and what must not break. We will reply with a written PRD that lists each story, its criteria and its count. Set it beside your own count, and you will see quickly whether the price fits.
- Read the PRD before you approve it. Ask us in writing when the prepayment is due. Nothing is built until you approve.
- If you want a small first request, send one story. The $500 minimum still applies. It is a fair test of how the list works, how the criteria read and what the pull request looks like before you commit to more.
- Treat the sample numbers as a guide, not a quote. A sample of one story at $5, four stories at $20 and six stories at $30 shows the rule. Your request may sit anywhere between those numbers, and only your PRD can say where. Nothing in this page replaces the list you will read and approve.
- Which terms apply to my order? Your signed agreement or written order applies if it differs from anything on this page. The terms page and the refunds and billing page set out the rest, and we will answer any question about them in writing.
Write the change in plain words.
Split it into user stories and count them.
Multiply the count by $5.
Send the request using the button on this page.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1What does $5 per completed user story mean?
Each request becomes a PRD that lists its user stories, like "an admin can export the current report as CSV". A story counts as completed when its pull request meets the acceptance criteria you approved. Each one uses $5 of your prepaid balance. The minimum is 100 user stories a month, $500, paid in full before work begins.
2How do I know what a feature will cost before it starts?
The PRD lists every user story before any work begins. Multiply the count by $5, and that comes out of your prepaid balance. Nothing gets built until you approve it.
3How 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.
4What if I need help along the way?
You get a named account manager. That is a real person who tracks every request through to the merge, at zero extra cost. Founders are one email away too.
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.