Package the testing mission
The submission flow carries the app URL, setup steps, task checklist and test data into a shared hub. Typed contracts keep the command, API and tester interface aligned.
QA.ninja
Make human testing part of the development loop, with enough context for the next person to act.
The problem
A URL alone is a poor testing brief. Testers need instructions and safe data, while developers need reproducible evidence rather than a message saying that something broke.
My part
Product and engineering work on the QA.ninja prototype. The public demonstration includes seeded apps and findings.
What this shows
I can design the handoffs around an AI-assisted workflow, so that human observations become clear, reviewable engineering work.
Where it started
QA.ninja explores the handoff between fast app development and human testing. The working prototype includes a testing hub, submission tooling, tester interfaces and an optional findings-to-fix workflow.
Interface preview
The decisions behind the product
Make findings actionable
Reports include severity, steps, expected behavior and actual behavior. Screenshots, videos and diagnostic attachments preserve the evidence needed to reproduce a problem.
Connect feedback to the next development step
A watcher detects new findings and can optionally hand them to a coding-agent fixer. A desktop interface brings jobs, findings and watcher state together; deployment requires its own explicit option.
What came out of the work
A demonstrable end-to-end prototype
The live hub serves real application listings and finding records. Seeded sample apps make the workflow available to inspect without claiming they are acquired customers.
A stronger handoff between people and tools
The product preserves the testing brief, reproduction evidence and repair context across the workflow. Real tester adoption, resolution rates and time saved still need measurement.
- One loopfrom an app submission to findings and a reviewable fixImplemented prototype · checked 9 Oct 2026
- Evidencescreenshots, video, console and network attachmentsFinding attachments · source-verified 9 Oct 2026
Inside the implementation
Explore the features, architecture and quality checks
What I built
- A submission command that packages an app URL, setup instructions, test data and a task checklist
- A public testing hub and an Expo tester interface using a shared validated contract
- Structured findings with severity, reproduction steps, expected and actual behavior, and evidence attachments
- Testing rounds with email dispatch and recorded delivery outcomes
- A findings watcher with an optional coding-agent repair flow; deployment is separately opt-in
- A Tauri desktop interface for jobs, findings and watcher controls
How it works
- Ship a testable briefThe developer submits the URL, context, tasks and safe test data.
- Try the productA tester follows the mission and works through the real interface.
- Report with evidenceStructured steps and attachments make a finding reproducible.
- Review a fixThe watcher can pass a new finding to a coding agent; applying fixes and deployment remain explicit options.
Quality and reliability
- Submission and finding inputs are validated; related submission records are persisted transactionally
- Attachment types and sizes are validated before storage
- Public sample apps include deliberately planted bugs; their listings and findings are not adoption metrics
- Email delivery is implemented; other notification adapters remain gated stubs in this prototype
Technology
Explore another problem I worked on
- UnholdExplored an AI hotline assistant through a landing page and scripted call demo before building the calling system.
- MeshExplored phone-to-phone messaging without mobile internet through a one-day native networking prototype.
- Lifecycle TrackerDesigned a workspace that organizes product decisions, evidence and next steps around the stage each product has reached.