Prove it to your client, not just to yourself
You built their app in a week. It works, it looks good, and the invoice is ready to go. Somewhere in the client’s head is a question they may not even ask out loud: is this thing safe?
Right now the only answer most freelancers can give is “yes, I checked.” Which is not an answer. It’s the person who built it vouching for the thing they built, and everyone in the conversation knows it.
The fix is boring and it’s the same one every other industry uses: hand over a check that didn’t come from you.
What you actually hand over
A dated report on the live app, written for someone who can’t read code. It carries the URL that was checked, the date it was checked, and every issue in plain English — and it prints straight to PDF, so it goes in the handoff email next to the invoice.
- The app URL and the date, on the document — an undated report isn't evidence of anything.
- Every finding in plain language. Not "BOLA on /users" — "anyone can currently read every user's email address".
- The exact fix for each one, so anything it finds is something you can close before you send it.
- A short account of what Assay did and didn't keep. Your client's data is not stored, and the report says so in writing.
The part your client can check themselves
A report you hand over is still a report youhanded over. So the mark isn’t an image you paste into a document — it’s a link, and it re-checks itself.
Your client can open it without trusting you, or us. It shows the current standing of the live app, not the day you ran the scan.
Which means it can go against you, and that’s the point. If the app stops passing after handoff, the mark revokes itself in public and nobody — not you, not Assay — can hold it open. A mark that can only ever say yes isn’t evidence of anything.
It never publishes what’s wrong, though. A public page listing a live app’s weaknesses would be a gift to an attacker, so the detail goes to whoever owns the app and nowhere else.
The obvious objections
- Why not just use the platform's own scanner?
- Because your client is not going to accept it, and they're right not to. Lovable checking a Lovable app is the builder grading its own work — the same system that made every decision is the one deciding those decisions were safe. That's fine as a first pass for you. It is not proof for someone else.
- Why not Snyk, or a real audit?
- If the budget is there, get the audit — it's a person, with time, actively trying to break the specific app, and nothing automated replaces that. Assay is for the far more common case: a four-figure project where a full audit costs more than the build did, and the honest alternative is currently nothing at all.
- I already checked it myself.
- You did, and you're the maker. That's the whole argument on the rest of this site — it applies to you exactly as much as it applies to the AI. You're not going to find the thing you didn't think of, because you didn't think of it.
Scanning an app you built for someone else
Assay only runs against apps you own or are authorised to test, and you confirm that before a scan starts. Building the app under contract is exactly that authorisation — but if you’ve already handed over the keys and the relationship is finished, ask them first. It takes one message and it keeps you on the right side of a line that matters.
Everything Assay checks is what any visitor to the app can already reach. It never logs in, never changes anything, and never keeps your client’s data. What it doesn’t check is written down too — worth reading before you put it in front of a client, so you never promise more than it does.
Free for your first app, no account needed for a first verdict. Run it on the next project you’re about to hand over and see what comes back.