Skip to content
Nauro

Product validation (in development)

Product validation

Nauro is building a testing service for the user flows teams still check by hand before release. It is in development: there is no app to sign in to yet, but you can request a free, founder-assisted pilot today.

On this page

Last reviewed: 22 October 2026. This page separates what you can do today from how pilots are designed to work. The design will change as the service is built.

What you can do today

Request a pilot through the form on the homepage or by email to [email protected]. Include a link to your app’s test environment and what agents may do there. Sending a request does not confirm a pilot. Nauro’s founder replies by email.

Pilots are free and founder-assisted: the founder helps when you want it. You don’t need to set up Nauro or use the decision system first.

How a pilot is designed to work

A pilot is planned in three steps. They describe the design of a service that is still being built.

  1. Send a link. You share a link to your app’s test environment and say what agents may do there. Agents are designed to map the app, pick the user flow that matters most and start testing. The design lets you name a different user flow or redirect them.
  2. Get a report. The report is designed to show what passed, what failed and what could not be checked, with evidence for each finding and steps to reproduce problems.
  3. Check the next release. After your app changes, agents are designed to repeat the checks and compare the results. When an expected behavior changes, the pilot is designed to ask you to review the new expectation before the checks change.

What you decide before agents start

  • A link alone is not permission. You choose which actions agents may take and which data they may use.
  • Test accounts and documentation are optional. They are meant to let agents cover more of the app.
  • Your existing tests stay in place. There is no need to replace Playwright, Cypress or other tests. If you share them, the pilot is designed to focus on what they leave unchecked in the user flow.

How results are designed to read

Reports are designed to follow these rules:

  • Each finding is a failure, a question for your team, or something that could not be checked.
  • When the expected behavior is an inference rather than something you confirmed, the finding is a question for you, not a bug.
  • Missing evidence never counts as a pass. A user flow passes only when every check you confirmed passes.
  • There is no readiness score. Your team decides whether to release.

The homepage example

The workspace on the homepage is a fictional example. Demo shop and its findings are written for the page: no application is connected and no test runs. It shows the intended experience, not a customer result.

Not available yet

  • Self-service access. There is no app to sign in to and nothing to install.
  • Running or scheduling checks yourself.
  • Published terms for pilot data.

Product validation and the decision system

They are separate products. The decision system keeps approved decisions available to coding agents, and it is available today. A pilot does not need it.