How to share access for a review

The short version

Share the least you can, for the shortest time, and take it back when the report arrives. We never ask for your passwords, your production keys or your real users' data. Every step below is something you do in your own accounts; you can stop at any point.

Before you share anything

• Ask for a mutual confidentiality agreement if you want one. Say so when you order: we sign ours, or yours once we have read it, before you send anything.
• We tell you the reviewer's name before they get any access. The reviewer has signed our reviewer agreement, which covers confidentiality and deleting your files, and states for your order that they have no stake in a competing product.
• Read access lets a person copy what they can read. That is true of any reviewer, anywhere, so share a staging copy with made-up data where you can, and only what the checklist needs.
• Your code's history holds every file it ever had. If a key or a .env file was ever committed, even once and later deleted, change that key before you share.
• A reviewer may use an AI tool to read code, but only one whose terms say it does not keep or train on what it is given. Your report names it.

Your code

• Your repository is in a GitHub organization: add the reviewer with the Read role on that one repository.
• Your repository is on a personal account: do not add the reviewer as a collaborator, because on a personal repository that also lets them push changes. Send a single file of the repository instead: in a terminal, in your project folder, run git bundle create app.bundle --all, and send app.bundle the way you send the archive described under "Sending files". Never used a terminal? Ask when you order and we explain it step by step by email, or use the zip route below.
• No git at all (some builder tools keep the code for you): export the project as a zip from your tool and say so when you order.

Logins and secrets

• Make test accounts for the review: two ordinary users and one admin, plus two test teams if your app has teams. Never send the login of a real person.
• Send test-account passwords through a one-time link, such as Bitwarden Send (needs a free Bitwarden account) or Password Pusher. Set it to open once and expire within a few days. Never put a password in the email itself.
• Never send your Supabase service role key, your database password, your Stripe secret key or any other production key. The checklist never needs them.

Database, login and payment settings

• Supabase: screenshots of the Security Advisor result, the auth rate limits and the backups page (free plans have none; say so), plus the text the SQL editor shows when you run select * from pg_policies; (your row-level security rules) and select tablename, rowsecurity from pg_tables where schemaname = 'public'; (which tables have those rules switched on at all). Neither shows your users' data, though a rule can mention an email address; blank it out if you like.
• Stripe: screenshots from test mode only. The reviewer pays with Stripe's test cards and never sees a real card or a real customer. Test cards only work on a copy of the app that uses Stripe's test mode; if you have no such copy, we tell you before you pay which payment checks cannot be run.
• Other setups: screenshots of the equivalent settings; the reviewer will name each one.
• Hosting: tell us your host and plan when you order. Some free plans block automated requests or limit the logs the review needs; if yours does, we say so before you pay.

Sending files

Put the files in one 7-Zip archive with a password (on Windows, in 7-Zip choose the 7z format, the AES-256 method and "Encrypt file names"; on a Mac, the free Keka app makes the same kind of archive), email the archive, and send the password through a one-time link as above. If the archive is too big to email, ask and we suggest another way. The delivered report comes back to you the same way.

Testing on a live app

If there is no staging copy, you and the reviewer agree in writing on a testing window and the test accounts it uses. If you are selling and the buyer ordered the review, you, the owner of the app, sign that agreement, because you are the one who can permit testing on it. If no safe window can be agreed, the fee is refunded before any work starts.

When the report arrives

1. Remove the reviewer from your repository, if you added them.
2. Delete the test accounts, or change their passwords.
3. Expire any one-time links that were not opened.
4. If you made a staging copy only for the review, delete it.

We then email you the list of what we deleted on our side, with a fingerprint (a short code that identifies a file exactly) for each file of yours that we held, so you can match it to your own copies. The reviewer deletes their working copies at delivery. We keep one copy 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 we delete it.

If something goes wrong

If any of your files reach someone they should not, we tell you within 72 hours of finding out: what was involved, when, and what we have done about it.

Order a review See the checklist