The 5-Point Check for Fast-Built Products

The check

• Find any screen that shows a user their own data — their profile, their orders, their documents. Open your browser's developer tools (F12 → Network tab), reload the page, and look at the request your app makes. Does it send an ID for the user — something like user_id=123 or "userId": "abc"?
• If yes: change that value to a different one and send the request again. Can you see someone else's data?

Why it matters: This is the single most common critical issue we find — it appeared in every fast-built product we've audited. The app builds a login system correctly, then trusts whatever ID the browser sends rather than the verified session. The result: anyone who can open developer tools can read other people's records.

In one product we reviewed, this meant any anonymous visitor could retrieve every user's home address — on a platform whose main promise was privacy.

Green flag: The server figures out who you are from your login session and ignores any ID sent by the browser.

The check

• If your app went down at 3am, what would tell you? An alert, a customer email, or you happening to check?
• When did you last restore a backup — not create one, restore one — and confirm the data was intact?
• If today's deploy broke something, what's your rollback, and how many minutes would it take?
• Is any configuration living only in a dashboard somewhere, absent from your code repository?

Why it matters: Backups, monitoring, and rollback are operations, not features. They never appear in a prompt like "build me an app," so they never get built. The product looks complete because the missing parts are the ones you only need when things go wrong.

One product we audited was running its database as a file on auto-scaling infrastructure. Every routine restart wiped it. No backup had ever been configured.

Green flag: Error tracking and uptime alerts are live, you've actually restored a backup at least once, and your rollback is a procedure you've timed.

Skip this if your product doesn't call any paid API.

The check

• Find the place your app calls a paid service — an AI model, an SMS provider, a maps API.
• Is there a limit on how many times one user can trigger it per day?
• Is there a total daily spend ceiling that stops everything when hit?
• If your rate limiting uses an ID the browser sends (a session ID, a device ID), could someone just generate a new one and start over?
• Would you find out about a spike today, or on your next invoice?

Why it matters: The expensive call is the feature, so it gets built. The budget around it isn't, so it doesn't. Every product we audited that called a paid AI API had no meaningful spend cap.

In one, a script rotating session IDs could have run a four-figure bill in about five minutes, overnight, before anyone noticed. (That's our estimate from their rate-limit design, not a bill they received.)

Green flag: Per-user quotas, a daily ceiling that fails closed, rate limits keyed to something the client can't change, and an alert when spend jumps.

The check

• Can two people sign up with the same email address? Try it.
• If two users act at the same moment — booking the same slot, claiming the same last item — what stops both from succeeding?
• If a payment, message, or booking request gets sent twice (a double-click, a retry, a webhook fired twice), does it happen twice?
• Is money stored as a decimal number rather than whole cents?

Why it matters: The intuitive way to write this is "check whether it's taken, then save it." It reads correctly and passes every test you run alone. Under real traffic, two requests check at the same instant, both see "available," and both save.

We found this in every fast-built product we've audited. Real consequences we've documented: duplicate accounts, double bookings, and duplicate sales messages sent to real prospective customers.

Green flag: Unique constraints and transactions in the database itself, idempotency keys on anything that charges or sends, money as integers.

The check

• Search your codebase for || or or followed by a quoted string near anything named SECRET, KEY, TOKEN, or PASSWORD. You're looking for a fallback default — something like const secret = process.env.SESSION_SECRET || "change-me-in-production".
• Are any user tokens — OAuth tokens, API keys belonging to your customers — stored in your database as plain readable text?

Why it matters: These tools add fallback defaults so the code runs without you configuring anything. Convenient on day one, dangerous forever after. If that environment variable is ever missing in production, every session gets signed with a string that's visible in your source code — and anyone can forge a login as any user.

We found exactly that in a recent audit. The fallback string was "MakeThisSecretMoreSecureInProduction".

Green flag: No fallbacks — the app refuses to start if a secret is missing. Tokens encrypted at rest.