FAQ
Questions, answered plainly.
The things people ask before they send a first request. If yours is missing, write to a founder.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Price and minimums.
- 2
Speed and scope.
- 3
Code ownership.
- 4
Whether it fits you.
Get clear answers before you send a single word
- Most people who read an FAQ are looking for one thing. They want to know whether it is safe to take the next step. A question they could not get answered is the one that stops them, so the answers matter more than the layout.
- This page goes past the basic questions. It covers the doubts that come after the first read: what happens if the plan changes, what happens to your code, what happens if the work disappoints, and what happens if you simply want to stop. Those are the questions a careful buyer asks before signing anything.
- By the end, you should know where each answer lives, who gives it to you and in what form. That is more useful than a long list of reassurances. A reassurance is cheap. A written answer you can file and show your own team is worth something.
- If a question is missing from this page, that does not mean we are hiding it. It means we have not written it down yet. Ask it. We will answer it in writing, and we may add it here if it is one many people ask.
Answers you can check, not answers you have to trust
We answer in specifics.
A specific answer names a number, a document or a step. A vague answer says that things will be fine. We would rather give you the specific one, even when it is less comfortable to read.
Where we cannot give a clean answer yet, we say so.
Some terms are settled in writing for each arrangement, so a general answer on this page would be a guess. In those cases we point you to the written terms and to the person who will confirm them.
We also keep the answers short.
A long FAQ can hide the one thing that matters. Each answer here tries to do one job: say what is true, say where it is written down and say what you should ask next.
Read each answer against your own situation.
A stack, a team size or a queue that is unlike the examples here may change the answer. When in doubt, bring the question to your first email rather than assuming.
Where each kind of answer lives
Different questions have different homes.
Knowing the home saves you time. Some answers are on this site, some are in the PRD for your request, and some are in the written terms you agree before you prepay.
Use this as a guide.
If you are not sure where a question belongs, start with your account manager. They can point you to the right place, and they track the question as part of your request.
The PRD for a request:
the stories, edge cases, acceptance criteria and story count. You see this before you approve anything.
The terms of service:
your approval, timing, your duties and how your code is treated.
The refunds and billing page:
prepayment, how stories are used from your balance, and how unused stories are settled in writing.
The data processing page:
personal data in your repository, and how to ask for an agreement.
The privacy policy:
what this website and your emails collect, and how to ask what we hold about you.
Your account manager:
day-to-day questions about access, the PRD and your pull requests.
Why we put answers in writing
A verbal answer is easy to forget and hard to prove.
A written answer can be filed, checked by your procurement team and shared with your engineers. It also protects both sides, because the question and the reply stay on the record.
This is the reason the legal pages and the PRD carry so much weight on this site.
They are the places where a promise becomes something you can hold us to. A line on a sales call does not do that job.
It also matters for the questions that are hard to answer at all.
Which model providers see your code, how access is removed, and what happens to stories you do not use are all things we would rather settle in writing than guess at on a call.
If you want a written answer to a question, ask for one.
Asking is not a sign of difficulty. It is the normal way a careful team works with a supplier.
How the questions differ from those you would ask a hire or a seat
The questions you ask about a hire are about time, notice and fit. The questions you ask about a coding tool are about the people who will drive it. The questions you ask about this service are about the plan, the review and the record of what was agreed.
For a hire, you ask how long it takes to find the person and what happens if they leave.
For coding seats, you ask who will steer the tool and whether your engineers have the spare hours. For us, you ask who approves the plan, who reviews the result and what the written terms say about the money.
Some questions are the same for all three.
Who reviews the work, who owns the code, and what happens when the arrangement ends. Those are fair to ask of any supplier, including us, and we will answer them in writing.
What if the plan grows after I have read it?
You can change the plan before you approve it. Ask for a story to be split, a state added or an edge case covered. The story count moves with the scope, and you see the new count before anything is built.
The risk that matters is the change after approval.
Once you approve a PRD, it is the agreed scope. A change to that scope should be raised in writing and agreed before work moves on. Ask us how that works before you approve your first plan, so the rule is clear to both sides.
What happens to our code if the arrangement ends?
- Your code stays in your repository, and the work arrives as ordinary pull requests. There is nothing to export if you stop. Ask us what happens to copies of your code during the work. The history of each change is in your own version control, reviewed by your own team.
- That is why we describe the arrangement as having no lock-in. The question still deserves a careful read of the written terms. Check how access is removed when the work stops, and ask us to confirm it in writing before you grant access.
Will our data leave our control?
Your data is the first thing to protect, and we treat it that way. Keep real customer data out of the repositories in scope. Use made-up test data where you can. Do not send production credentials or database dumps in a request.
If your repository holds personal data, for example in fixtures, seed files or logs, ask for a data processing agreement before work begins. Send your own template if you have one. Ask which service providers, including AI model providers, would handle your data, and ask for that list in writing.
We cannot make promises about certifications on this page, and we do not claim any.
If your procurement process needs a particular document, ask for it in your first email. We will tell you what we can provide, and what we cannot yet.
What if a pull request is wrong in a way the tests miss?
- Tests catch a lot, but not everything. That is why manual QA by a person sits between the tests and your team. A person checks the feature against the acceptance criteria you approved, and notices things a test was never written to notice.
- Your team is still the final check. Your engineers read the diff, decide whether it fits, and decide what merges. A problem found in review is a normal part of the process, and it does not reach your product unless your team lets it.
- If a problem gets past everyone, you have a clear route. Write to your account manager with the story, the pull request and what went wrong. Ask for the fix and the cause to be written down together, so the same gap does not appear twice.
What if no one on our side is technical?
A non-technical product lead can approve the PRD. The stories, edge cases and acceptance criteria are written in plain language so a person can check them without reading code. That is the part of the work most product people already know how to judge.
A pull request still needs someone who can review code.
Without that role on your side, your team cannot decide what merges, and no outside team can make that call for you. If the reviewer role is empty, fill it before you start.
Some teams split the work this way.
The product lead approves the plan and tracks the queue. A senior engineer reviews the pull requests. That arrangement fits our model well, because each role does the part it is suited to.
Can we pause the work for a while?
A pause is a fair thing to ask for, and it depends on the terms in your agreement. Ask us in writing before you prepay, and describe the pause you have in mind, including its length and what it means for your balance.
Please do not assume a pause is free or automatic.
Settle it in writing. Then both sides know what happens to the queue, to the balance and to any stories already in progress.
What if our contact is slow to reply?
You have two routes. Your named account manager is the first, and founders are the second. Each one is reached by email on this site, and a person answers the email. Use the account manager for day-to-day questions and a founder for anything about the terms or the business side.
We do not promise a reply time on this page, because we would have to guess at it.
If a question matters to a decision, say so in the subject line. That helps us answer it sooner, and it helps you judge how responsive we are from the start.
A worked example: one story from request to balance
- This example follows one story from start to finish. The numbers and the wording are invented for the example. The steps are the ones this site describes.
- A team asks for an empty state on its team invites page. The PRD lists one story: when nobody has been invited yet, the page shows a short message and a button that opens the invite form. The acceptance criteria name the wording, the button's destination and what a person sees on a phone.
- A pull request arrives with a test for the empty state. A person opens the page on a phone and on a laptop, clicks the button and checks the wording against the list you approved.
- Once the pull request meets the criteria you approved, the story counts as completed and draws $5 from the balance. The next story on the PRD follows the same path.
- The point of the example is the trail. Each step leaves a record: the PRD, your approval, the pull request, the review and the balance. You can check each record against the one before it, which is harder to do with a promise.
Does a story that fails its criteria still cost $5?
Under the terms on this site, no.
The balance moves only for stories that are completed, and a story counts as completed when its pull request meets the criteria you approved. A story that falls short does not move the balance.
That only works if the criteria are clear.
Vague criteria turn the question of met or not met into a matter of opinion. This is why the PRD is written in plain language, and why each criterion should be something a person can check by clicking.
If you think a completed story has missed a criterion, say so in writing.
Name the story and link the pull request. Then ask how the question is settled before you rely on the outcome. This site does not spell out a dispute process in full, so ask for it in writing rather than assume one exists.
Ask us how an uncovered case is counted, and get the answer in writing before you approve.
Edge cases can be their own story, and each one carries its own count and its own criteria, so the cost stays visible.
What if our coding conventions are not written down?
Many teams keep their conventions in habit rather than in a document.
Agents learn from the code they can read, so the patterns they copy are the ones that show up in your repository.
That helps when your code is consistent.
It is a weaker guide when the same job is done three different ways across the repo. Then the new code may follow one of the three, and your reviewer may prefer another.
The honest fix is to name the convention.
One sentence in the first email, such as which helper your team uses for dates, can help avoid a round of review. If you cannot name it, ask us to show you which pattern the PRD says will be followed, and read that before you approve.
A good PRD states the chosen pattern in plain words.
If yours does not, that is a reason to ask before approval, not after the pull request lands. Good questions are cheap at that stage, and expensive later.
What does a manual check look like in practice?
- Manual QA means a person uses the feature the way a real user would. Here is an example for the CSV export story. It is an example, not a record of a check we have run for a customer.
- The checker sets three filters, exports the report and opens the file to compare its rows with the screen. They then export a report large enough to be slow, and watch whether the download finishes. Last, they cut the connection part way through and read the message that appears.
- Each step is checked against the acceptance criteria you approved. If the message makes no sense, the checker notes it. If a row is missing, the story is not complete, whatever the automated tests report.
- Automated tests and a person look at the same story from different angles. The example shows why both stay in the process, and why neither one is enough alone.
- Before you pay, ask us what a manual check record looks like and whether you would receive one. Get the answer in writing too.
How does the minimum look when fewer stories complete?
Here is an example for a team with a full queue.
The numbers are made up, and they show the arithmetic only, not what your team will do.
Say the team's PRDs add up to 100 stories, and 75 of them are completed.
Those 75 draw $375 from the prepaid $500, at $5 each. The other 25 draw nothing, because they have not met their criteria.
In a quieter month, with 12 stories completed, the same arithmetic gives $60 drawn.
Read the written terms on unused stories before you decide whether a pattern like that suits your team.
Do not judge the price first.
A team with a steady queue of small asks may find the monthly count easy to reach. A team with a bursty queue may not, and that is worth knowing before you prepay.
Do we have to hand over production access?
- Do not send production credentials unless we have agreed how they will be handled. If a task truly needs one, talk to your account manager before anything is shared, and agree how it will be handled.
- Many small features can be built and tested without live data. A new export or a validation message can be checked against made-up records that look like yours, so the tests have something realistic to run against.
- If your team already keeps a safe test environment, say so in your first email. Tell us where it is, and name the person on your side who can confirm what is safe to use.
- If a task would need a credential your team cannot share, say that too. We would rather you tell us early that a task is blocked than find out during the build.
Who should not start with us yet?
A short list, so you can rule yourself out quickly.
Saying no early is useful for both sides, and it keeps your time and ours for a better fit.
Teams that want to try one story before a commitment should wait.
The minimum is 100 user stories a month, so a single story is not something we sell on this site.
Teams that expect to change direction in the middle of a PRD should settle that first.
Changes are handled in writing, and a shifting direction makes every story harder to check.
Teams that need a person in the room every day, or that want us to take over product decisions, are better served by hiring or by a product lead of their own. We take requests and ship them. We do not run your product.
Finally, a team that cannot share its code, even under a written agreement, should wait until that is sorted. Start with the question of access, and come back once it has an answer.
What does three business days mean in practice?
We aim to raise the pull request within three business days of your approval.
It is counted in business days, not calendar days, so a weekend does not use up the time.
Public holidays are not covered on this site.
If your team or ours is closed on a particular day, the count may be affected, so ask us how holidays are counted in writing before you rely on a date.
The three days begin at your approval, not at your first email.
Time spent before approval is outside that count.
If a pull request is late against that window, say so in writing and ask what happened.
A written question leaves a record for both sides to act on.
Can we settle our own terms instead of the standard ones?
The terms page says a signed agreement or written order wins if it differs from the website. So if your procurement team needs its own wording, put it in writing and ask us to confirm which version applies.
Send your own template if you have one, for a data processing agreement or for the order itself. Ask for each change in writing, and keep the replies with the PRD, so the paper trail stays in one place.
Do not assume a change is agreed because someone said yes on a call.
A verbal yes is easy to forget. The written answer is the one that applies, as the refunds page also says.
How to tell a request is too big
- A request is too big when a person cannot check its acceptance criteria in one sitting. If a reviewer would need a day to click through every criterion, the story is probably two stories.
- Watch for words like 'and' in a story title. A title that joins two actions usually hides two stories, each with its own criteria. Splitting it early keeps each pull request small enough to read.
- Size also affects the count. Every story is $5 once it is completed, so a split is a count you can see on the PRD before you approve. Ask for the split in writing if the PRD does not show it.
Still unsure? Ask one question in writing
If you have read this far and one question still stands in the way, ask it. Keep it short and specific. A question about one story, one term or one step is easier to answer well than a question about everything at once.
When you are ready to start, use the button on this page to send your first user story.
Include your stack, the feature and the name of the person who will approve the plan. 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.
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 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.
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.
4How 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.
5Will 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.
6Who owns the code?
You do. Work arrives as a pull request on your own infrastructure. Your repository, your stack, your review process. To do the work, our agents and team read your repository under the access you agree, and AI model providers may process it. See the security page for details.
7Is 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.
8What 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.