You paid a developer, or built it yourself with an AI builder. I read the code and show what really happens when a customer clicks the button.
Check my projectFree for the first ten. I answer myself, usually the same day.
The order is saved to the database, but nobody checks whether it saved. If the database refuses, the customer still gets charged and the order does not exist.
api/checkout/route.ts:30
The work is handed over. You click through it, and it works.
Sign-up works. The cart works. Payment goes through, the card is charged, the thank-you page appears. You pay the invoice and launch.
Five weeks later a customer writes: I paid, where is my order?
You look in the admin panel. The order is not there. The money left the card, Stripe confirms it, and the record does not exist. You have no idea how many others there were, because nobody complained.
This is what was in the code the whole time.
The order is written to the database, and nobody looks at whether it saved. The Supabase client does not throw when a write fails, it returns the error in the response. Nothing reads that response, so the code carries on and charges the card.
Nothing about this is visible from the app.
It only happens when the database refuses: a timeout, a full disk, a rule that changed. On a good day everything works, which is exactly why it survived to launch and past your acceptance.
It is visible in the code, if you read the whole path.
Button, request, server, database, Stripe: written out step by step, with the one place where the chain breaks marked. In this project 9 of 10 database calls check the result. The tenth is the one on the payment path.
That is the whole idea
I read the code of a project handed to you, trace every path a customer can take, and tell you in plain words where it breaks. Free for the first ten, by hand, usually the same day.
Check my projectThe same demo shop, all of it: every path a customer can take, grouped by the questions you would actually ask.
And one more finding from the same run
In 16 of 17 endpoints this project checks who is asking. In one it does not: anyone who knows the address can read someone else's order.
src/app/api/orders/[id]/route.ts:5
This shop has 18 paths. A real project usually has between 100 and 300, and the report has the same shape: questions first, then the paths under them, then each path in full.
This is what you receive: a plain-language verdict first, then each finding with the exact file and line. Open it before sending anything.
Open the example reportYou send a link
A public repository link is enough. If it is private, there are two other ways below.
I run the tool and read the result myself
The engine traces every path a customer can take. I check each finding against the source by hand, because a tool alone gets it wrong often enough to matter.
You get a private link to your report
Same day, usually. The report names files and lines, so you can hand it to your developer as it is.
Every path a customer can take, drawn out
Sign-up, payment, deletion, letters that go out, data that leaves for other services. For each one: what was clicked, where the request went, what the server did, whether it reached the database, what happens when it fails.
The places where the path breaks
Data written without checking it arrived. A failure with no branch to handle it. A record fetched by id with nobody checking it belongs to this user. Keys sitting in published code. Each finding names the file and the line, so your developer cannot argue with it.
I read the code, I do not run the app. So I will not tell you "the button works" or "the page looks right", and there will be no overall "your project is fine" verdict either: silence where the tool is blind is more honest than a green checkmark. What I do tell you is exact, with file and line.
One: you hired someone, they said it is done, and you have no way to tell. Two: you built it yourself with an AI builder, things keep breaking, and you want to know what state it is in before you launch. Either way the project runs on Supabase and I can see the code. I run the check by hand and answer myself, so the first ten are free.
If the repository is public, there is nothing to hand over: it is already readable by everyone, including the bots that scan GitHub for keys around the clock. If it is private, you do not have to send it at all, see the two options below. And if the project belongs to your developer rather than to you, ask them for read access or for the migrations folder: that is a normal request and they will understand it.
Public repository: send the link, nothing else
I clone it, read the migrations and the source, and delete the clone when the report is written. No account access, no invite, no permissions.
Private repository: send only the migrations
The folder `supabase/migrations` is enough for most of what I find. It holds table and policy definitions, not your business logic, and it is the part where these problems live.
Nothing leaves your machine: run one query yourself
Open the Supabase SQL editor, run the query below, and send me what it returns. It lists policy names and table names, no code at all. I will tell you which rows matter and how to fix them.
SELECT tablename, policyname, cmd, roles, qual, with_check
FROM pg_policies
WHERE schemaname = 'public' AND cmd <> 'SELECT'
AND (qual = 'true' OR with_check = 'true');The tool is called plumbline. Author: nzt108, hello@nzt108.dev