Somebody sends me a repo with the message "it's 90% done, I just need it deployed". I used to start by reading the feature list. I stopped, because the feature list is the part that works in the demo. The things that decide whether this app can take a real card, from a real user, without a human watching, are always in the same six places.

Here is the twenty-minute pass, in order, and what each finding costs in days.

1. The key that is in the browser bundle

Open the deployed page, press view-source, search for sk-, service_role, AIza. Half the Cursor and Lovable apps I see ship an API key to the client, because the key was convenient in the file where the call was written and the framework happily inlines anything prefixed VITE_ or NEXT_PUBLIC_.

That is not "insecure in theory". Anyone can read it, spend on it, and the first evidence is usually an invoice or a quota mail. The fix is a server route and a rotated key — half a day. The reason it costs half a day and not ten minutes is that the call has to move, its error handling has to move with it, and the old key has to be killed everywhere it was pasted.

2. Authentication that lives in the UI

The login screen hides the button. The data layer does not. When I open the network tab and replay a mutation as a logged-out user, more often than not the row changes.

Moving that check to the server is not hard, but it is not local either: every write needs an identity check, every read needs an ownership check, and every place the client trusted a user ID in the request body has to start ignoring it. That is one to two days, and it is the single most common reason an app that demos perfectly is not allowed to be public.

3. A database the client can query directly

Supabase and Firebase make the first version absurdly fast, and they make this mistake easy: the anon key is public by design, so the permissions in the database are the only thing standing between a stranger and the table. A policy written for the demo ("authenticated users can select") is not a policy for a paid product.

This one is tedious rather than clever: one policy per table, one test per policy, and a decision about every join the product needs. Usually a day, and it is the day that turns "it works" into "it is allowed to work".

4. A payment webhook that nobody verified

The checkout redirect tells the app that the payment succeeded. The webhook tells it later, and separately. I have now seen three versions of this failure: a webhook with no signature check (send a POST, get credits), no idempotency key (the provider retries, the user gets the credits twice), and an order marked paid by the browser redirect while the payment itself later fails.

Money bugs are quiet. Nobody reports them; you find them in the settlement report a month later. Signature verification plus one idempotency table is a day of work, and it is the only part of the build where being wrong is not recoverable.

5. Only the happy path

AI writes the path where the network is fast, the card is valid, the list has items and the user does what the design assumed. Then a store reviewer opens it on a slow connection, the empty state is a blank white screen, and the error is a raw JSON dump.

This is the cheapest fix on the list — half a day for empty states, loading states, real error messages, and one retry — but it changes the review outcome and the first review a user writes.

6. A deploy that only works on the builder's laptop

Environment variables that exist only in .env.local. A build that needs a Node version nobody wrote down. An SPA whose deep links 404 the moment they are opened directly. No account deletion page, which both stores now require before they will publish. No privacy text for the permissions the app requests.

None of this is engineering. All of it is release, and release is where a three-day build turns into three weeks of "it works on my machine".

Where this list ends up

This is the list I quote from. I do the pass, then write down which items are open, which are half-open, and which are not needed for this product — a booking app and a marketplace do not have the same six. The price is fixed and written before any deposit. The finish is 3–5 days for the normal case. The balance is due only after you have clicked the working build on your own domain with a real card. Revision rounds are free while the scope on that one page does not change.

And when the audit says three weeks — a bank integration, two-sided compliance, a game whose content does not exist yet — the first reply says three weeks, not three days.

The code review and the quote are free. Send the repo or the URL: yyhak12345@gmail.com

https://cpcai-studio.netlify.app/en/

I am one person at a small company in Seoul (CPC AI Inc.), no agency, no PM, no sales layer — the person who answers the mail is the person who writes the code.