Quality
Your team reviews working software, not a promising draft.
Tests ship with the code. A person checks the feature against the criteria you approved. Then your engineers decide if it earned the merge.
Minimum 100 user stories a month, $500 paid in full before work begins. No seats to buy, no hiring, no notice periods.
- 1
Unit and integration tests.
- 2
Browser tests, end to end.
- 3
Manual QA by a person.
- 4
Your review stays the last word.
Four layers, in this order.
Each layer catches what the one before it cannot.
- 1
Acceptance criteria
Written before code and approved by you. Every later check measures against this list, so "done" is never a matter of opinion.
- 2
Automated tests
Unit, integration and browser tests run on the change. A failure sends the agents back to fix the code and run them again.
- 3
Manual QA
A person clicks through the feature against your criteria. Tests prove what they were written to prove. A person notices when an error message makes no sense.
- 4
Your code review
Your engineers read the pull request like any other. If it would not pass review, it has not earned the merge.
Do not take our word. Three things to try on request one.
We would rather you test us than trust us.
Read the PRD
Does it catch edge cases your own team would have missed?
Run the tests
They arrive in the pull request. Run them on your own machine.
Review the diff
Does it look like your code? It should reuse what is already there.
Your reviewers spend their hour on design, because the basics are already checked
- Imagine the pull request arrives on a Thursday afternoon. The tests already ran and passed. Someone on our team has already clicked through the feature against your criteria. Your reviewer opens the diff with a different question in mind. Instead of asking whether the thing works, they ask whether it is the right design for your codebase, and whether the next developer will understand it.
- That shift changes how review feels. A review that starts with a list of broken cases drains the reviewer, and it tends to push the real design comments to the bottom of the thread. A review that starts from a passing suite lets your engineers spend their judgment on what matters: naming, structure, the risk in a particular change and whether the feature fits the rest of the product.
- Quality also changes what happens after merge. A feature that has been run through every layer is less likely to surprise your users on its first day in production. That is the outcome we work toward. No honest team can promise that no defect will ever reach a user, so we make no such promise. We design each layer to catch a different kind of problem before the change reaches your people.
- Your own standard stays in charge. Your engineers decide what merges, and they can ask for more checks, stricter criteria or a different kind of review on any request. The layers described on this page sit underneath your standard. They do not replace it.
- Think about a typical week of requests. Your team should spend its review hours on design choices and product judgment, not on finding the same missing empty state again and again. Quality built into each change is what keeps that week calm, and a calm review week is one your senior engineers actually get back.
- The destination is a review that feels like reading a careful colleague's work. You read the change, you ask the questions that matter, and you merge it or send it back for a reason you can name. You do not spend the afternoon hunting for what should already have been caught.
- Ask your engineers one question after each review. Did this review teach us something about the design, or did it only catch a slip? If the answer is always a slip, the layers before the review need tightening. If the answer is the design, the process is doing its job, and the hour was well spent.
- There is also a cost to reviews that run late. A pull request that waits three days loses the context its author had in mind. Quality checks that finish before review keep the pull request fresh, and a fresh pull request is much quicker to fix when a reviewer asks for changes.
Confidence that a change works before anyone else touches it
Confidence is the benefit most teams chase and rarely get.
You want to know that a feature works, that it fails in a sensible way when something goes wrong, and that the next change will not quietly break it. The layers on this page are built to give you those answers, in order, with evidence you can read for yourself.
Acceptance criteria give the feature a finish line.
You approve them before any code is written, so nobody has to argue about what done means at the end. A criterion either passes when a person clicks through the feature or it does not. There is no meeting in which opinions compete to decide the outcome.
Automated tests protect the next change.
A unit test watches one piece of logic. An integration test checks that two parts still work together. A browser test walks through the feature the way a user would. Together they stop a later edit from breaking something that worked yesterday, which is the cost most teams pay quietly every month.
Manual QA adds judgment to that protection.
A test can confirm that an error appears. It cannot tell you that the error message is unclear, or that a success notice shows before the save has finished. A person can, and a person on our team reads the message as a customer would before the pull request is raised.
Code review closes the loop.
Your engineers read the change, check the design and decide whether it merges. That review stays yours, and it moves faster because the basics are already in place when it begins.
The benefit adds up over time.
Each feature that ships with its tests makes the next one easier to change, because the tests describe what the feature is supposed to do. Your codebase becomes easier to work in, not harder, and new engineers can read the tests as a plain description of the product.
Confidence also grows through the criteria themselves.
A criterion that a person has checked once, against the real feature, is a criterion your team can trust in the next round. Over several requests, the approved criteria become a plain list of what your product promises, written in the words your users would use.
A simple test shows whether this is working.
Ask whether a new hire could understand the feature from the criteria and the tests alone. If they could, the work is documented well enough to trust, and it will still make sense after the people who built it have moved on.
Criteria that a person can check by clicking.
Tests that stay behind, guarding later changes.
A manual check for what tests cannot judge.
A review focused on design, not on basics.
Six layers, and what each one catches
Each layer has a different job, and the order matters.
The layers start with the cheap and fast checks and move toward the slower, more human ones. That order keeps the expensive review time for the questions that need it.
Acceptance criteria come first.
They are written from your request, approved by you and used as the yardstick for every later layer. A good criterion names what the user sees or gets, what a failure looks like and where the limits are. Vague criteria go back for another pass, because a vague finish line cannot be checked.
Unit tests come next.
They cover single pieces of logic, such as a calculation, a rule about who may see a record or a function that formats a date. They run fast and catch the mistakes that are easiest to make and easiest to miss in a long diff.
Integration tests check the seams.
They confirm that the frontend sends what the backend expects, that the database returns the shape the code reads, and that the parts agree on what an error looks like. Many real failures happen at those seams, which is why they get a layer of their own.
Browser tests sit at the top of the automated stack.
They open the feature and do what a user does, from the first click to the final confirmation. They catch the problems that only appear when every part runs together inside a real page, such as a button that works in isolation but never receives the data it needs.
Manual QA is the human layer.
A person clicks through the feature against the criteria, then looks at the things a script does not notice: a confusing label, an empty state with no guidance, or a flow that makes sense to the developer and to nobody else.
Code review is the last layer, and it belongs to your team.
Your engineers check design, naming, risk and fit with the rest of the codebase. The earlier layers mean this review can focus on those questions instead of on basic mistakes.
Each layer also tells you something when it fails.
A failing unit test points at one function. A failing browser test points at a whole flow. A problem found in manual QA usually points at a gap in the criteria. Knowing which layer caught a problem shows where to tighten the next request, and it shows what kind of problem your product tends to have.
Acceptance criteria:
what done means, approved before any build.
Unit tests:
single pieces of logic, checked fast.
Integration tests:
the seams where parts meet.
Browser tests:
the whole feature, the way a user meets it.
Manual QA:
a person reads and clicks what scripts miss.
Code review:
your team decides what merges.
A check you can run yourself on request one
- We have no customer quotes to show you, and we will not invent any. That is the honest starting point. Quality is the one area where you do not need to take our word for anything. You can check the work yourself, and we would rather you did.
- Start with the tests. They arrive in the pull request, so you can pull the branch and run them on your own machine. If they pass there, the claim that they pass is no longer ours to make. It is a result you have seen with your own eyes, on your own hardware.
- Then read the criteria. Ask whether a person could check each one by clicking through the feature. If a criterion says the page should feel fast, ask what fast means in numbers, and ask for that number to be written down before the build starts. Vague words are the first thing to fix, not the last.
- Then click through the feature yourself. Try the empty state, the failure path and the back button. Type the input a real user would type, not only the tidy example a demo uses. Look for what a script would never think to test, because a person who has used the product for a year will notice it at once.
- Seven live products are the other evidence we can offer. 60db.ai, Qcall.ai, Vrid.ai, Niyam.ai, Autoposting.ai, Firstsales.io and Communicate.so were each built using AgentCTO, and each went through manual QA by a person before release. Open one. Use it for a few minutes and watch what happens when things go wrong.
- If you find something that should have been caught, tell us. That is useful information, and it shows you whether the layers are working for your kind of product. Testing us is your own due diligence, and it is the right instinct for a team that is about to merge code it did not write.
- Read the pull request description, too. It should say what changed, which criteria the change meets, and what was checked by hand. If the description claims something without a test or a note to back it up, ask about it. A short, honest description is a good sign. A long one full of confident words, with no evidence attached, is a reason to look closer.
- Use the same standard you would use for a colleague's work. Check the one thing you care about most first, such as a payment step or a permission rule. Look at how it fails, not only at how it succeeds, because failure is where most of the damage happens.
How quality holds up against a coding tool, a hire or an agency
A coding tool produces code quickly.
Quality still depends on whether your team writes the criteria, runs the tests, clicks through the feature and reviews the diff. The tool is one step in that chain, and the rest of the chain is the part that tends to get skipped under deadline pressure.
A hire brings quality habits, and a good engineer often holds a high bar.
One person's bar is hard to scale across a backlog, though. Quality then depends on that person's calendar, on their availability for review and on how much testing the team has already built around them.
An agency's quality process is whatever it has written into its contract and its own practice. Ask to see its checklist for a recent project. Ask who runs the tests, who checks the feature by hand and what happens when a defect reaches users after launch. Those answers tell you more than a case study does.
None of these is a bad choice in every case.
If your team already runs a strong test suite and reviews every change well, a coding tool may fit into what you have. If you need a person solving hard product problems every day, hire. The question is where your quality checks live today, and whether they run on every change or only when someone remembers to run them.
Our layers run on every request, whether the request is large or small.
They do not depend on one engineer's memory or one reviewer's free afternoon. That consistency is the real difference, more than any single type of test.
If your team already has a suite, tell your account manager where it lives, so the new work sits next to it rather than in a separate corner. Quality is easier to keep when the new checks and the old ones share one place, and one set of results.
A hire can be a strong choice for quality, but plan for the review time.
Someone has to read each change, and that time comes out of your senior engineers' week. If that time is already full, the quality checks will slip first, long before the feature does.
When you talk to a coding tool or an agency about quality, ask what happens when a test fails. Ask whether a person checks the feature before release. Ask what happens after a defect reaches users. The answers are plain facts you can compare side by side, and a vague answer tells you something too.
Coding tool:
fast drafts, with the checks left to your team.
Hire:
strong judgment, limited by one person's time.
Agency:
quality set by its own process, which you should read first.
AgentCTO:
four layers on every request, with a person checking by hand.
Hard questions about quality, answered in full
Does a passing test suite mean the feature works?
It means the feature passes the checks we wrote for it. That is useful, but it is not a guarantee. Manual QA and your code review exist for the gaps that tests leave behind, and that is why there are several layers rather than one.
What if a user does something the tests never imagined?
That is what manual QA is for, and it is also what your own users will do later. Tell your account manager about any real defect you find, so the next criteria cover that case.
What about speed and security?
If speed matters for a feature, write it as a criterion with a number, and the work is checked against what is written. If security matters, name the risk in the request, such as who may see what, and the criteria will say so. Your code review still covers the things a general checklist would miss.
What if our existing tests are weak or flaky?
A flaky test is one that fails at random, for no clear reason, and it wastes review time. Tell your account manager which tests your team already distrusts, so the first request does not build on them without a note.
Do the tests replace our review?
No. Your engineers review every pull request, and they decide what merges. The tests make that review faster and more focused. They support the decision, and the decision stays with your team.
What counts as done when a story is complete?
A story is complete when its pull request meets the acceptance criteria you approved. The same test applies every time, and the criteria are written before the build starts, so the finish line does not move in the middle of the work.
Can we add our own checks?
Yes, if you name them in the request before you approve the PRD. A check written into the criteria gets built and tested like everything else. Raising a new check only after approval is a change to the scope, so it is best to name it early.
What if the request is very small?
A small change still goes through the same layers, although a tiny change may need only a few tests. The checks should match the size of the change, not the size of your worry about it.
What happens when a bug shows up after merge?
Tell your account manager. The usual first step is to look at which layer should have caught it, and then to add a check for that kind of problem to the next request, so the same gap does not come back.
What if one of your reviewers disagrees with a check?
Raise it in the pull request, the same way you would raise any other review comment. The check is part of the request, so changing it is a decision for your team to make and write down. Nothing changes quietly.
Judge the quality on your first pull request
- The best way to judge quality is to see it on your own code. Send one request you would be comfortable merging, and read the result with the standard you already use.
- Check the criteria in the PRD first. Then run the tests, click through the feature and read the diff. If all four hold up, you have seen the layers work on your own code, and the decision to continue is an easy one to make.
- If something does not hold up, tell us which layer missed it. That tells us where to tighten the next request, and it tells you whether the process fits the standard your team keeps.
- 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 the three things below so the first PRD can start the same day.
- You do not need a finished test plan to start. Most teams find the criteria are the hard part, and that is the part worth a careful hour. If your team has no test suite yet, say so in the request. We will state in the first PRD what the checks rest on, so you can see the gap before you approve anything.
The request you would be comfortable merging.
Your current bar for review, written in one line.
Any test suite your team trusts, and where it lives.
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.
2Is 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.
3Will 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.
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.