Straight answers. From how it works to what's next.

TaloTrace is autonomous software quality. It explores real user journeys across your web and mobile apps, finds bugs and unexpected behaviour, and hands your team a Trace: the recording, reproduction steps and evidence behind every finding.

Code tells you what you built. TaloTrace tells you what actually happened.

You give TaloTrace your app and whatever product context you have, such as specs, release notes or Confluence pages. It learns how the product is meant to behave, explores the running app, drives the journeys that matter to a verified outcome, and reports what it found. Every finding is independently reviewed before it reaches you.

That is the first part of a longer loop: Find, Understand, Fix, Prove. All four are in development, starting with finding and evidencing issues, and are labelled as such throughout this page.

Scripted automation replays steps someone wrote in advance, tied to element IDs and selectors that break when the UI changes. Every release brings more scripts to write and fix.

TaloTrace has no scripts to maintain. It navigates by looking at the screen, works out the steps from what you want tested, and checks whether the outcome actually happened rather than whether a click fired.

Many AI testing tools let the same AI that finds an issue also decide whether it is real. TaloTrace separates the two: findings are reviewed independently before you see them, and a goal only counts as reached when a check proves it.

The aim is not more findings. It is findings your engineers can trust, with the evidence attached. AI proposes. TaloTrace proves.

Product and engineering teams who want better software quality without scaling manual QA: engineering teams reducing regression risk, QA teams who want broader coverage, product teams who need confidence before a release, and startups with no dedicated QA at all.

It works whether you have a QA organisation or nobody in that role yet.

No, and no testing tool should claim to replace human judgement. TaloTrace takes on the repetitive, time-consuming, large-scale checking so your QA engineers and developers can spend their time on exploratory testing, usability and product decisions.

Most teams treat it as a force multiplier, not a replacement.

Yes. TaloTrace has multilingual support: English and Vietnamese are supported today, in the product and on this website, with more languages on the way. The in-app feedback widget follows whichever language you are using.

Anything that describes how your product should behave: PRDs, release notes, user stories, acceptance criteria and internal docs. Upload PDF, Word, Markdown or plain-text files, connect Confluence, or import from Jira or Linear. Re-importing refreshes documents in place, and you can view, update or delete them at any time.

TaloTrace uses this context to understand features, rules and expected outcomes, so it can judge whether a journey achieved what it was meant to, not just whether a button responded. The more context it has, the better its judgement.

You can also connect product analytics such as Mixpanel, Google Analytics 4 or Google Tag Manager. This is used as extra context about where real users struggle, to help decide what is worth testing.

No. Point TaloTrace at your app and, if you want to steer it, describe the flow you care about in plain language, for example 'create a project'. TaloTrace explores the app, works out the steps, drives the journey and turns each completed journey into a replayable scenario in your Test Plan.

Scenarios can also come from a chat with Nico, or be written by hand.

Web apps in a browser, Android apps on a cloud Android emulator, and iOS apps on a cloud iOS Simulator. TaloTrace picks the right one from your app's platform. Physical devices are not part of it today.

You can run several device or OS configurations in one submission.

Most journeys a real user takes in a single session: sign-up and onboarding, sign-in, checkout, profile and settings changes, content creation and feature-specific flows, including logged-in and role-based areas. It taps, types, scrolls, swipes, drags and long-presses like a user would.

TaloTrace commits real actions such as create, save and submit. Destructive or irreversible actions, like deleting an account or making a payment, are held back.

Journeys that depend on account state across sessions, such as trial expiry, renewals or account ageing, are not supported today.

Outcomes. A flow can technically complete and still fail its purpose: a checkout that reaches the payment page but never confirms the order, or an upgrade flow that never activates the plan.

Because TaloTrace understands what each journey is for, it checks whether that intended result actually happened. That is how it surfaces issues a pass/fail script would miss.

TaloTrace navigates by looking at the screen rather than relying on brittle element IDs, so renames, restyles and layout changes usually do not break it. New documentation and features feed into future runs, so coverage grows with the product instead of becoming a maintenance burden.

No. When you ship a release, a re-scan proposes scenario changes for your review. Nothing in your Test Plan changes without your approval.

Re-scans are included at no extra cost and do not use credits.

Camera-based scanning, including boarding passes, QR codes and barcodes, is in development. When it launches, TaloTrace will tell you upfront whether a flow can run on cloud devices or needs a real one.

API testing is in development.

A Trace is TaloTrace's evidence-backed record of what happened during a run. Instead of a red or green result, it shows what the journey did, where it went wrong and the proof behind each finding, so your team can move from discovery to diagnosis without reproducing the bug first.

Each finding comes with a screen recording, step-by-step reproduction, expected and actual results, a severity rating, TaloTrace's reasoning and an AI summary of the likely cause. An evidence panel shows every step it took.

The recording itself is also analysed, so visual problems like broken layouts can surface even when nothing hard-fails.

Every finding gets one of five levels, Critical, High, Medium, Low or Trivial, shown as P0 to P4 by default. Critical means the system is unavailable. High means a core journey is impossible. Medium means a feature works incorrectly. Low means the experience is degraded. Trivial is cosmetic.

You can supply your own triage guidance and labels, during onboarding or later in settings, and TaloTrace rates findings against it.

From what TaloTrace actually did. It records every action during the run and turns that sequence into clear, human-readable steps. Because they come from observed actions rather than someone's memory, they tend to be more complete than a typical bug report.

Yes. Every completed journey becomes a scenario in your Test Plan that you can rerun on demand or on a schedule, and every run keeps its recording so you can watch exactly what happened.

Repeated observations of the same defect collapse into a single issue. If a failure repeats across runs, the existing ticket is updated rather than a new one being filed.

The part of TaloTrace that finds a possible issue is not the part that decides whether it is real. Every finding is reviewed independently, against expected behaviour and the evidence, before it is reported.

Results start hidden and only become visible once a reviewer approves them, or once you set a project to auto-approve. Low-confidence findings always need an individual decision before they are released.

It needs proof. A goal only counts as done when a machine-checkable condition was false before the action and true after it. A screen that already showed 'Projects' cannot pass a 'create project' goal by accident.

If TaloTrace cannot prove a goal was reached, that goal fails. It is never reported as a pass.

Through independent review, proof of completion, and filing bugs only with video evidence and reproduction steps. Duplicates are detected so the same issue does not flood your tracker.

If something still turns out to be a false positive, flag it in one click. Our team helps clean up the affected tickets, and your feedback helps stop the same mistake happening again.

Always. You should never have to trust a black-box verdict. Every finding links to its recording, reproduction steps and reasoning, so you can check the conclusion for yourself.

Accuracy depends on the product context you provide and the complexity of the journey. Rather than ask you to trust an AI's opinion, TaloTrace combines independent review and proof of completion, and gives you the evidence to verify each finding yourself.

Yes. Approved findings can be exported to Jira or Linear with the recording, reproduction steps, severity and context attached, so engineers can go straight from finding to fixing. Export is off by default and opted into per project, so nothing reaches your backlog until you decide it should.

Jira and Linear can also be connected as sources of product context. If you rely on another tracker, tell us.

On demand, from the app or through the API, or automatically on a daily or weekly schedule with a timezone picker. Nobody needs to kick off scheduled runs by hand.

Not today. There is no pull-request trigger, so a scheduled run tests whatever build you shipped most recently rather than a specific commit.

It fits alongside it. Teams use TaloTrace for release validation and regression checks, started on demand, through the API or on a schedule, without changing how they build and ship. Deeper hooks such as pull-request triggers and MCP access are not live yet.

No. Findings arrive in tools your team already uses, with the evidence attached. There is no scripting framework to learn.

Usually soon after you share your app, your product docs and what you want tested. With no scripts to write, onboarding is much faster than a traditional automation project. Exact timing depends on how complex your product is.

In development. Playwright, Cypress, Appium and Maestro scripts will be converted into TaloTrace scenarios that keep their intent and assertions. Your original scripts stay untouched.

In development. A scoped credential that will let your own AI tools or CI drive TaloTrace: trigger runs and fetch results. It can be disabled at any time and appears in audit logs.

QA is where we start, not where we stop. The loop we are building is Find, Understand, Fix, Prove: find what broke in real journeys, understand why, propose a fix, then prove the fix works by running the journey again.

Find, Understand, Fix and Prove are all in development. Find comes first.

Partly. Every finding includes an AI summary of the likely cause, built from the recording, the steps taken and the gap between expected and actual results. It is a starting point for diagnosis, not a full root-cause analysis.

That is in development. When enough context is available, it will investigate the events leading up to a failure, such as user actions, application behaviour and state changes, and narrow down where and why it happened.

In development. With access to your source code, TaloTrace will point to the components or code paths most likely involved, so engineers review less code to find the problem.

In development. TaloTrace will understand your codebase, including its conventions, patterns and architecture, and propose the patch your team would naturally write, like a properly onboarded teammate. Your engineers decide what, if anything, gets implemented.

In development. TaloTrace will not merge a fix into production to find out. It will test each fix independently in an isolated environment, rerunning the failed journey and nearby regression checks, and only then hand your team a reviewable pull request with an easy-to-follow record of what was checked.

Until then, you can rerun any scenario yourself to confirm a fix.

Only for the code-aware capabilities, once they are available. They will work best with read-only, narrowly scoped access to a repository, and will also run in a logs-only mode with less depth. Access will be per repository and revocable at any time.

Testing today does not need your source code.

Yes, always. TaloTrace will propose and prove. It will not merge anything on its own. Every change stays a decision for your team.

You save the test accounts TaloTrace should use, each with a role label such as admin or viewer. Sign-in is email and password, with optional free-text instructions for extra steps like an OTP prompt. There is no password-less or SSO-only sign-in path today.

Saved passwords are write-only and encrypted at rest. They are never sent back out, and they are masked in run steps and logs. You can edit or delete saved accounts yourself.

No. Payment journeys only ever run in payment vendors' sandbox or test environments, such as those from Stripe, Adyen, Braintree or Checkout.com. No real transaction is performed.

Destructive or irreversible actions, like deleting an account, are held back. You can also set boundaries. A journey that would cross one is recorded as blocked, with a note on what it would take to test safely.

Only what is needed to run your tests: recordings, screenshots, run steps, findings, the documents you provide and your configuration. Your documents can be viewed, updated or deleted at any time.

On Google Cloud, with retention that varies by plan. Singapore data residency is available on enterprise agreements, and a data-processing agreement (DPA) is available on request.

Our own employees, under confidentiality and access controls, review recordings of your test environment only. This is disclosed in our data-processing terms.

Not yet. We complete vendor security questionnaires and architecture reviews for every enterprise engagement today. An independent penetration test and SOC 2 certification are on our roadmap, with committed dates shared during procurement.

For organisations with specific security, compliance or capacity needs, dedicated infrastructure or more isolated setups may be available. Talk to us about your requirements and we will work out the right fit.