Our story
The agents worked. Everything around them was broken.
We did not set out to start a services company. We were trying to ship our own products with AI agents, and we kept hitting the same wall.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
A broken pipeline.
- 2
No custom harness to buy.
- 3
So we built our own.
- 4
Then we opened it up.
How we got here, plainly.
If you have tried to ship real work with agents, some of this will sound familiar.
- 1
At first it felt like magic
You describe a feature. Code appears in minutes. You sit back and start doing the maths on how fast you can now move. Anyone who has tried this knows that first evening.
- 2
Then the next morning arrived
The code compiled, and it was not quite right. It had made its own helper when one already existed. The empty state was missing. Nobody had decided what should happen on failure, so the agent had guessed. Someone had to read all of it carefully, and that someone was us.
- 3
The bottleneck just moved
Typing was never the slow part. We now had more drafts than we could review, and our most senior people spent their days prompting, re-running and checking. We had bought speed in one step of the pipeline and piled up work in every other step.
- 4
We looked for the fix, and could not buy it
There were plenty of tools for writing code. What we wanted was the setup around them: something that reads your repo first, agrees scope before building, runs real tests, and has a person check the result. Generic setups did not know our code. A harness has to be built around the repo it works in, and nobody was selling that.
- 5
So we built our own
We wrote the PRD step first, so nothing got built until scope was agreed. We made tests part of the job and not the cleanup. We made agents follow the patterns already in the repo. We kept a person at the end. It stopped feeling like magic and started feeling like a pipeline, which was much better.
- 6
Then it started shipping products
The same setup is behind the seven products on our work page. Each one is live and you can open it today. That is when we stopped thinking of it as an internal tool.
- 7
Why we sell it this way
Most teams do not want another tool to run. They want the feature they have been postponing for a quarter. So we do not sell seats. You send the request, we own the pipeline, and $5 comes off your prepaid balance when a user story meets the criteria you approved. If it would not pass your review, it has not earned the merge.
Picture drafts turning into merged work, not piling up
- You have seen the pattern before. A coding tool writes a draft in minutes. The draft looks promising. Then the real work starts, and the draft becomes a stack of things to check, fix and explain. The feature still is not in your product.
- This story is about the step that comes after that first draft. It is about how the work moves from a request to something your team can merge, without someone on your side acting as the project manager, the reviewer and the QA team all at once.
- Imagine the feature you have been carrying for a quarter. It has a written plan with its edge cases and acceptance criteria. It has tests that run with the code. It has been checked by a person against the criteria you approved. It sits in your repository as a pull request, waiting for your engineers to decide. That is the change we are trying to make real.
- The rest of this page explains how we got to that setup. We were not trying to start a services company. We were trying to ship our own work with agents, and the gaps we hit along the way became the design of what we sell. Read it for the reasons behind the process, so you can judge whether the reasons apply to you.
A pipeline that finishes work, not one that only starts it
Agents are good at starting things.
Give them a request and they produce code quickly. The hard part is finishing, which means the screen works, the empty state exists, the error message makes sense and the tests pass in the same change.
We built around that gap.
The aim is not a fast first draft. The aim is a pull request that your team can review and merge with confidence. Every step between the request and that pull request exists to close a gap that we kept hitting on our own products.
The payoff is that your team reviews working software rather than a promising draft.
The tests come with the change. The criteria were agreed before any building started. A person has already clicked through the feature. Your engineers can spend their attention on the questions that need a human, such as whether the design fits your product and whether the change is worth the risk.
That is the difference between starting work and finishing it.
A pipeline that only starts work hands the finishing back to you, and it usually lands on your most senior people. A pipeline that finishes work gives your team its time back, and it lets the backlog move without a hiring plan.
A plan with user stories and acceptance criteria before any code.
Unit, integration and browser tests that ship with the change.
Manual QA by a person before the pull request is raised.
A pull request your engineers review and decide to merge.
The four changes we made, in the order we made them
The first change was to write the PRD before anything gets built.
Nothing starts until the scope is agreed, the edge cases are named and the stories are counted. That turned a vague feeling of progress into a list that someone could approve or reject.
The second change was to treat tests as part of the job.
Tests used to show up at the end, as cleanup. We moved them into the same work as the feature, so a failing test sends the agents back to fix the code rather than leaving a surprise for a reviewer later.
The third change was to make agents follow the patterns already in the repository.
A new helper that duplicates an old one is not progress. It is a second way of doing the same thing, and someone has to choose between them. Agents now read the codebase first and reuse what is already there.
The fourth change was to keep a person at the end.
Automated tests check what they were written to check. A person clicks through the feature and notices the odd error message, the empty screen nobody designed or the flow that technically works but feels wrong. That check is slower than a test run, and it catches what the tests cannot.
Each change was small on its own.
Together they changed the shape of the work. The process stopped feeling like a clever trick and started feeling like a pipeline, which is what a team needs when it has to ship every week and sleep at night.
From a first evening of magic to a steady delivery rhythm
The first time you see an agent write a feature, it feels like magic.
Code appears in minutes, and you start doing the arithmetic on how fast you can now move. Almost everyone who has tried this remembers that first evening.
The morning after is different.
The code compiles, but it is not quite right. A helper was duplicated. The empty state was missing. Nobody decided what should happen on failure, so the agent guessed. Someone had to read all of it carefully, and that someone was us.
The rhythm we built is the opposite of that morning.
Requests come in plain English. The PRD arrives with the scope and the cost. You approve it. The work runs in parallel, the tests run with it, and a person checks the result before the pull request is raised. What we sell is the steady part.
We have no customer quotes to show you yet, and we will not write one for you.
We are onboarding our founding cohort. What we can point to is the work itself. The same setup sits behind the seven products on our work page, and each one is live. You can open them and judge the results for yourself.
Our sample run shows the shape of one request.
The page labels it sample data, and it is not a customer result. A request to add CSV export listed four user stories, a cost of $20 in total, and one automated test failure that agents fixed before the pull request was raised. A person then checked the feature against the criteria before the merge.
If the first evening sounds like your own experience, you are not alone.
The steady rhythm is what separates a demo from a delivery pipeline, and it is the part that takes the most care to build.
Why speed in one step does not clear the backlog
Speed in one step of a process can hurt the whole process if the rest of it stays the same.
That was the lesson from our first attempts. Writing code got faster, and every other step of the pipeline filled up with work.
Hiring adds people, and people bring their own ramp time and their own review load.
A new engineer is a real gain, but the first few months are slower, and the queue keeps growing while they learn your code. Hiring is the right answer when you need people in the room, but it does not clear a backlog on its own schedule.
Coding tools speed up the typing.
Someone still has to write the request, steer the agent, decide the design and run the checks. If that person is already busy, the tool moves the bottleneck rather than removing it. We saw that happen to our own senior people before we built the rest of the pipeline.
Agencies can take work off your plate, but the work often arrives in a form your team must still review, test and maintain. How much of the process is shared depends on the contract and on how the handover works.
We built the rest of the pipeline because the bottleneck was never only the typing.
It was the planning, the tests, the QA and the review. Our route covers those steps and hands you a pull request that your team decides about. That is why we sell the outcome, and not a seat or an hour.
Hiring:
strong ownership, but slow to ramp and slow to clear a queue.
Agencies:
useful capacity, but the handover shape depends on the contract.
Coding tools:
fast typing, but someone on your team still runs the process.
AgentCTO:
we run the process to the pull request, and you approve every merge.
Honest questions about where this came from
A story told by the seller deserves some doubt. These are the questions we would ask ourselves in your place, with the answers we can give today.
Was this built only for ourselves?
It began as the way we shipped our own products. It is now the way we sell to others. We did not set out to start a services company, and we do not claim the story is more than it is. What matters is whether the process works on your repository, and that is for you to test on a first request.
Why should we trust a story that flatters the team?
Do not trust the story. Trust the artifacts. Read the PRD, run the tests and review the diff. The story only tells you why the artifacts look the way they do.
Does the setup fit an old codebase?
It is built to read your code first and follow the patterns it finds. PHP, Node, Python, Java, .NET and Go are in scope, including legacy code. Ask us about your stack in your first email, and we will tell you plainly where we see the fit.
Will the process change over time?
Probably, because we keep learning from the work. Changes will show up in the pull requests and the PRDs, and your team can see them as they happen. We would rather you notice a change than trust that nothing moved.
What if our product is unusual?
Tell us in your first email. The PRD will show whether the agents understand the feature well enough to plan it. If they do not, you will see that before you approve.
An example request, step by step
- This is an example, not a customer result. It shows how a request could move from your inbox to a merge, so you can picture the steps before you send anything.
- Suppose you write one line: let customers download their invoices as a PDF from the billing page. An agent reads the billing code and the existing invoice template first. It then writes a PRD that lists the stories, such as the download itself, a clear message when an invoice is missing, and a check that the file name matches the invoice number. The PRD shows the count and the cost, so you can see the price before anything is built.
- Say the PRD lists three stories. At $5 each, the count comes to $15 from your prepaid balance, if all three meet the criteria you approved. That is arithmetic, not a quote. Your real count comes from your own PRD.
- Once you approve, agents build the feature and write the tests with it. A person then clicks through the feature against the criteria in the PRD. If a check fails, the agents fix the code and run it again. Only then does the pull request land in your repo, where your engineers can review it like any other change.
- Notice where you spend your time in that example. You read the request, the PRD and the pull request. The middle is handled for you, and you can check each of those three points without trusting anyone's word.
What to check before you buy
Before you buy, read this story as a buyer, not as a fan.
When a PRD arrives, look for the gaps your own team would have caught, such as empty data, failed saves and users who lack permission. If the list is thin, ask us to add stories before you approve.
Next, ask the questions the story cannot answer for you.
Ask which AI model providers may process your code. Ask who on our side reads your repository and what access they get. Ask what happens to unused prepaid stories, and ask for that answer in writing. Our refunds page says that written answer is what applies to you.
Then check the pull request against your own bar.
Does it reuse the helpers already in your repo? Do the tests run on your own machine? Would your engineers merge it on a normal day? If the answer to any of those is no, your team should say so, and the story has not earned the merge.
Does the PRD name what happens on failure?
Who on your side can approve a PRD and review a pull request?
Which AI model providers may process your code, and what did we confirm in writing?
What is the narrowest repository access the work needs?
Who this story is not for
This story is not for you if your team has no one who can review code.
Your engineers make the final call on every merge. If nobody has that time, pull requests will sit unread, and the process will not pay off.
It is also not for a handful of changes a year.
The minimum is 100 user stories a month, and that is a real commitment. A small team with a few requests a year would be buying a minimum it may not use up. Hiring a contractor or buying a coding tool seat may suit you better.
Finally, this is not a shortcut around a product decision.
We work from your repo and your requests. If you do not yet know what the product should do, the PRD will expose that gap, and no amount of agent speed will close it for you.
Honest limit:
the seven live products on our work page were built using AgentCTO. That shows the setup has shipped real software. It does not show how it would go on your codebase, with your reviewers.
Objections, with plain answers
Objection: our code is ours, so why let an agent read all of it?
Plain answer: the agent cannot follow your patterns without reading them. Give only the repositories in scope, under the access you agree. Agents and our team read those repositories, and AI model providers may process them. If that still worries you, start with one repository and the smallest scope you can live with.
Objection: what if we stop after a few months?
Plain answer: the code lands in your repository as ordinary pull requests, in your history. There is no platform of ours to leave. Our code-ownership page says that if you stop, nothing breaks, because the work already sits in your repository.
Objection: what happens to stories we prepay for and never use?
Plain answer: it is settled in writing before you pay, as our refunds page says. We will not guess at the terms on this page. The $500 minimum is prepaid, and each completed story draws $5 from that balance.
Objection: what if the PRD is wrong about your product?
Plain answer: you approve it, so nothing is built on a guess you did not see. You can change anything in it. A wrong PRD costs you a read, not a sprint.
Objection: will a person catch what the tests miss?
Plain answer: that is what the manual check is for, and a person can still miss things. A person clicks through the feature against your acceptance criteria. It is there to catch odd error messages and empty screens that tests were never written to see. It does not replace your code review.
What each part of the process means for you
Prepaid stories are the money side of the work.
Each completed story draws $5 from the balance you have prepaid, and a story only counts once its pull request meets the criteria you approved. The count is on the PRD before anything gets built, so you can add it up yourself.
The PRD is the scope side.
It is the document where you agree what the feature is, using the stories, edge cases and acceptance criteria. Read it as the agreed scope. If a line in it is vague, that is your signal to ask before you approve, not to hope the build will guess right.
The pull request is the proof side.
It arrives in your repo with its tests, and your engineers review it like any other change. Judge the diff, the test results and how well it fits your code. If your team would not merge it, say so in the pull request.
Manual QA is the human side.
A person checks the feature against the criteria you approved, and that check sits between the automated tests and your review. It replaces neither of them. It adds a person's eyes to the thing you will eventually decide about.
Put together, the four parts give you evidence you can check yourself.
Count the stories, test the criteria against what you know, and weigh the pull request. If any part fails your standard, the process has told you something useful about fit.
Start with the feature that keeps getting pushed back
Every team has one.
It is the feature that keeps moving to the next sprint, because it is never urgent enough and never small enough. It sits at the bottom of the list while the customers who need it stop asking.
That is where we would start with you.
Send us that feature with the email button on this page. Describe it the way you would describe it to a colleague, and tell us the stack and who reviews the work. A person reads it, and we reply with what we need next.
Then watch the process from the outside.
Read the PRD when it arrives, and check that it covers the edge cases your own team would have listed. Approve it only when the criteria read clearly. When the pull request lands, run the tests and read the diff before you decide.
If the story holds up on your repository, the next request will go faster, because the patterns are already known. If it does not, you will know that from the PRD or the first pull request, which is a far cheaper lesson than a year of planning meetings.
Questions, answered plainly.
Can’t find yours? Write to a founder.
1How 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.
2How 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.
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.