友田 陽大
日本語English

Free · no signup · 20 questions

Is the app you built with AI safe to launch?

Twenty questions to run before you put an app built with Claude Code, Cursor or Lovable in front of real users. You don't need to read any code. Answer yes / no / not sure and you get your risks ordered by severity, plus fix instructions you can paste straight into your AI tool.

Nothing you type leaves your browser — no upload, no storage

Answered0 / 20

Passwords & API keys

Whether your keys are sitting somewhere other people can read. AI optimizes for “it runs,” which often means putting the key wherever it works fastest.

  • CriticalIs your Supabase `service_role` key or database password stored anywhere that reaches the browser (for example an environment variable starting with `NEXT_PUBLIC_`)?
  • ImportantAre any API keys or passwords written directly in your code or pushed to GitHub? (Is a `.env` file tracked in the repository?)
  • RecommendedHave you rotated any key that was ever visible somewhere others could see it — an AI chat window, a screenshot, a public repository?

Database permissions

The single most common source of real incidents. One missing setting makes every user's data readable by anyone.

  • CriticalIs Row Level Security enabled on every database table, with policies that limit rows to the logged-in owner?
  • ImportantAre writes (inserts and updates) restricted too, so nobody can create or modify rows as someone else?
  • ImportantIf data gets deleted or corrupted, do you have a backup you can restore from?

Login & permissions

Having a login screen and keeping other people's data private are two different things.

  • CriticalIf someone edits an ID in the URL (the 123 in `/orders/123`) to someone else's, do they still get blocked?
  • ImportantAre admin screens and actions (listing all users, deleting, refunding) actually impossible for a normal user to invoke?
  • RecommendedDo email verification and password reset actually work in production?
  • RecommendedDoes logging out reliably work, and do idle sessions eventually expire?

Payments

Mistakes here turn into refunds and lost trust immediately. If your app has no payments, answer yes to all of these.

  • CriticalIf the same payment webhook arrives twice, is the customer protected from being charged or credited twice? (Answer yes if you have no payments.)
  • ImportantIs the amount charged decided on the server rather than taken from the browser? (Answer yes if you have no payments.)
  • ImportantDo you verify the signature on incoming payment webhooks? (Answer yes if you have no payments.)

Personal data & legal

Once you hold other people's information, some obligations are not optional.

  • ImportantDo you publish a privacy policy? (You need one as soon as you hold even an email address.)
  • ImportantIf you charge money, do you publish the commercial-transaction disclosures your jurisdiction requires? (Answer yes if everything is free.)
  • RecommendedAre you collecting more personal data than you need — and is personal data ending up in your logs or error alerts?
  • RecommendedIf a user asks you to delete their account and data, can you actually do it?

Operations, cost & recovery

This is what bites after launch. A runaway bill and “I can't roll back” are the two most painful ones for solo builders.

  • ImportantHave you set spending limits or billing alerts on your cloud services and APIs?
  • RecommendedWould you notice that production is broken before a user tells you?
  • RecommendedIf a deploy breaks production, can you get back to the previous version quickly?

Your result

Nothing answered yet. Answer the questions above and your verdict — plus everything that needs attention, worst first — appears here.

This is a self-reported checklist, not a reading of your actual code. It cannot confirm that the items you answered yes to are implemented correctly. If your app handles money or personal data, have a human look at it before launch.

About this check

Twenty questions, ordered by what can actually hurt you

AI writes working code fast, but it does not implement “who can see which data,” “nobody gets charged twice,” or “we can roll this back” unless you ask. This check covers exactly those gaps, in plain language.

  1. 1

    1. Answer 20 questions

    Yes, no, or not sure. No code reading required. Choose “not sure” honestly — unverified is nearly as risky as unaddressed, and the scoring treats it that way.

  2. 2

    2. See your risks in order

    Ranked critical, important, recommended. While a single critical item is outstanding, the result says do not launch regardless of your score.

  3. 3

    3. Paste the fixes into your AI tool

    Every item carries an instruction you can paste into Claude Code or Cursor, and you can copy them all as one brief. Bring in a human only for what you cannot close yourself.

FAQ

  • Can I use this if I can't read code?

    Yes. The questions are about how your app behaves, not how it is written — for example, whether editing an ID in the URL exposes someone else's data. Choose “not sure” where you don't know; it counts as risk and the result tells you how to find out.

  • Is anything I type sent anywhere?

    No. Answers and results are computed entirely in your browser. Nothing is uploaded, nothing is stored, and there is no email field. Close the page and your answers are gone.

  • I answered “not sure” a lot and my score is low. Does that mean I'm unsafe?

    It means we can't tell yet. This check weights “not sure” at 0.7× the risk of “no,” because treating unverified as safe would make the result meaningless. Start with the critical items.

  • If everything is yes, am I safe to launch?

    It means nothing major is missing within what this check covers. But it is self-reported, not a reading of your code — answering “RLS is configured” doesn't prove the policy actually scopes correctly. If you handle money or personal data, have a human look first.

  • Does it work for Claude Code, Cursor, Lovable, v0 and Bolt?

    Yes. The questions target gaps common to AI-generated apps rather than any one tool. That said, builders that provision a backend for you (Lovable, Bolt, v0) tend to ship with invisible database permission gaps, so pay particular attention to the database section.

  • What do I do about items I can't fix myself?

    Paste the per-item instruction into Claude Code or Cursor — that closes most of them. For anything you still can't judge, especially authorization design, payments and personal data, a light review (from $210, about 3 business days) has an engineer read the actual code. A free intro call is a fine place to start.

For the items you can't close yourself

Authorization design, payments and personal data are the areas where asking an AI does not converge on one right answer. I read the actual code and tell you what would happen in your app. I build production B2B SaaS with Claude Code myself, so I am not going to tell you that using AI was the mistake.

Get your app reviewed (free intro call)See pricing and scope (from $210)

No coding knowledge required — I'll walk you through sharing the repository.