Quakby Ambient Intent
XR TESTING, WITH RECEIPTS PAID ALPHA

Good interactions.
On repeat.

Your next feature shouldn’t break your last. Meet Quak, your XR bug catcher.

Quak duck-foot logo
QUAK / BUILT TO CATCH BUGS.
BUILT FOR SPATIAL SOFTWAREUnityOpenXRMeta QuestDevelopment builds · See requirements ↓

Keep shipping.
Keep checking.

Turn the engineer’s understanding of a feature into repeatable tests, then give the whole team evidence they can review.

01

Even great teams miss things.

A feature can reach thousands of users while earlier flows go unchecked. Engineers move to the next priority, and QA needs context about what to test and what should happen. Even the most careful person can miss a step. Quak captures that knowledge in explicit tests the team can run again.

SHARED KNOWLEDGE
02

Real devices close the gap.

Installing builds, putting on a headset and repeating every journey takes time. It is tempting to rely on quicker simulator checks or skip the device pass, leaving regressions to surface later as costly investigation and rework. Quak runs repeatable interactions on Quest and checks the app’s response. Performance experiments can compare changes using metrics exposed by the app and runtime on the device.

REAL DEVICE TESTING

A pressed grip
isn’t proof of a grab.

Quak connects the build you’re testing, the interaction you make, and the outcome your app reports. Start with an engineer and their coding agent; keep the test and its evidence open to the whole team.

01

Describe the intent. Make it testable.

An engineer briefs their coding agent on the exact journey, expected outcomes and invalid interactions. The bundled Quak skill guides the agent through the project’s code to write the test and the app-state checks it needs. The team reviews those rules, including a failing case, before trusting a pass.

AGENT-ASSISTED AUTHORING
02

Run the interaction. Check the effect.

Bind the exact app, device, and test. Run repeatable interactions through OpenXR input, then assert independent application state: was the object grabbed, or an invalid action rejected? A command being accepted is not proof that the interaction worked.

BUILD · INPUT · APP STATE
03

Every protected test adds lasting value.

Test today’s feature, then add the reviewed test to a known-good regression baseline. Run that suite locally or in CI as you work on the next feature. Quak flags failures, invalid tests, and protected tests that change or disappear. Coverage grows with the journeys you add, keeping earlier work checked long after your attention has moved on.

PROTECTED REGRESSIONS
04

Review the evidence. Close the loop.

Managers and QA can inspect results and recordings, mark timestamps, and note what happened versus what was expected. Share those change requests with an engineer or pass the review and run evidence to their agent. The fix is rerun with a link to the earlier result, ready for another review.

REVIEW AND RERUN

03 / A CLEARER ANSWER

“It worked.”
Show your working.

Input delivery, product behavior, and visual evidence answer different questions. Quak keeps them distinct, so a green check means what you think it means.

Request documentation ↗
EXAMPLE / GRAB INTERACTION
InputGrip delivered
ProductObject held
EvidenceHuman review pending

Illustrative result · Visual approval stays with a person.

Repeatable coverage.
Human judgment.

Quak checks the journeys and outcomes your team defines; it cannot guarantee every regression is caught or replace exploratory QA and human visual review. Currently in paid alpha for Unity and OpenXR, with real-device testing on supported Quest development builds. Editor and simulator workflows remain useful alongside device validation. Tell us what you’re building and the interactions you need to protect.

Talk about early access

Private releases. Access and setup coordinated with your team.

Duck model: Cute little Duck by TadenStar · CC BY 4.0 · Adapted with rigging and animation.