Autosana: Catch Bugs Before Your Users Do

A finished feature still needs a user

A login change can work in isolation and still fail when someone follows a magic link. A checkout can pass its unit tests and break when a customer returns from another app.

Shipping the code leaves another job: checking that the whole journey works.

Autosana runs those journeys with AI agents across iOS, Android and web. Teams describe the flow in natural language, and the agent operates the application through its visual interface. [1][2]

The test follows what a user is trying to do. It can adapt to interface changes while the underlying journey stays intact. [1]

Authentication, across apps and devices

Autosana covers OTP and magic-link flows, multi-device journeys and vision-based tests that adapt to UI changes. Authentication and cross-device interactions become part of the test itself. [3]

Autosana’s agents can use email and phone numbers to exercise authentication. A test can request a code or link and continue through onboarding, instead of stopping at the authentication screen. [2][3]

Multi-device tests cover interactions that cannot happen entirely on one screen. One device can create a link; another can open it and verify the next step. [2][3]

Teams can also use hooks to prepare the account or backend state a test needs. That setup becomes part of a repeatable user journey. [2][4]

Ziina: regression work runs before the day starts

Ziina’s mobile developers rotated responsibility for release testing. A full manual regression cycle took about 12 hours of active effort across two business days. [4]

Autosana now runs the regression suite overnight. Four critical smoke tests also run on each pull request, while engineers review results and investigate failures. [4]

Ziina reduced active manual testing to approximately one hour. The automated regression run takes one hour and 20 minutes, including the build, and 69% of its E2E suite is automated. [4]

The remaining work includes flows involving physical hardware. Ziina’s next coverage target is 80%, with hands-on verification retained where the product needs it. [4]

Gobi: product people can write the test

At Gobi Maps, CTO Tyler Becks wanted tests to operate the app the way a person would. Maintaining tests around changing labels and element IDs had become a separate engineering job. [5]

During an Autosana test, the agent found a needed element by scrolling a bottom sheet. The team had previously spent most of a day trying to script that interaction. [5]

Gobi’s product lead then mapped roughly 250 user flows in a spreadsheet. Product priorities guided what needed coverage, and natural-language instructions made test authoring accessible beyond engineering. [5]

Engineers still prepare the infrastructure and test environment. The people closest to the user can define the journeys to verify. [5]

Built to close the loop with coding agents

Yuvan Sundrani and Jason Steinberg founded Autosana in 2025 and joined YC’s Summer 2025 batch. Both had worked on early-stage products; Steinberg’s background includes founding teams at mobile-first startups. [6]

Autosana now works locally through its CLI and MCP, as well as in cloud test runs. A coding agent can run a flow, inspect a failure and check its fix before opening a pull request. [1][6]

In pull requests, Autosana runs tests against the changed build and returns results with video. The team is building validation into the same loop where software is written. [1][6]

The bigger picture

Faster development creates more changes to verify. Teams need to know whether a person can still finish the task the application was built for.

Autosana brings that user journey into local development and release checks, from a login code to an interaction on another device. [1][3]

The aim is simple: catch the bug before the user does.