Humantik: human checklist review for AI-built apps

Why this exists

AI tools build working apps fast. They also skip the parts nobody sees: who can read whose data, where the keys live, whether a payment can be skipped. Scanners catch some of it. A buyer, an investor or your first business customer wants to know that a person who understood the app checked it.

Humantik sits between you and the reviewer

Humantik is the go-between: you deal with Humantik, not with the person who checks your app.

• You pay Humantik, not the reviewer. Stripe takes the payment. Humantik pays the reviewer after delivery and holds back part of their pay until the 90-day refund window closes, so a miss costs them too.
• We find and screen the reviewer. Before their first review, every reviewer must pass a practical test and an identity check. You get their name before they get any access, and you can say no.
• The rules are published. The checklist, the refund rule and the registry are public, so neither side has to take the other's word.
• If a check was wrong, we step in. A refund claim on an item marked pass is checked by a second reviewer, and some finished reviews are checked again, blind; when two reviewers disagree, a third reviewer decides, and Humantik if the third agrees with neither.

Know how to read and test code? Reviewers are paid per review.

Apply to be a reviewer

How it works

1. Email us to order: the tier, your app's web address and the tool you built it with. We reply within one business day (Monday to Friday) with the access the review needs and a payment link. No reply in two? Send it again. Already paid with a Pay button? The same reply follows, and if the app does not fit, everything you paid is refunded.
2. Give the access listed under "What we'll need from you". Never your passwords, production keys or real users' data: the review runs on a staging copy, or on the live app in a window you agree to, with test accounts.
3. A screened reviewer checks every item your tier covers on the published checklist, attaching evidence and the steps to re-run each check.
4. You get a signed report. Signed Review and Sale & Raise Attestation also get a public registry page and a badge that links to it.

Prices

Every detail, side by side:

Business days are counted from the day we have every access we asked for; US federal holidays don't count.

Signed Review and Sale & Raise Attestation results are public: the registry page and badge show every failed item and its severity for 12 months, beside any re-check you pass. The steps and evidence stay in your private report. Launch Check results are never published.

Launch Check covers every critical item plus the main login, key, payment and unsafe-content checks. Signed Review and up add seven more: session expiry, error messages, sensitive data in logs, failed-login records, outdated dependencies, data sent to trackers, and account deletion.

Your review fee can count toward one more order within 30 days of your report: fixes by the same reviewer, or, after a Launch Check, a Signed Review or Sale & Raise Attestation of the same app. The fee counts once in all; it is never credited twice, and a fee that was credited is not also refunded. The bigger review checks the build you send then, not the old one.

Failed items can be fixed by the same reviewer at a menu price per item.

On Signed Review and Sale & Raise Attestation, if you fixed the failed items yourself, send us the updated version of your app within 30 days of the day you got your report. The reviewer tests each failed item once more, for free, within 5 business days of receiving it. The result goes on your registry page next to the original failure, whether it passes or not, so a buyer sees both. A re-check covers only that item on that version. It does not change your other results, your refund terms or your expiry date. If the reviewer fixed an item for you, a different reviewer does its re-test, so nobody marks their own work.

What we'll need from you

• A staging copy of the app, or a time you agree for testing, so nothing touches real users.
• Two ordinary test accounts and one admin test account; for team apps, two test teams.
• Read access to the code, including its history: the Read role on an organization repository, or the whole repository sent as one file. Never a collaborator invite on a personal repository, which would also let the reviewer push changes.
• Screenshots we ask for from your database, login and payment settings (for Supabase: the Security Advisor result, row-level security policies, auth rate limits, backups).
• Stripe in test mode, if the app takes payments.
• Recent log excerpts, with personal data removed, for the logging items.

Test-account passwords go through a one-time link, never in an email. Step by step, with what to take back afterwards: How to share access.

No staging copy? Say so when you order. You and the reviewer agree in writing on a testing window and test accounts that keep real users out of it. If no safe window can be agreed, you get your money back before any work starts.

Who sees your code, and what stops misuse

• One named reviewer. You get their name before they get any access, and you can say no. Besides them, only these see your materials: Humantik, which keeps one copy for refund claims; a second reviewer, if you claim a refund or your review is picked for a blind re-check; and an AI tool the reviewer uses to read code, only one whose terms say it does not keep or train on what it is given, named in your report.
• A signed agreement. Every reviewer signs ours before their first review: confidentiality, deleting your files at delivery, and, for each order, a statement that they have no stake in a product that competes with yours.
• A name at risk. Signed Review and Sale & Raise Attestation reports carry the reviewer's name in public, next to their record.
• What no agreement can do. Anyone who can read code can copy it, and your code's history holds every file it ever had: if a key was ever committed, even once, change it before you share. So share a staging copy with made-up data where you can, and only what the checklist needs; the How to share access page shows how.

What a review is not

• Not a penetration test, a security certification or a legal opinion. The reviewer runs the published checks on a staging copy or in an agreed window, with test accounts.
• Not a review of anything outside the checklist, or of any change made after the build named in the report.
• Not a fix: fixing is a separate order, at a price per item.

Your code and your data

• We ask for read access and test accounts, never your passwords or production keys.
• Your report goes to you. The public registry page and buyer summary show results, never the steps to reproduce a failure or the evidence.
• Want a mutual confidentiality agreement before you share access? Say so when you order. We sign ours, or yours once we have read it, before you send anything.
• Any test credentials you gave us are deleted within two business days of delivery.
• The reviewer deletes their working copies at delivery.
• Our copies of your code and the notes made along the way are kept for 90 days after delivery, or until any open refund claim is settled if that is later, so a second reviewer can check a claim. Then they are deleted. The delivered report, with its evidence, its fingerprint and the registry entry, if your tier has one, are kept.
• When we delete your materials, we email you the list, with a fingerprint (a short code that identifies a file exactly) for each file, so you can match it to your own copies.
• If any of your files reach someone they should not, we tell you within 72 hours of finding out.
• When the report is delivered, remove the test accounts and the repository access you gave us. For a re-check, fixes or a bigger review, you give access again.

The refund rule, in plain words

If an item on the checklist was marked pass and a second reviewer confirms it was in fact failing on the build we reviewed, the fee is refunded to whoever paid for the review. On an order paid partly with a credit, the refund is what was actually paid. Each order can be refunded once. Claims close 90 days after delivery. The rule does not cover anything outside the checklist, or any change made to the app after the reviewed build.

Cancelling an order

• Before the review starts, which is the day we have every access we asked for: cancel by email and everything you paid is refunded.
• If we are late: if the report has not arrived 5 business days after its due date, you can cancel and everything you paid is refunded, even if work has started.
• Once the review has started, the fee is not refunded on request; the refund rule above still applies to the delivered report.
• Refunds go back to the card or account you paid with. Stripe usually shows them within 5 to 10 business days.

Why pay when scanners are free or cheap?

Run one first. On Supabase we ask for the Security Advisor result when you order, and a scanner run against your live app is worth a few dollars. Some scanners even give you a badge.

A scanner reads settings and probes your app from the outside. A person checks what that can't tell you:

• whether your access rules behave the way your app intends, using real test accounts for two users and an admin;
• whether a payment can be skipped or a price edited;
• whether logging out really ends a session;
• what your settings screens and code show about backups, logs and keys.

Every finding comes with evidence, steps to re-run it, and the reviewer's name. If an item marked pass was failing, and a second reviewer confirms it within 90 days, you get your fee back. One refund per order. Each checklist item also says plainly what a pass does not show.

Selling or raising?

Buyers on Acquire.com build a due-diligence task list for each deal. A Sale & Raise Attestation gives you a registry link and a one-line task you can paste straight into it. A buyer can also order the review of a listed app, as long as the seller grants the access above and signs the testing agreement, since only the app's owner can permit testing on it. The registry page shows which build was reviewed (its git commit, where the code is in git); ask the seller to show you the same id in the repository. Every change to the registry is kept in a public history that anyone can check.

Questions

Who runs Humantik? Humantik is a new business based in Darby, Pennsylvania, USA. Write to us through Order a review (it opens an email); a person answers. The reviewer who signs your report is named in it.

Why is the registry empty? Because Humantik is new. Entries appear as reviews are delivered, and none are invented. Until then, judge the work by the checklist, version 1.0 and the refund rule above.

Which apps can you review? Web apps, whatever tool built them. Most checks are written for Supabase and Stripe, the usual setup for these tools; on other setups the reviewer runs the same check against your equivalent setting. A native mobile app is not reviewed.

Is a person really doing the review? Yes. Before their first review, each reviewer's identity is checked on a video call. They run the checks by hand from the test accounts named in the report, so every request shows up in your own logs, and the report says when testing happened. Reviewers may use AI tools to read code faster; the report lists any that were used, and the reviewer ran and answers for every result.

I don't code. Will I understand the report? The report opens with what failed, worst first: each failed check in plain words and how serious it is, so you know what to fix first. Signed Review and up include a 20-minute call in which the reviewer walks you through it. We don't tell you whether to rebuild; we report on the checklist.

What if the reviewer finds something serious mid-review? If a critical item fails, for example one user can read another user's data, we tell you within one business day, before the report, so you can plan the fix. Fix it after testing ends, so the report matches the build that was reviewed.

My app calls an AI model. Is that covered? Partly. The reviewer checks the browser code the app loads, and the code's history, for secret keys such as an AI provider's, and that any key that leaked was replaced. Checklist version 1.0 does not test prompt injection or spending limits on AI calls; set a monthly spending cap with your AI provider.

Will an investor, buyer or business customer accept this? We can't promise that. The report shows what was checked and how, with evidence and a named reviewer, and the checklist is public so they can judge it. If someone asks for a penetration test by name, this is not one.

What if my app fails items? Your report lists each failure, with the steps to reproduce it and how serious it is. Fix them yourself (Signed Review and up include a free re-check), or order the fixes. Launch Check results stay private.

What does the badge prove? That this build of this app was reviewed on the date shown, with the results on its registry page. It does not cover later changes, and it shows as expired after 12 months.

Can I order for an app I'm buying? Yes, if the seller gives the access listed above. Choose Sale & Raise Attestation if you want the buyer summary.

The checklist is free

All 30 items, why each matters, how it is checked and the public source behind it: checklist, version 1.0. Use it yourself; we'd rather you fix things before you pay anyone.