auditmyapp

Launch readiness review

What your app actually does, written down, so your lawyer is not guessing.

Last updated 2 October 2026.

Before an app takes real users, a handful of things are expected of it: that someone can leave, that an unsubscribe link works, that tracking doesn't start before anyone agreed to it, that what the privacy policy claims matches what the code does. None of these produce an error when they are missing. The app works perfectly without any of them.

What this is, and what it is not

I am not a lawyer, and this is not legal advice. I don't tell you which rules apply to your business or what you would be fined. What I do is test whether the mechanisms exist and actually work, and write down what I found, with evidence. Your lawyer then has facts to work from rather than guesses.

The distinction matters because almost everything in this area is sold the other way round. A checklist can tell you that account deletion is expected of you. Only a test can tell you that your delete button signs the user out and leaves every row in place.

What I check

  1. Account deletion. I create an account, use it, delete it, then look in the database and storage for what survived. Here is that test in full.
  2. Data export. Whether a user can get their data out at all, and whether what comes out is complete.
  3. Unsubscribe. Whether the link works, whether a later send to that address is actually suppressed, and whether your emails carry the sender identification and postal address that bulk email rules require.
  4. Tracking and consent. Which scripts load before anyone clicks anything, whether session replay is recording form fields, and whether a consent choice is stored and can be withdrawn.
  5. Age collection. If your app could plausibly attract minors, whether an age check exists and is enforced on the server rather than only in the interface.
  6. Subscription terms. Whether the renewal interval and cancellation method are shown at the point of payment, and whether cancelling is as easy as subscribing.
  7. Policy against reality. I list the third-party services your app actually sends data to, taken from live network traffic, and compare that with what your privacy policy says.
  8. User uploads. If people can upload content, whether there is a route to report and take down someone else's work.
  9. Leakage. Personal data or secrets in the client bundle, in URLs, or in browser console logs.
  10. Evidence of the above. Every finding comes with the screenshot, query result or request log that demonstrates it.

What you get

A written report, ordered by severity, separating three things: what is missing, what exists but does not work, and what only you or your lawyer can decide. The same format as my security reports, and the first pass is free and comes back within 48 hours.

Why a prompt is not enough

There are good prompts circulating that ask an AI tool to audit a codebase for this and fix what it finds. They are genuinely useful, and if you have run one, you are ahead of most people. They also share one blind spot: they read what the code says, then report what they changed, and nothing checks whether it is true.

An assistant can add an age gate, and not notice it is enforced only in the interface. It can add an unsubscribe link without confirming the next send is suppressed. It can add a consent banner while the analytics script still loads on page load. It can add a delete button that signs the user out. Every one of those reports back as done.

Verification is the whole job. If you have already run a prompt like that, the most useful thing I can do is check what it actually changed.

Cost

The first pass is free: send me the app and you get a written report within 48 hours. A full review is typically $400 to $800 depending on how many flows there are, quoted after the first pass so the number cannot move on you. Most people have this done alongside a security audit, since both are testing the same running app.