Proof, not promises.
Exactly how money is held, who can see what, and what happens when a job goes sideways.
From funding to payout
No job is listed until it is paid for, and nothing is paid out until the founder approves.
- Step 1
Founder funds
The budget plus the 10% platform fee is charged through Stripe before the job is ever listed.
- Step 2
Held until approval
qahuman holds the money while the tester works. Neither side can touch it mid-job.
- Step 3
Report delivered
The tester submits a structured report: severity, repro steps, devices, evidence.
- Step 4
Founder approves
You approve once the report matches the brief — after revision rounds if it does not.
- Step 5
Tester paid
Approval releases the payment. The tester receives 90%; the report stays yours.
Revisions first, disputes second
Most jobs never need an umpire — the revision loop settles them.
Report delivered
Every job reaches this point, then takes one of three paths.
Approve
The report answers the brief.
Tester paid
The held payment is released and the job closes.
Request changes
Say exactly what the report missed.
Up to 3 rounds
The tester re-runs and resubmits.
Approve or dispute
Most jobs end approved right here.
Dispute
Either side can escalate after revisions.
Admin review
A qahuman admin reads the whole record.
Resolution
Payout released, or budget refunded.
What an admin actually reads: the brief's focus areas, the workroom messages, the report content, and every revision note — then the payout is released or the budget refunded.
Who can access what
Private information stays between the founder, the one accepted tester, and — only during a dispute — an admin.
| What | Public | Assigned tester | qahuman admin |
|---|---|---|---|
| Job briefTitle, tier, budget and platform are public. The full brief and attachments are not. | Limited access | Full access | Full access |
| App credentialsEncrypted at rest, decrypted only inside the accepted tester's workroom. | No access | Full access | Limited access |
| Report contentsYours to keep. It only goes public if you publish it as a verified page. | No access | Full access | Limited access |
| MessagesWorkroom threads stay between the founder and the one accepted tester. | No access | Full access | Limited access |
| Payment detailsCards and payout accounts live with Stripe — qahuman never stores the numbers. | No access | No access | Limited access |
- Full access
- Limited — partial fields, or only while resolving a dispute
- No access
One exception, controlled entirely by the founder: an approved job can be published as a public verified page to showcase the work. Nothing else goes public.
Temporary credentials, handled properly
Test-account credentials never appear in a listing or a proposal — only in the workroom of the one accepted tester.
Credential checklist
- Use a throwaway or sandbox account
Seed a test tenant with fake data. A tester should never sign in as a real customer.
- Never share production admin
Testers need the flows named in the brief, not the keys to your business.
- Rotate or delete after the job
Change the password or bin the sandbox account once the report is in your hands.
- Encrypted at rest — AES-256-GCM
Encrypted on the server before anything reaches the database.
- Revealed only to the assigned tester
Never in the public listing, never in proposals — decrypted inside one workroom.
- Revoked on completion
The job closes and workroom access ends with it.
NDA modes
Every job picks one. When an NDA applies, the tester signs before credentials or the private brief unlock.
- NonePublic-friendly briefs
Nothing sensitive to protect? Skip the NDA and keep the job friction-free.
- StandardGenerated per job
A mutual NDA covering builds, credentials, reports, and messages — signed before access unlocks.
- CustomBring your own
Upload your company's NDA. Same rule: signed before anything private is revealed.
Inspect the proof before you commit.
Read a real report format end to end, or open a job a founder chose to publish.