You built a web app in Lovable, or with ChatGPT, or in Bolt, v0 or Replit, or by talking to Claude. It works. You have shown it to a friend on your laptop and they were impressed. Now you want to send the link to a customer, and a small voice is asking whether that is a good idea.
The voice is right to ask. Not because the tool did a bad job, but because the tool built what you asked for, and nobody asked for the boring parts. Here are five of them you can check yourself, this afternoon, without reading a line of code.
If you built with ChatGPT instead, by asking it for the code and pasting it in piece by piece, the five checks are the same. The one difference is that nobody connected the pieces for you, so check 4 counts double.
1. Open your own web app as a stranger
Log out. Open a private browser window. Paste in the link you were about to share, and then try the links you would not normally click: the settings page, the admin page, the address of a record with a different number at the end.
What you are looking for is anything that opens when it should not. An admin page that loads without a login. A customer's details that appear when you change the number in the address bar. A page that says "loading" forever, which usually means it tried to fetch something it was not allowed to and nobody told it what to do about that.
If you find any of these, stop here. This is the fault we see most often in web apps built fast, and it is the one that ends up in a screenshot somewhere public.
2. Ask the tool where the keys are
Your web app talks to other services: a database, an AI model, an email sender, maybe a payment provider. Each of those gave you a key, a long string of letters that works like a password. The question is where your app keeps them.
You do not need to find them yourself. Ask the tool you built with, in plain words: "Does any API key or secret in this app reach the browser, or is any of it committed to the repository?" Then ask a second time, differently: "List every environment variable and where each one is used." Tools are good at answering this when asked directly, and bad at volunteering it.
A key that reaches the browser can be read by anyone who opens your app. If that key has a credit card behind it, that is how a surprise bill happens.
3. Find out what costs money per click
Make a list of every service your web app uses. For each one, answer a single question: do I pay a fixed amount, or do I pay per use? An AI model is nearly always per use. So are email, text messages, maps, and file storage once you pass the free amount.
For every per-use service, log in to that service's website and look for two settings: a spending limit and a spending alert. Set both. A limit stops the bill; an alert tells you before it gets there. Most services have them. Most apps built in an afternoon have neither switched on.
Then ask the tool one more question: "Can a visitor who is not logged in trigger any call that costs money?" If the answer is yes, your free demo page is a button anyone on the internet can press as often as they like.
4. Check what is in your name
Three things should be in an account you control, with a password you know and an email address you read: the domain, the hosting, and the code.
The domain is the address people type. The hosting is where the web app runs. The code is the app itself, and it should live in a repository (GitHub is the usual one) that belongs to you, not only inside the tool that built it. If the tool disappears, changes its prices, or locks your account, the repository is what lets you walk away with your app.
Many tools can connect to your own GitHub in a few clicks. If yours is not connected yet, do that before you share anything.
5. Add the boring page
If your web app collects anything at all about a person, a name, an email address, a photo, it needs a privacy policy that says what you collect and why. If you are in Europe or your customers are, and the app uses cookies for anything beyond keeping someone logged in, it needs a cookie banner that lets them say no. And somewhere, there should be a way to contact you.
None of this is glamorous. All of it is the difference between a web app a business can use and one a business cannot be seen using. A tool will write you a privacy policy if you ask; read it before you publish it, because it will describe what a typical app does, not what yours does.
What a checklist cannot do
Everything above is a test you run from the outside. It tells you whether the door is open. It does not tell you how many other doors there are.
When a stranger used a feature in our own product, Tolkra, exactly as it had been built to send scam email from our domain, the button they pressed had passed every outside test. It checked that you were logged in. What it did not check was whether you had any business naming the person the email went to. Finding that took reading the code, and finding the four other places the same assumption had been made took a day. We wrote the whole story up, because it is the day most web apps built fast are heading for.
So run the five checks. If they all pass, you have ruled out the most common ways to be embarrassed. If you then want someone to read the code and tell you in plain language what else is there, that is what a readiness review is for: half a day, a written report. The first conversation, a 25-minute check, is free.