Design waits on scope
Nobody can draw it until somebody has decided what it is.
How we work
You write what you want. A tested pull request comes back.
No new tool and no sprint planning. You do two easy things: raise a request and approve a plan. Your team then reviews the pull request like any other.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
A written PRD the same business day.
- 2
Nothing built until you approve.
- 3
A pull request within 3 business days of approval.
- 4
Your team decides what merges.
The usual way
One feature takes a whole pod, and everyone waits on someone.
Most of the 22 days in a normal feature is not typing. It is people waiting for other people to finish.
Frontend waits on the API
Work runs one step after another, so each delay moves everything behind it.
QA finds it last
Bugs surface at the end, when fixing them costs the most.
Four steps from issue to merge. You touch three of them.
Here is who does what, in order.
- Step 1 · You
Raise the request
Write it the way you would tell a colleague. One line is fine if it is clear.
- Plain language. No ticket format and no spec to write.
- Any size. A full feature, a bug or one forgotten edge case.
- Step 2 · Same business day
Agents write the PRD, you approve it
Agents read your code, then list the stories, edge cases and acceptance criteria. You see the count and the cost.
- Scope you can read. Every story has criteria a person can check.
- A real gate. Nothing is built until you click approve.
- Step 3 · Within 3 business days
Agents build, test, and a person checks
UI, frontend, backend and tests run in parallel. When a test fails, agents fix the code and run it again. Then a person clicks through it.
- Automated QA. Unit, integration and browser tests.
- Manual QA. A person checks it against the criteria you approved.
- Step 4 · Your call
Review the pull request and merge
The PR lands in your repo with its tests. Your engineers review it as usual and decide what merges.
- Your branch strategy. The work lands where your team already looks.
- Optional deployment. Keep releases in-house or hand them to us.
What you need
Four things on your side.
If you have these, you can start this week.
- A repository we can raise pull requests on.
- A backlog, even a messy one.
- Someone who can review pull requests.
- Someone who can approve a PRD, often the same person.
Your feature ships without a sprint meeting in the way
Picture a request you have been postponing for a quarter.
On Monday morning you write it in plain English, the way you would explain it to a colleague over coffee. You do not fill in a ticket template or a spec form. You say what the feature should do, who it is for and what is wrong with the way things work today.
We aim to open a written PRD the same business day.
It lists every user story, the flows and screen states, the edge cases and the acceptance criteria. It also lists the cost, because each story is $5 and the count sits at the top of the page. You can read it at your own pace, ask for changes, and cut or add stories until the scope says what you actually want.
You approve the PRD only when it is right.
From that point, the clock runs for three business days, and the pull request lands in your repository with its tests attached. You do not have to chase anyone for a status update in between, because your account manager follows the request for you.
On Thursday, your engineers open the pull request.
They read the diff the way they read any other change, check it against the criteria you approved, and decide whether it merges. Nobody had to book a planning meeting, chase a designer for a mockup, or wait for a backend change before the frontend could begin.
That is the destination.
A feature moves from idea to reviewable code, and your team stays on the work only it can do. The queue gets shorter each time a request clears, and the small asks finally get built too. An edge case that was cut to protect the sprint can now be its own user story, written, counted, approved and built like everything else.
Think about your week in that picture.
You stop being the relay between product, design and engineering. You read documents you can judge, instead of waiting for a meeting to explain them. Your calendar keeps its slots for the decisions only you can make, such as which requests matter most this quarter.
Some teams worry that a PRD written by someone else takes control away.
Here you approve every scope decision, and nothing is built on an assumption you did not see. The same shape works for a small fix. A change to one screen gets a short PRD with a single user story, so a small request does not wait behind a large one. It moves through fewer people and reaches a pull request sooner, with fewer conversations about it along the way.
Your part stays small through all of it.
You read a document, you press approve, and you review a pull request. Everything between those three moments is the work that used to fill your team's calendar, and it now runs without a meeting for each step.
Fewer handoffs, and nobody waits on someone else
A traditional feature moves through people in a line.
Design waits on scope. Frontend waits on the API. QA waits on both. Each handoff adds a delay, and the delays stack up. Our working figure for a traditional four-person squad is about 22 business days from start to a finished feature. Most of that time is people waiting for other people.
On our path, the steps run together.
The UI, the frontend, the backend and the tests are built at the same time, following the patterns already in your repository. Nobody sits idle while the step before them finishes, so the three business days after your approval are spent on building.
There is less rework in the middle as well.
Scope and edge cases are agreed before any code is written, so the builders are not guessing what the empty screen should say or what should happen when an upload fails. That removes a common source of rework before it starts.
Your team also skips the coordination work.
You do not need a standing meeting for this feature, a board to keep current or a status chase between design and engineering. Your named account manager tracks every request from the first email to the merge, at no extra cost.
Think about the cost of waiting, too.
Every week a feature sits in a queue, the customers who asked for it keep asking, and some of them stop. A shorter path also keeps the people who asked for the change around long enough to see it land.
A small request follows the same shape.
It moves through fewer people, reaches a pull request sooner and needs fewer meetings to explain it. The count on the PRD shows the cost before anything starts, so there is no guessing about whether a small ask is worth the queue.
Parallel work also means fewer surprises at the end.
When the UI, the frontend and the backend are built together, a mismatch between them shows up in the same test run, while the change is still small enough to read. You do not get a sudden list of integration problems in the final week.
Your engineers stay on the work only they can do.
Scope is agreed before any code is written.
Builders follow the patterns already in your repo.
One person on our side tracks the whole request.
Each step leaves something you can check
- Every stage of the path leaves a record. You can look at it, question it and decide what happens next. Nothing important is hidden inside a tool you cannot read.
- The first record is the request. You write it in your own words, so there is no ticket format to learn. Include what you want built, where the code lives and who on your side will approve the PRD and review the pull request. Those three things are enough to start.
- The second record is the PRD. It describes the flows, the states each screen can be in, the edge cases and the acceptance criteria for each user story. The criteria are written so a person can check them by clicking through the feature. That check is the test we use to judge whether a criterion is any good.
- The third record is the approval. It is a single click, and it is the gate for everything that follows. Nothing starts until you press it, so you see the count and the cost before any work begins.
- The fourth record is the test run. Unit, integration and browser tests run on the change. When one fails, agents fix the code and run the suite again. The pull request is raised once the suites pass.
- The fifth record is the manual check. A person on our team clicks through the feature against the acceptance criteria you approved. That person looks for what a test cannot see, such as an error message that makes no sense or a screen that loads but helps nobody.
- The last record is the pull request itself, with its tests included, in your repository. Your engineers review it like any other change, and they decide what merges.
- Taken together, these records give you a paper trail you can follow from the first sentence to the final merge. You do not need to trust a summary. You can open each record and see what was asked, what was agreed, what was tested and what a person checked.
- A reviewer on your side sees the same record at every stage. That makes a conversation about a feature easier, because everyone points at one PRD, one set of criteria and one test run, instead of three versions of what was meant. The record also protects your team. When someone asks why a behavior exists, the answer points to a criterion you approved.
Step 1, you:
raise the request in plain English.
Step 2, agents:
write the PRD with stories, criteria and cost, the same business day.
Step 3, you:
approve the PRD. Nothing is built before this click.
Step 4, agents:
build UI, frontend, backend and tests in parallel.
Step 5, agents:
run the automated tests and fix what fails.
Step 6, a person on our team:
check the feature by hand.
Step 7, AgentCTO:
raise the pull request within three business days of approval.
Step 8, your team:
review the pull request and merge what it accepts.
Seven live products show where the process ends
We have no customer quotes to show you yet, and we will not write them for you.
That is the honest position. What we can show is the finished result of this same process. Seven products were built using AgentCTO, each one went through manual QA by a person, and each one is live today.
The seven are 60db.ai, Qcall.ai, Vrid.ai, Niyam.ai, Autoposting.ai, Firstsales.io and Communicate.so. They are real products with their own websites, not demos, so you can judge their finish yourself.
The spread of work is wide.
Voice, calls, search articles, social publishing, cold email, customer answers and legal research are very different jobs. Building all seven through one process is the reason to look closely. A process that only suited one kind of product would struggle across this range.
Open one of them and look for what a reviewer usually misses.
Check the empty state, the error message and the last step of a form. Those are the details that show whether somebody thought about the person using the screen.
The feeling we want you to have is relief that a request you have postponed for months now has a clear path, a written scope and a named person tracking it. That relief is what the first request has to earn.
If you want a second opinion before you commit, show the PRD to a colleague who knows the product. Ask one question: would they know when this feature is finished, just by reading the criteria? If the answer is no, the criteria need more work before anything else does.
Here is the check you can run on request one, before you commit to more.
Read the PRD and look for the edge cases your own team would have missed. Run the tests on your own machine. Read the diff and see whether it reuses what is already in your code.
Nothing gets built until you approve the PRD, so the decision to go ahead stays in your hands at that point. Until then, nothing has been built for you, and the choice is still yours to make.
How this path stacks up against hiring, agencies and coding tools
Hiring gives you people, and people carry their own cost and timing.
The figures on this site put a hire at about three months to find, six weeks to ramp up, and notice periods on top. Every week of that is a week the queue keeps growing. Our path does not replace the people you already have, and it asks you to buy no seats.
Agencies sell you a team for a project.
We have no agency price or agency timeline to quote, so we will not guess at one. Ask any agency who writes the spec, who runs the tests, who checks the feature by hand and who owns the repository once the project ends. Those four answers tell you more than a rate card.
Coding tools give you speed at the keyboard.
Someone still has to write the PRD, steer the agent, make the design calls and run QA. If your engineers have spare hours and enjoy that work, a coding tool is a fair trade. If those hours are already spoken for, the bottleneck stays exactly where it was.
Our path sits in a different place.
We take the request, write the PRD, build, test and run manual QA. Your team keeps the merge. That gives you one clear line of responsibility, so you can see exactly where your work starts and where ours ends.
None of these is wrong for every team.
Hiring suits work that needs people in the room every day. An agency can suit a short, fixed project with a clear end. A coding tool suits a team with spare hours. Our path suits a team with a repo, a growing backlog and someone who can review pull requests.
If you are unsure which one fits, sort your last three months of requests.
Count how many were small asks that never got scheduled, how many needed a person in the room, and how many were waiting on your own engineers' spare hours. The split usually points to the right option faster than any brochure.
A quick test for any option is to ask what happens in the week after you sign.
Hiring means a new person still needs a ramp-up. A coding tool means your engineers learn a new workflow. Our path means your first PRD arrives the same business day, and the first pull request follows within three business days of your approval.
Be honest about the answer, even when it points away from us.
If the right fit is a hire, or a tool your team already runs well, that is a good outcome for you. It is better than a mismatch that costs you months of waiting.
Hiring:
you carry the salary whether the queue moves or not.
Agencies:
ask who writes, tests, checks and owns the code.
Coding tools:
someone on your team still owns every step after the first draft.
AgentCTO:
$5 per completed user story, and your team decides what merges.
Hard questions about the process, answered in full
What if the PRD misses an edge case that matters to us?
You can add it before you approve. Each edge case becomes its own user story, counted on the page and priced at $5 if it completes. Nothing is built until you approve, so an added edge case never reaches the build without your say.
What if a test fails during the build?
Agents fix the code and run the suite again. You only see the pull request once the automated suites pass and a person has checked the feature against your criteria. A failed test is part of the normal path, not a surprise at the end.
What if our engineers dislike the pull request?
Your team decides what merges. An unmerged pull request changes nothing in your product, and your engineers can turn it down for any reason that matters to them. Their judgment is the final check, and it stays that way.
What if the feature is right but the code style is not?
The first thing agents do is read your repo. They follow the patterns already there, and a reviewer can still send back anything that does not match your house style. That is a normal review, the same one you run today.
What if we stop halfway through?
Everything we deliver lands in your repository as ordinary pull requests, so the work stays in your history. For what happens to prepaid stories you have not used, ask us before you pay. We will answer in writing, and that written answer is the one that applies to you.
What if nobody on our side has time to review?
Then this path does not fit yet. A pull request needs a reviewer, and your team makes the final call on every merge. We would rather you know that before you prepay.
What if the request is bigger than we expect?
The count appears on the PRD before you approve it. If it is more than you want to spend in one go, you can cut stories from the PRD before you approve. Cutting stories does not lower the $500 monthly minimum.
What if a feature touches a part of the system our team does not own?
Then your account manager and your team agree access before work begins. Give only the repositories in scope, and ask us what the work will touch before you approve.
What if a person on your team needs to check the work before the pull request is raised?
That is already built in. A person on our team clicks through the feature against your acceptance criteria first. Your reviewers see the work after that check, not before it.
Send one request, and see the scope the same business day
- The next step is small. Write the feature you keep postponing. Say what you want built, where the code lives, and who on your side will approve the PRD and review the pull request.
- We open the PRD the same business day, so you can read the scope and the story count before you decide anything. Nothing is built until you approve, and you can change the wording until it says what you want.
- Three business days after your approval, a pull request is in your repository with its tests. Your team reviews it and decides what merges. That is the whole path, from one email to one merge.
- Use the button on this page to send your first request by email. Write to us the way you would tell a colleague, and a person will answer. Include these three things so the first PRD can start the same day.
- Keep the first note short. A paragraph is enough. The detail gets worked out in the PRD, where you can read it, change it and see the count, so you do not need to write a full spec before you send anything.
- Once the first PRD is in front of you, the decision is simple. Does the scope match what you asked for? Is the cost one you accept? Can a person check every criterion by clicking through the feature? If the answer is yes to all three, approve it. If not, say what is missing and the PRD gets revised.
What you want built.
Your stack and where the code lives.
Who approves PRDs and who reviews pull requests.
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.
3Is 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.
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.