Getting started
Start with the feature you keep postponing.
There is no signup form and no sales deck. You send one email with what you want built. We take it from there.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Send one email.
- 2
See the PRD and cost.
- 3
Prepay, then approve.
- 4
Review the pull request.
What happens, in order.
No onboarding ramp and no recruiter fees.
- 1
You email us the request
Write it in plain English. Tell us your stack and where the code lives.
- 2
We agree access and the prepayment
A named account manager sets up access to your repo with you. You prepay at least 100 stories, $500, before work begins.
- 3
You read the PRD
It lists the stories, edge cases, acceptance criteria and cost. Change anything. Nothing is built until you approve.
- 4
A pull request lands in your repo
Within three business days of your approval, with its tests. Your engineers review it as usual.
- 5
You send the next one
Your account manager tracks every request through to the merge. The small asks can finally go in too.
Four things make the first request smooth.
None of them take long.
- The feature you keep postponing.
- Where the code lives.
- Who will approve PRDs.
- Who will review pull requests.
From a postponed feature to a pull request, with one decision in your hands
- Most features that wait in a backlog are not waiting for code. They are waiting for someone to write the plan, find the time to build it and check the result. Each of those steps is a small job, and each one tends to fall on a busy person.
- Here, the plan arrives the same business day you ask for it. The building and the testing happen on our side, and a pull request lands in your repository within three business days of your approval. The one decision that stays with you is the approval itself. Nothing starts until you say yes.
- That is the change you are buying into. The feature you have been carrying for a quarter stops being a line in a planning document and becomes a set of user stories, each with a price and a pull request. Your team still reviews it, but they review finished work instead of planning a feature from scratch.
- You do not need to be ready to start. You need one feature in mind, your stack and the name of the person who will approve and review. Everything else is set up with you once you write in.
One email starts the whole thing
There is no signup form on this site, and there is no sales deck to read first.
You send one email describing what you want built. That is the whole front door.
Keep the email short.
Describe the feature the way you would tell a colleague. Name your stack, say where the code lives and tell us who will approve the plan and who will review the pull request. Three or four lines is enough. If you have more than one feature, start with the one you keep postponing.
A short email is also a fair test of us.
If we reply with questions that show we read what you wrote, you have a sign of how we will handle the work. If we reply with a sales pitch that ignores your stack, you have a sign of that too.
Use the button on this page to start the email.
It opens a message with a subject line already set, so the request is easy to find later.
What you get at each step of the first week
The first week has a clear order.
Knowing that order in advance removes most of the surprises. Each step below has a clear next move, either for you or for us.
The first step is your email.
You describe the feature and the stack. We reply and ask only what we need to read your repository well.
Access, prepayment and the first PRD are agreed with your account manager.
Ask us when the prepayment is due, and get the answer in writing. A named account manager sets up access to your repository with you. You prepay at least 100 stories, which is $500, in full before any work begins. We do not start building on a promise that the money will follow.
Then you read the PRD.
You read the stories, the edge cases, the acceptance criteria and the cost. You can change anything in it. Nothing is built until you approve.
The fourth step is the pull request.
Within three business days of your approval, it lands in your repository with its tests. Your engineers review it the way they review any other change, and they decide what merges.
The fifth step is the next request.
Your account manager tracks every request through to the merge. The small asks that never made the sprint can now go in too.
The people and papers you need, in order
Before the first email, have these items ready.
None of them takes long to find, but each one unlocks a step. A missing item can slow the first week.
Gather them in the same order the steps happen, so the items reach us in the order we need them.
The feature you keep postponing, in a sentence or two.
Where the code lives, meaning the repository or repositories the work would touch.
Your stack, including languages, frameworks and how old the code is.
Old is fine.
The name of the person who will approve the PRD.
The name of the person who will review pull requests.
A way to pay the prepaid minimum, $500 for 100 stories, before work begins.
What happens to your code during setup
- Setup is the part people ask about most, and it deserves a plain answer. Agents need to read your code before they can follow its patterns. That means access to the repository in scope. We do not ask for more than the work needs, and we agree the terms with you in writing.
- Give access only to the repositories the work touches. Keep production credentials out of the request. If a task truly needs one, talk to your account manager first and agree how it will be handled.
- Ask us which AI model providers would see your code. We will tell you what we can in writing. Do not rely on a verbal answer for something this important, and ask for the answer before you grant access.
- Once access is set, the work lands as pull requests in your repository. Nothing reaches production by itself. Deployment stays with your team unless you choose to hand it to us.
A first request that tells you what to expect
The first request is a learning exercise for both sides.
You learn how we read your code and how we write a plan. We learn how your team reviews work and what it considers done. A good first request makes both of those clear before much money is at stake.
The PRD is where that learning shows.
It lists each user story, the edge cases it covers, the acceptance criteria that define done, and the cost in stories. A reader can check each part. If the PRD misses an edge case your team would have caught, that is useful to know before any code is written.
Read the PRD the way your most careful reviewer would.
Look for missing states, such as empty, error or loading screens. Look for stories that are too big to test in one go. Look for criteria that a person cannot check by clicking. Each gap you find is a fix you can ask for before approval.
Your first pull request then shows what the approved plan turned into.
Check the tests, read the diff and see whether it reuses the helpers and patterns already in your code. If it does, the process is working on your repository. If it does not, tell us, in writing, and we will treat it as the first thing to fix.
Starting this week, against hiring next quarter
- A hire takes time before it helps. Three months to find a person is a common shape, followed by six weeks to ramp them up, and then notice periods on top. A feature that waits for that person waits all of that time.
- Starting here is different. The first email can go out this week. The PRD follows the same business day. After your approval, the pull request lands within three business days. No recruiter fees, no onboarding ramp and no bench time sit between your request and the work.
- A hire still has a place. If you need a person who makes product calls every day or runs on-call for your systems, you need one. Starting here does not replace that. It clears the queue while you find that person, and it keeps your team's time for the work only they can do.
- The practical question is simple. Would you rather wait a quarter for a feature that a hire would eventually build, or send the first user story this week and see a PRD the same business day? That choice is yours, and either answer can be right for your team.
What if we change our mind after reading the PRD?
Change it. The PRD is a draft until you approve it. Ask for a story to be split, a state to be added or an edge case to be covered. Nothing is built until you say yes, so a change at this point costs you a message and no build time.
The approval is the moment the scope becomes the agreed plan.
Read the whole PRD before you approve it, and ask about anything that is unclear. If a question stays open, the answer is to keep the PRD in draft until it is closed.
What if we want to stop after the first request?
This is a fair question, and it depends on the terms you agree before you prepay. The minimum is 100 stories a month. The terms for cancelling and for stories you do not use are settled in writing before you pay.
So ask before you pay.
Put the question in your first email in plain words, and ask for the answer in writing. A written answer is what applies to you, and it is better to know the terms before money moves than to argue about them afterwards.
What if we need help during the first week?
You get a named account manager. That is a real person, not a ticket queue. They track each request through to the merge, and they are the first point of contact when something is unclear about access, the PRD or the review.
Founders are one email away too.
If your question is about the terms, the business side or anything the account manager cannot settle, write to a founder directly. Both paths are open from the first week.
What if our repository is hard to share or split up?
- Tell us in the first email. A repository that is split across several services, or one that is hard to give access to, changes how the first week runs. It does not make the work impossible, but it does need a plan before the PRD is written.
- Name each repository the work might touch. If some of them should stay out of scope, say so. Agreeing the scope early is cheaper than discovering a dependency halfway through a build.
What if a story fails review after the pull request lands?
Your engineers decide what merges. A pull request that does not pass your review has not earned the merge, and it is right that your team has the final say. That holds from the first request onward.
How rework is handled and whether it affects the story count is a detail to settle in writing before you prepay. Ask it in your first email. We would rather answer it now than leave it to be argued over once the code is in review.
A worked example of the first week, from one email to one merge
- This is an example of how one small request moves through the first week. The feature is a team invite page that shows a blank panel when nobody has been invited yet. It is a sample only. Your own PRD will look different.
- First, you send the email. It says the invite page shows a blank panel, names the Node and React stack, points to the repository where the page lives and names the person who will approve the PRD. That is the whole request. No ticket, mockup or spec is needed.
- The PRD arrives the same business day. In this example it lists one user story, the empty state and its copy. The criteria say the panel explains what an invite does, offers one clear button, and reads well on a phone. The count line shows one story, $5. You read the criteria, change any wording you dislike and approve.
- Within three business days of your approval, a pull request lands in the repository. Your engineer reads it, checks that the new panel reuses the button component already in the code, and then merges it or asks for changes. A pull request that fails review has not earned the merge.
- The balance moves by $5 for this example. One completed story uses $5 of the prepaid balance, and it counts as completed only once its pull request meets the criteria you approved.
What to check in the PRD before you approve it
Approval makes the scope the agreed plan, so it deserves a slow read.
Check four things before you click approve. They are easy to skip when a document looks tidy.
First, count the stories and multiply by $5.
The total should match what you expected to spend on this feature. If the count is far above your guess, ask why before approval, not after the first pull request.
Second, look at what each story touches.
A story that changes login, permissions, payments or exports carries more risk than a copy change. For those, check that the criteria say what happens when a user is not allowed to take the action.
Third, make sure every criterion can be seen.
A person should be able to confirm it by clicking through the feature or reading the output. Words such as fast, clean or intuitive are not criteria. They are opinions, and opinions cannot be checked.
Fourth, check what is missing.
A PRD that covers only the happy path will ship a feature that breaks on the first odd input. Ask for the empty states, the failure states and the case where two people change the same record at once.
How the prepaid balance applies to your first request
- The balance is the simplest part of the first week, so check it early. 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.
- A story that misses its approved criteria has not been completed, so it does not use the balance. That is why the criteria deserve more of your time than the story titles do. Change any criterion you doubt before you approve.
- Example: a request with four stories uses $20 of the balance once all four are completed. If only three meet their criteria, the example uses $15. What happens to the unused $5 is a question to settle in writing before you pay.
How a person checks the feature before your reviewers see it
Your engineers review the code. Before the pull request is raised, a person on our team clicks through the feature against the criteria you approved. That check looks at what a user would see, which is a different job from reading the diff.
You can make that check more useful.
Ask for criteria that a person can see on a screen or in a file, and name the states you care about most. When the pull request arrives, click through those same states before your engineers do.
A manual check does not replace your own testing.
It can spot a confusing message or a broken step that no automated test was written to find. Your team still has the last word on the merge.
Three routes to a first feature, and what each asks of you in week one
Most teams already have a route for a first feature.
It helps to compare what each route asks of you in the first week, not only what it costs.
Hiring asks you to write a job brief, run interviews and plan a start date before the feature can begin. The first week goes on the hiring process, and the feature waits for the person to arrive.
An agency asks you to choose a partner, agree a contract and explain your codebase to a team that has not seen it. The first week goes on the contract and the handover, and the answers about access live in that contract.
A coding tool asks one of your engineers to drive it.
The first week goes on setup and on learning the tool's habits. The engineer still writes the plan, checks the output and owns the result.
Our route asks for an email, a repository, a stack and an approver.
The first week goes on reading a PRD and reviewing a pull request. It does not remove the need for your review, and it does not suit every team, so compare it honestly with the other two.
Questions to put in writing before you pay
Some answers matter more than any feature detail.
Put them in writing before money moves, and do not treat a verbal answer as settled.
Ask these in your first email, or in a follow-up, and ask for each answer in writing.
A written answer is the one that applies to you. If an answer is not in writing, treat the question as still open when you decide.
What happens to prepaid stories you do not use in a month.
How rework is counted when a pull request needs changes.
Which AI model providers may process the repositories in scope.
Who on your side can end our access, and how that is done.
What happens if you want to stop after the first request.
Honest limits of the first week
The first week does not guarantee a result. We can read your repository, write a PRD and raise a pull request. We cannot promise the pull request will pass your review first time, because your reviewers decide that, and they may ask for changes.
Some requests stall in the first week.
The usual reasons are a repository nobody can grant access to, a feature that waits on a product decision nobody has made, or a reviewer who is away when the pull request lands. Each one is a reason to pause and settle it first.
A first request is also a poor place to test a large rewrite.
If the feature needs a new framework, a new database or a change to how your system is deployed, say so in the email. Those choices belong to your team, and the first PRD should not be where they get made by surprise.
Who should wait before the first email
If you are not sure what you want built, wait. A first email that says the product needs to grow is not a request. A PRD can list stories, but it cannot choose your product direction for you.
If nobody on your side can read a pull request, pause here too.
Your team makes the final call on every merge, and a pull request with no reader has nowhere to go.
If your work is a few small changes a year, a monthly minimum of 100 stories will not match it. A single small job is better handled another way, and we would rather you hear that from us before you prepay.
A plain answer to the worry that a first email is too vague
A vague first email is normal. Most people write the first one in a hurry, with one feature in mind and no structure. You do not need to polish the wording before you send it.
What matters is that the email names the feature, the stack, the place the code lives and the approver. Those four things give the PRD something to work from. If a detail is missing, you can add it in a reply before you approve.
Keep a short record of your first request
- Write down five things as the request moves: the approval date, the story count, the pull request link, the reviewer's decision and any open question. The record is short, and it tells you more about the process than any summary can.
- Bring that record to your second request. If the same question keeps coming up, you have found a gap in your own process, and that is worth fixing before you send the next email.
Where a first request can go wrong, and how to spot it early
A first request can go wrong in three places.
The email was too broad, the criteria were too vague, or the reviewer had no time. Each one shows up early if you look for it.
Too broad:
the email asks for a whole area of the product, such as billing. Ask for one feature instead. A billing area is many stories, and each story needs its own criteria.
Too vague:
the criteria say things like works well or looks clean. Replace each one with a line a person can check on a screen. If you cannot picture the check, the criterion is not ready to approve.
No reviewer:
a pull request nobody reads sits in the queue. Name the person who will read it before you send the first email, and tell them roughly how many pull requests to expect in a month.
A short checklist for the day before you send the email
Before you send, check these four things.
Each one takes a minute, and each one saves a round of questions later.
The repository is named, and someone on your side can grant access to it.
The stack is named, for example Node and React.
The feature fits in one short sitting, so you can test it by clicking.
One person is named to approve the PRD, and one person is named to review the pull request.
How a second request differs from the first
The first request tests the process. The second one tests whether you trust it. By then you have seen one PRD, one set of criteria and one pull request, so you know what to expect.
Use the record from your first request to plan the second.
Pick a feature of similar size, and keep the same reviewer if they were happy with the first.
Send the email this week
If you have one feature you keep postponing, you already have a first request. Write it down in a few lines, with your stack and the name of your approver. That is enough to start.
Use the button on this page to send it.
The PRD follows the same business day. After your approval, a pull request lands in your repository within three business days, and your team decides what merges.
If you are not ready yet, ask your questions first.
Put the terms, the access and the review process in writing, and come back when you are ready to commit. A clear start is worth more than a fast one.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1How 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.
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.
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.