Why we built Ito.

The problem

Your engineers generate pull requests at AI speed, but before they can merge, someone has to manually test every change. Click through the same flows. Fill out the same forms. Try to remember which edge cases matter.

Across the industry, engineers spend an average of 3 hours per week per engineer on manual testing. For a 20-person team, that’s 60 hours weekly, or 1.5 FTEs doing nothing but clicking through flows. This is the tax your engineering team pays every single week.

Your team isn’t lazy. They’re making optimal choices with terrible economics.

Manual testing has awful ROI, so rational teams only do it on the “important stuff” and ship the rest and hope for the best. Alternatively, they burn valuable hands on keyboard hours doing repetitive clicking that a computer should be doing. Neither option is good. Both feel inevitable.

The market tells you this is a process problem. That you need better discipline. More rigor. Stricter gates. A QA team. Maybe hire a contractor. Write more tests. We think that’s fundamentally wrong.

The real problem isn't discipline. it's infrastructure.

Think about what happened with continuous integration. Before CI/CD, someone had to manually build and deploy code. Teams had “integration weeks” where they’d merge everything and pray it worked. Nobody does that anymore.

Not because engineering culture got more disciplined, but because the tools got so good that manual deployment became obviously obsolete.

QA is having that same moment right now. Some teams automate the clicking with Selenium or Playwright, but that just shifts the burden from manual testing to test maintenance. You’re still burning engineering hours keeping tests in sync with your evolving application. Manual testing is technical debt pretending to be process.

Now AI exists to test your application the way a human would: clicking, navigating, but with the speed and consistency of automation. Computer-use agents can spin up your environments, understand your application, and find bugs faster than your PM can open the PR.

For teams with dedicated QA, Ito handles the repetitive execution so your team can focus on exploratory testing, edge case design, and complex scenarios that require domain expertise. The boring clicking gets automated. The interesting work stays human.

Yet most teams are still clicking.

Our principles

• Repetitive manual testing should be invisible infrastructure, not a team activity.‍
  
  • Like CI/CD, testing should just happen. No standup discussions about “who’s testing the checkout flow.” No assigning test tasks. No checking if someone remembered to manually verify the change before merge.
• Speed and quality aren’t opposites. They’re just incompatible with manual QA.‍
  
  • Bugs in production aren’t a skill issue. They’re a coordination failure. Your best engineers still ship bugs. Not because they’re careless, but because they’re ambitiously trying to help customers. They’re moving at calculated risk. Test and deal with bugs later, or test thoroughly and miss the window. This is a false choice created by broken tooling.
• QA expertise is underutilized, not unnecessary.‍
  
  • The best QA engineers shouldn’t be clicking through login flows. They should be thinking about failure modes nobody else considered.
• Every commit should be production-ready by default.‍
  
  • Not aspirationally. Not “if we had infinite time.” Actually ready. Right now.

The future we're building

QA stops being a tax and becomes a confidence multiplier.

You ship faster. Not despite testing, but because of it. Because you trust your testing. Because the moment a PR is opened, Ito is already running: finding issues, passing feedback with screenshots and recordings.

• Your engineers stop choosing between thoroughness and speed.
• Your PM stops spending afternoons manually clicking through flows.
• Your bugs get caught before they’re in production, not after.
• Your releases happen when you’re ready to ship, not when someone finally has time to test.

Ito can handle:

• Auth flows
• Mocking external services
• Seeding data to reach specific states
• Testing applications the way humans do

But faster, more consistently, and without forgetting edge cases.

We’re not building another testing framework. We’re building the QA tool you’ve always wanted: relentlessly testing every PR, every edge case, every device, automatically so your team can ship faster with confidence.