Nobody can review code
Your team makes the final call on every merge. If no one can, this will not work.
Who it is for
For teams whose requests arrive faster than they can ship them.
You do not need a bigger plan. You need the queue to move while your team keeps doing the work only it can do.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
You have a repo.
- 2
You have a backlog.
- 3
Someone can review pull requests.
- 4
You want outcomes, not more seats.
Good fit
This tends to fit when one of these is true.
If you nodded at one, send us a request.
The roadmap keeps getting edited
Small asks get cut to protect the sprint, and customers stop asking.
Hiring is too slow
Three months to hire, six weeks to ramp, and the queue grew the whole time.
You run a legacy product
Old PHP, .NET and Java are in scope. Nobody needs to volunteer to touch it.
You lead engineering and are the bottleneck
Your team keeps the review. It loses the waiting.
You run product without enough engineers
You can write what you want. You need someone who can review it.
You tried coding tools
They worked, and then someone had to own all the rest.
Not a fit
Please do not buy this if any of these are true.
We would rather tell you now.
You have a few changes a year
The minimum is 100 stories a month. A small job is the wrong shape for that.
You do not have a product yet
We work from your repo and your requests. We do not decide what your company should be.
Picture the queue moving while your team keeps its focus
Think about your backlog on an ordinary Monday.
There is a list of requests, and the list is longer than it was last month. Some items have been there for a quarter. A few are small asks that never made it past the sprint planning meeting. Your team knows about all of them, and nobody has time to build them.
Now picture the same list a month from now.
Some items are merged. The small asks have finally shipped. The edge cases that customers kept mentioning are handled, with tests in the code. Your engineers spent their time on the work only they can do, and they did not spend it chasing the queue.
That is the change this page is about.
You do not need a bigger plan or a new set of tools to see it. You need the queue to move while your team keeps doing the work that only your team can do. For the right kind of team, that is a real and practical goal.
It is also a goal you can test.
Look at your backlog and count the items that have waited longest. Ask who would build them if you had the time. If the honest answer is nobody, you have the problem this page is written for.
The rest of this page explains who tends to fit, what you need in place, and where it does not suit a team. We would rather you leave this page knowing the truth about your situation than sign up on a hope.
Your team keeps the work only it can do
Most engineering leaders are not short of ideas.
They are short of hours. The best people spend their weeks on the hard problems in the product, the architecture decisions and the customer escalations. The small and medium features get pushed down the list, not because they are unimportant, but because nobody can see the time to build them.
If you have a team like that, the value of an outside queue is simple.
The work that is clear and testable moves to us. Your engineers keep the review, the design of the hard parts and the decisions that only they can make. They lose the waiting, and they lose the context switching that comes from picking up small tasks between big ones.
This is not a plan to remove your engineers.
Your team keeps the final say on every merge. An unmerged pull request changes nothing in your product, and your reviewers decide what is good enough to land. We take the building and testing of defined stories, and they keep the judgment.
For a founder or product lead, the same logic applies from the other side.
You can write what you want in plain English. You do not have to turn it into tickets and specifications before anyone will start. You do have to approve the scope before work begins, and that approval is the part you keep.
This works best with a clear owner for the backlog and a clear reviewer for the code.
When both roles are filled, the queue has somewhere to go. When one is empty, the work will stall at that gap, and no outside team can fix a gap in your own decisions.
The kind of team this tends to suit
Some teams are a clear fit on the first read.
They have a repository, a backlog that keeps growing and at least one person who can review pull requests. They want to buy finished work, not more seats, and they can commit to a regular flow of stories rather than a single burst.
Other teams fit once they look at their own queue.
A team may have a backlog of forty small items and only three large ones. In that case the flow of small stories is the main value, and the minimum commitment becomes easier to justify against the work it clears.
The roadmap keeps getting edited, and small asks get cut to protect the sprint.
Hiring is too slow to help, with months to find someone and weeks to ramp up.
You run a legacy product, and nobody volunteers to work in the oldest parts of it.
Engineering leadership is the bottleneck, and the team loses time to waiting rather than to building.
Product is clear on what it wants but lacks the engineers to build it.
You tried coding tools, they worked, and then someone on your team had to own everything around them.
What you need in place before you start
- The work starts from your repository, so a few basics matter. Think of them as the entry ticket. None of them is hard to arrange, but each one needs an owner on your side, and it is better to name the owner before the first request than after it.
- A repository is the first item. We raise pull requests on your repository, so we need access to the code the work touches. Give access only to the repositories in scope, and agree the terms with your account manager before any work begins.
A repository we can raise pull requests on, with the code the work touches.
A backlog of requests, even a messy one.
A list of postponed features is enough to start.
Someone who can approve a PRD.
This is the person who says yes to the scope and the cost.
Someone who can review pull requests.
Your team decides what merges, so this role is required.
A way to pay the prepaid minimum, in full, before work begins.
Code in the stacks you already run
We work across the stacks most product teams already use.
Backends include PHP with Laravel, Node.js, Python with Django, Java with Spring, .NET and Go. Frontends include React with Next.js, and mobile work with Flutter and React Native. Databases can be SQL or NoSQL.
If your system uses one of these, we can start from your repository as it is.
If your system uses something not listed here, do not assume the answer is no. Ask us, and describe your stack in a short email. We will tell you plainly whether we think it fits.
Legacy code is welcome.
A ten-year-old PHP service with its own habits is not a reason to say no. The agents read your repository first, and they follow the patterns they find there. The aim is new code that looks like the code around it, not a fresh framework brought in for one feature.
Some teams worry that old code will be too hard.
That worry is fair, and it is also the reason the first PRD matters. The PRD shows how we read your code before any building starts. If we misread it, you will see that before you approve, and that is the cheapest place to find it.
Teams that look like this, described plainly
These are illustrations of the kind of team that fits.
They are not customers, and they are not quotes. We are not showing praise we do not have, so the examples below describe fit, not results.
A product lead with a growing list of requests.
They can write what they want in plain English, but they have no one free to build it. For this person, the value is in turning a list of postponed features into finished pull requests, with each story counted up front.
An engineering lead who is the bottleneck.
Every change passes through them for review, and they cannot keep up. For this person, the value is in taking the building and the testing of defined stories off the team, so the lead spends the time on review and design instead of chasing the queue.
A founder with a small engineering team and a long to-do list.
They want the product to move without hiring for every task. For this person, the minimum commitment is the main question, and it is worth asking whether a steady flow of stories matches the business.
A team that runs an older product.
The codebase is large, and few people want to work in its oldest parts. For this person, the value is in having the small, careful changes done with tests, in the existing patterns, reviewed by people who already know the system.
A ten-minute test to see if you fit
You can check fit in about ten minutes, before you write to us.
Answer these questions honestly. If most of your answers are yes, this is worth a request. If most are no, the page has done its job and saved you time.
Start with the repository.
Is the code in one place, and can you say which repositories the work would touch? If the answer is that nobody knows, sort that out first. A first request can stall when nobody owns the approval.
Do you have a repository we can raise pull requests on?
Do you have a queue of at least a hundred stories' worth of work a month, or a steady path toward it?
Can someone on your side approve a PRD within a day or two of receiving it?
Can someone on your side review pull requests every week?
Can you pay the prepaid minimum before work begins?
Would you rather buy finished work than more seats?
Read your answers honestly before you write
If you answered yes to most of these, send us a request. If you answered no to the review question or the queue question, be honest about that in your first email. We will tell you plainly whether we think you should wait, and a clear no now saves both of us a month.
A mixed set of answers is normal.
Many teams have one gap to close, such as a reviewer who is not yet named. Name the gap in your email, and we can talk through whether it can be closed before the first request.
Where the fit is clear, and where it is not
The fit is clear when you have a repository, a backlog and a reviewer. It is also clear when you want outcomes rather than seats, and when a steady flow of work fits the way your business plans.
The fit is not clear when nobody on your side can review code.
Your team makes the final call on every merge, and that call needs a person who can make it. If that person does not exist yet, hire first, or wait until they do. We would not want you to pay for pull requests that nobody can judge.
Do not buy this if you have few changes a year
The minimum is 100 user stories a month. That is a real commitment, and it is built for a team with a steady queue. If your team ships a handful of changes a year, a monthly minimum of this size is the wrong shape for your work. A smaller need is better served by a person or a small contract, and we would rather say that clearly now.
The same is true if your need is a single project with a clear end date.
Projects of that kind can suit a different model. Tell us about it, and we will be honest about whether we are the right fit, even if the honest answer is no.
We do not decide what your product should be
We work from your repository and your requests. We do not decide what your company should become, which markets to enter or which features matter most to your customers. Those are product decisions, and they belong to you.
If you do not yet know what to build, this is not the right place to start.
Get a clear product direction first, even a rough one, and then come back with a feature. We are good at turning a clear request into a tested pull request. We are not the people to find the request for you.
A small team can still send a first request
A small team does not rule you out by being small. What matters is the shape of the queue and the ability to review. A team of three with a queue, a reviewer and a repository can be a good fit. A team of thirty with no queue may not be.
Be specific about your size in your first email.
Tell us how many people touch the code, who reviews it and how many features are waiting. That gives us what we need to tell you plainly whether the minimum makes sense for you.
Security and review questions are fair to ask
- If your company has a security team or a procurement process, it is right to ask questions before you grant any access. We do not claim certifications on this page, so do not expect us to show you any. Ask us in writing which AI model providers would see your code, who on our team can reach your repository and how access is removed when you stop.
- Do not send production credentials in a request. If a task truly needs one, talk to your account manager first and agree how it will be handled. A fit that depends on handling secrets badly is not a fit for us, and we would rather tell you early.
Example: sorting one Monday backlog into what fits and what does not
This is an example of how a team might sort its own backlog.
The items are invented for illustration. Your list will look different, and your own sort is the one that counts.
Item one:
add a bulk export button to the orders table, using the filters the screen already has. It is clear, it can be tested by clicking, and it lives in a repository you can name. This one fits, and it is the kind of story that clears a queue.
Item two:
decide whether the pricing page should change for large customers. That is a product decision, not a build task. It does not fit yet, because the team has not decided the answer, and a PRD cannot decide it for you.
Item three:
rebuild the reporting engine on a new database. That is a large change with choices your team has not made. Keep it on your own roadmap, and send the small reports and exports that sit on top of it.
Item four:
fix a typo in a help article. It is small, but it is not a feature. It is better fixed by whoever owns the help content, and it does not need a monthly minimum to justify it.
How a product lead can read a PRD in one sitting
- Start with the stories. Read each title as if you were the user, and ask whether a person would say it that way. If a title describes a screen rather than a thing a person can do, ask for it to be rewritten before you approve.
- Then read the criteria for the one story you care about most. Check that each line names something a person can see, and that the wording would still make sense to a stranger on your support team. Anything that only makes sense inside the product team is a gap.
What a small team's prepaid balance looks like week to week
Each completed story uses $5 of the prepaid balance. A story that does not meet its approved criteria is not completed, so it does not use the balance. Treat the criteria as the price list, because they decide what counts.
Keep your own count against the balance, using each approved PRD as the list.
Compare the stories on each PRD with the pull requests that have come back for your review. If the two drift apart, raise it with your account manager before the next request.
What a steady month looks like for a team that fits
Example: a team of four with a repository, a steady backlog and one reviewer. Each approved PRD lists its stories, and each story that meets its criteria uses $5 of the balance. The month's count is the number of stories completed, not the hours anyone spent.
The reviewer's time sets the pace in that example, so the team books a regular slot each week for pull requests.
What the monthly minimum means in a slow month
The minimum is 100 user stories a month, which is $500 paid in full before work begins. Some months the queue will be shorter than that. Plan for that case before you commit, rather than hoping the queue refills on its own.
Our terms leave one question to writing:
what happens to prepaid stories you do not use in a month. Ask it before you pay, and treat the written answer as the one that applies to you. Until you have it, a slow month is a risk you have not measured.
Questions a reviewer will raise, with plain answers
- Your reviewers may resist reviewing work they did not write. That is a fair concern, and it is better raised now than in the middle of a queue.
- The plain answer is that a pull request gets the same review as any other. A person clicks through the feature against the criteria before the pull request is raised, and your reviewer can reject it. Nothing merges without your team's approval.
- The honest cost is reviewer time. Every pull request needs someone to read it, and a steady flow of stories means a steady flow of reviews. Count that time before you commit, because an overloaded reviewer slows the whole queue.
Where small teams usually stall
A small team can stall on two gaps. Nobody has time to read a PRD, or nobody has decided who approves scope. Both gaps are fixable, but each needs a name before the first email goes out.
If the reviewer is also the founder, that can work.
If the founder is also the only person who can answer product questions, expect approvals to take longer. Plan for that now, rather than hoping the answers arrive quickly.
Why a first feature should be small
Pick a first feature you can test by clicking through in a short sitting. A small feature with clear criteria shows you how the PRD reads, how the pull request looks and how your reviewer works, before you commit to a larger queue.
A first request that is too large teaches you less.
It hides the gaps in your review process inside a long list of stories, and those gaps are much easier to see when the list is short.
What a good fit looks like in one sentence
A good fit is a team with a steady stream of small, clear features, a repository we can read, and a person who will review each pull request with care.
If you can say that sentence about your team and mean it, keep reading.
If not, the rest of this page will mostly tell you why not.
A worked example of a team that should wait
Example: a team of two founders building a brand-new product with no settled design. Every week the scope changes, and nobody has time to read a PRD closely. The first step for this team is to settle the product, not to buy a monthly minimum.
The same team could come back later, once the product is steady and one person has agreed to review the work. Waiting is a sensible choice here, not a failure.
How to keep the monthly count honest
Keep a simple log with three columns: the PRD date, the story title and whether its pull request met the criteria. At the end of each month, add up the completed stories and compare the total with the balance you prepaid.
The log is for your own check.
It does not replace the written terms, and it cannot settle a dispute on its own.
What to do if the reviewer says no
A rejected pull request is not a wasted month. Ask the reviewer to write down the reason in the pull request, then decide whether the criteria were unclear or the work missed them.
If the criteria were unclear, improve them for the next PRD.
If the work missed them, say so plainly. Either answer is useful, and both belong in the record.
Start with the feature that fits your team
- If you nodded at one or two of the points above, you may already have your first feature in mind. Choose the one you keep postponing, the one that would clear the most in your queue, or the one that is small enough to test quickly.
- Write to us with that feature, your stack and the names of the people who will approve and review. Use the button on this page to start. We will send a PRD the same business day, and a pull request will arrive in your repository within three business days of your approval.
- If you are not sure, write anyway. Describe your queue and your team in a few lines. A short, honest email is the fastest way for both of us to find out whether this is the right fit.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1Is 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.
2Will this work on our old codebase?
Yes. PHP, Node, Python, Java, .NET and Go are all in scope, along with React, Flutter and SQL or NoSQL databases. Agents read your repo first and follow the patterns they find.
3What 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.