Contact
Write to us. A person answers.
No form and no sales funnel. Send the feature you keep postponing, or ask whatever you need to know first.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Email to start.
- 2
A PRD the same business day.
- 3
Founders read these.
- 4
Ask anything first.
The people you will hear from
Sudhir Goenka
Co-founder & CFO
Sushant Pingale
Chief Product Officer
A good first email is short.
Three lines is plenty.
- 1
What you want built
Write it the way you would tell a colleague. If you have more than one, start with the one you keep postponing.
- 2
Your stack
Languages and frameworks, and how old the code is. Old is fine.
- 3
Who reviews
Who on your side can approve a PRD and review a pull request.
The feature you keep postponing gets a real start
- You already know which feature it is. It has been on the roadmap for a quarter, and every planning meeting pushed it to the next one. It is not urgent enough to fight for, and it is too real to drop.
- Sending one email changes that. You describe the feature in plain English. We aim to open a written PRD the same business day, so you see the scope, the stories and the cost before any building starts. Nothing is built until you approve it.
- Think about what that does to the meeting that never ends. Instead of another round of debate about whether the feature fits, you have a document to read, a count to check and a yes or no to give. The decision gets smaller, and it gets easier to make.
- This page is for the moment before you send that email. It explains what to write, what a reply looks like, what a person on our side will ask you, and what to think about before you commit. You can decide from here whether to write to us, and you can ask anything first.
A person reads your email and answers it
There is no form to fill in and no sales funnel to get through.
You write to us the way you would write to a colleague. The email goes to people who read these messages, and a person answers it.
The button on this page opens your mail app with a subject line already filled in:
My first AgentCTO user story. You can change the subject. Nothing is sent until you press send.
The reply is where the work starts.
We ask what you want built, what stack the code uses, how old the code is and who on your side approves PRDs and reviews pull requests. Those four answers are enough for us to say whether the work fits and what the next step looks like.
Founders read these emails, so your question does not stop at a support queue.
If your question is not about a feature at all, ask it anyway.
You can ask about access, about ownership, about how a PRD is structured or about the prepayment. A plain answer in writing is worth more than a quick call that leaves no record.
Email to start, with no form to fill in.
A written PRD, aimed for the same business day.
A person answers, and founders read these messages.
You can ask anything before you commit.
What to put in your first email
A good first email is short.
Three things are enough. The rest can come up in the reply, once we know what you need.
Start with what you want built.
Write the feature the way you would tell a colleague, in plain language. If you have more than one request, start with the one you keep postponing. A single clear sentence beats a long brief that tries to cover everything.
Next, describe your stack and how old the code is.
Name the languages and frameworks, and say whether the code is new or legacy. Old code is fine. Tell us where the code lives, so we can plan access with you. You do not need to share anything secret in this email.
Last, say who reviews the work.
Tell us who on your side can approve a PRD and who reviews pull requests. In many teams the same person does both. If nobody is available to review, say so now, because a pull request needs a reviewer to be useful.
You do not need a formal spec, a ticket or a template.
If you already have a rough document, attach it or describe where it lives. If you do not, the PRD we write from your email is the document that matters, and you will approve it before anything is built.
What you want built, in plain language.
Your stack, and whether the code is new or legacy.
Where the code lives, so we can plan access with you.
Who approves PRDs and who reviews pull requests.
Talk to a person who will know your request
Once you start, you get a named account manager.
That is a real person who tracks every request through to the merge, at zero extra cost. You do not have to explain the same feature twice, because the account manager keeps the history of your requests in one place.
The account manager is the person who sets up access to your repository with you, checks the PRD with you, and follows the work until the pull request is in your repo. If a request stalls, that is the person who notices and tells you why.
We also keep the founding cohort small on purpose.
Onboarding is capped at a small number of accounts each month, so each account gets real care. That is why we ask you the questions before we start, not after.
If you want to talk to someone at a different level, ask in your first email.
Founders are one email away, and they read these messages. Ask for what you need, and we will tell you who is best placed to answer it.
Writing to a person beats the usual routes to start
There are three common ways to start.
Each one asks something different of you at the start. Here is how writing to us stacks up, so you can choose the route that suits your team.
Hiring starts with a job description, a shortlist and a set of interviews.
It can take months before a person is in the seat. Writing to us starts with one email and a written plan, and the first pull request follows the approval of that plan.
Agencies usually start with a discovery call, a proposal and a contract.
The steps are sensible, but they take time, and the proposal often describes the work before anyone has read your code. Writing to us starts with your request, and the PRD is built from it.
Coding tools start with a trial or a seat purchase.
That is quick, and it puts the work on your team from the first hour. Writing to us asks less of your team in the first week, because the PRD and the account manager carry the planning.
Use the route that fits your team.
If you need people in the room, hire. If you have engineers with spare hours, a coding tool may suit you. If you want a person to take a feature from request to pull request, write to us first, and ask the questions before you prepay.
Hiring:
months to fill a seat, then a ramp.
Agencies:
discovery calls and a proposal before the work is clear.
Coding tools:
fast to start, but your team runs the process.
AgentCTO:
one email, a written PRD, and a named person on the account.
Honest answers to the doubts you may have
Writing to a company you have not met can feel uncomfortable. These are the doubts we hear most often, with the honest answer for each.
Will I be pushed into a sale before I know enough?
Your first email is for questions as much as for requests. We answer what you ask, and we tell you when a question needs a written answer before you commit.
Do I have to commit before I ask anything?
No. You can write to us, ask your questions and read the answers before you prepay. Nothing is built until you approve a PRD, and you prepay before work begins, so there is a clear point at which you decide.
What if my request is too small?
Our minimum is 100 user stories a month, which is $500, prepaid in full before work begins. If you have a few changes a year, that is the wrong shape for us, and we will say so. It is better to know that in the first email than after a payment.
What if I do not have a repository yet?
You need a repository we can raise pull requests on. If your code is still on a laptop, or in a place we cannot reach, tell us what you have and where it lives. We will say plainly whether we can work with it as it stands.
What if I am not sure who should review the work?
Say so. Many teams are unsure at first. Tell us who you think should review, and we will help you check that the reviewer can approve a PRD and read a pull request before the first build.
How quickly will someone reply?
A person answers. We do not promise a fixed reply time on this page, because the right reply depends on what you ask. What we do aim for is a clear answer, in writing, that you can act on.
What if you want to know about money back?
Ask us in writing before you pay. The refunds and billing page says how unused stories are settled, and the written answer is the one that applies to you.
A worked example: a first email from a team with an old Laravel app
This is an example, not a customer story.
It shows how one first email could travel through the process, so you can picture your own.
Example email:
'We run a Laravel app that is about six years old. We want CSV export on the reports page, with the current filters kept. Our lead engineer reviews every pull request, and our product manager can approve the PRD.' That is enough to start. It names the stack, the feature, the age of the code and the people on each side of the gate.
We aim to open the PRD the same business day.
For this request it might list four stories: export the current report, keep the filters in the export, handle large reports, and show a clear error on failure. Four stories at $5 each comes to $20 if all four are completed, so you see the cost before you decide anything.
Your reply to the PRD is the place to mark what your reviewer will care about.
A short note, such as 'the error must name the file that failed', is the kind of line a reader can turn into an acceptance criterion. You can say it in plain words. You do not need the formal language of a ticket.
After you approve the PRD, we aim to raise the pull request within three business days.
Your lead engineer reviews it the way they review any other change. Nothing in that path asks your team to learn a new tool, and the review stays where it already happens.
The example works because it is specific.
A reader on our side can ask the right questions from one email, and your reviewer can check the result against words you wrote yourself. That is the whole point of a first request.
A worked example: a team with a queue of small asks
Here is a second example.
A team has a queue of small asks that never reached a sprint: an empty state on the team invites page, a clearer validation message on the signup form, and a warning before an admin deletes a saved filter.
Each of these can become its own user story.
The invite fix might be one story, which is $5. The validation message might be one story. The warning might be two, one for the wording and one for the case where the filter is shared. That makes four stories, or $20, in one PRD.
Here the prepaid balance does the work.
Each story that completes draws $5 from the balance you prepaid. A small story follows the same path as a large one. It gets acceptance criteria, tests in its pull request and a person's check before your team sees it.
The team's first email would list the three asks, the stack and the reviewer.
The PRD would then show how the asks split into stories. If one ask matters more, say which. The PRD can list it first, so you see it at the top before you approve.
The size of an ask changes its story count.
It does not change the standard. That is the part worth noticing: a short queue of small asks can be as well tested as one large feature, and the PRD shows you the stories before anything is built.
Keep the list of small asks in your first email, even the ones you think are too minor to mention.
What to check before you send the email
Before you write, check four things on your side. None of them needs a meeting, and none of them needs a document.
First, is the request one feature or a bundle?
A bundle can still work, but the PRD reads more easily when each feature has its own list of stories. If it is a bundle, name the parts so we can split them cleanly.
Second, can someone on your side give us access to that repository?
Access is part of the work. A request can stall at access, however clear the feature is.
Third, will a reviewer be free to read the pull requests once they arrive?
A pull request without a reviewer is a pull request that waits. Name the person who will do it, and say how much time they can give.
Fourth, who signs off a $500 prepayment on your side, and how long does that take?
Find that out early. The minimum is 100 user stories a month, $500, paid in full before work begins. Knowing the sign-off route now keeps the request moving.
Who should wait before they write
Some teams will get more from waiting.
We would rather say so now than after a payment is made.
If nobody on your side has agreed who can approve scope, wait.
A PRD that no one is allowed to approve only sits there, and that wastes time on both sides.
If your product direction is still open, wait too.
We work from your code and your requests. We cannot settle what your product should become, and a PRD written against an open question will carry that question into every story.
If you need a certificate or a signed agreement before any code is shared, ask about that first, and hold back the repository until the answer is in writing. This site does not claim any certifications, and we will not promise one in a first email.
If you want a person beside your team every day, a first email will not give you that.
What it gives you is a written plan and a named account manager. Be clear with yourself about which of those two you need.
Plain answers to the money questions
Money is where careful buyers slow down. These are the questions we would ask in your seat. The answers are as they stand today, and each one points to the written page that governs it.
Is $500 a lot to risk on a first email?
You do not pay to send that email. The terms of the prepayment are set out in writing before you pay, and you can ask about any of them first. Ask as many questions as you need.
What if we prepay and the work misses what we agreed?
A story uses $5 of your balance only when its pull request meets the acceptance criteria you approved. A story that has not met them has not been completed, so it does not draw from the balance. Anything beyond that is a question for the written terms, and you should ask for them before you pay.
Will I pay for stories I did not ask for?
The PRD lists every story before anything is built. Nothing is built until you approve, so a story you did not approve is not part of the work. Check the list line by line before you approve it.
How the balance, the PRD, the pull request and manual QA apply to you
- Here is each piece from your side. Think of it as a map of what to expect, not a promise of exact dates.
- The prepaid balance is the money you put in before work begins. The minimum is 100 user stories a month, so the prepaid amount is at least $500. Each completed story then draws $5 from that balance.
- The PRD is the list. It shows each story, its acceptance criteria and its cost. You read it, change what needs changing and approve it. Your approval is what lets building start, and nothing is built before it.
- The pull request is the result. It arrives in your repository with its tests, and it is judged against the criteria in the PRD. When it meets them, that story is completed, and only then does it draw from the balance.
- Manual QA happens before the pull request is raised. A person clicks through the feature against your criteria before your team sees it. Your engineers then read the pull request and decide what merges, so the last word stays with them.
- If your own QA team knows where the product usually breaks, share that in your first email. Those notes help write the acceptance criteria, which is where they do the most good.
A worked count for one busy month
This example uses made-up numbers.
It shows the arithmetic, not a forecast for your team.
Say a team's PRDs add up to 100 stories in one month, and all 100 are completed.
Those 100 draw $500 from the balance, at $5 each. The minimum and the usage match exactly.
Now say 60 of those stories are completed by month end.
Those 60 draw $300. The other 40 draw nothing, because they were not completed. What happens to the unused part of the prepayment is settled in writing, so check that wording before you commit.
Now the other way round.
Say the team raises requests for only 30 stories in a month. The minimum still stands at 100. Check your own realistic count against 100 before you look at the price per story, because the minimum decides the fit more than the $5 does.
When the PRD arrives, multiply its story count by $5 yourself.
If the cost line does not equal the story count times $5, ask which one is right before you approve.
Questions to settle in writing before you pay
- Some questions are hard to settle after the first payment. Put these in your first email, or in a reply to it, so the answers are on record before you commit.
- Ask when the prepayment is due, and get that answer in writing. Get that answer in writing, because the order affects when you need the money and when you can start to judge the work.
- Ask what happens to stories you do not use in a month. The refunds and billing page says that this is settled in writing, so ask for that writing before you pay, and keep a copy.
- Ask which AI model providers may process your repository, and whether a data processing agreement is needed before work begins. That question is easier to answer before a procurement form arrives than after it.
- Ask how repository access is removed when the work stops, and ask for that answer in writing as well. Access is easy to grant and easy to forget to remove, so it pays to know the steps before you grant it.
Sizing your first request
A first request should fit on one page. One feature, one area of the product, and one reviewer is a good size. A bundle of unrelated asks can still be split, but it reads more slowly in a PRD and takes longer to check.
Look at the screens your users touch.
If the feature needs changes in three places, list those places in your first email. The PRD can then show how many stories each place needs, and you can judge the size before you approve anything.
Smaller is usually easier to check.
A story you can test by clicking through in a few minutes is easier to judge than one that needs a long walk through the product. If a request is large, ask us to split it, and approve the first part alone.
Send the email, and ask the rest in it
- The simplest next step is the email button on this page. Write the feature, your stack, where the code lives and who reviews it. Add any question you want answered before you commit.
- A person reads it and replies. If the work fits, we explain the next step, including the PRD and the prepayment. If it does not fit, we tell you that too, and we point you to a better route where we can.
- Keep the reply. It is the record of what you asked and what we answered. When the PRD arrives, check it against the reply. When the pull request lands, check it against the PRD. That is the thread your team can rely on.
- Your feature has waited long enough. Send the email, and we will take it from there.
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.
2Who 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.
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.