It's happening in a lot of small businesses right now. Your office manager builds a booking tool in Lovable over a weekend. Someone in sales makes a quote calculator with Bolt. A freelancer delivers a client portal in two weeks instead of three months, because an AI tool wrote most of it.
That's good news. These tools are real, and they save real money. A tool that used to need a development agency can now be built by the person who actually understands the problem.
The catch is that an AI-built app looks finished long before it's safe. The screens work, the buttons work, the demo goes well. What the demo doesn't show is who else can reach the data, whose account it all lives on, and what happens on the day it breaks.
This post is for the owner or manager who has to decide whether that app is ready for customers. You don't need to read code. You need to ask the right questions, and know what a good answer sounds like.
Why this isn't like a spreadsheet
When someone builds a clever spreadsheet, it sits inside your company account. Only people you've shared it with can open it.
An app is different. It's on the public internet, with a login page anyone can find. Its database is reachable from outside. It often holds keys to paid services, like an AI provider or a payment system, that cost money every time they're used. And the person who built it may be the only one who knows how it works.
None of that is a reason not to use it. It's a reason to check a few things first.
The eight questions
Sit down with whoever built the app and go through these. Most take a few minutes to answer. If the answer is "I'm not sure", that's useful too: it tells you where to look.
1. What data goes into it?
This decides how careful you need to be. An internal tool that tracks which meeting room is free is low stakes. A tool that holds customer names, emails, addresses, payment details, health information or anything about children is not.
A good answer: a short, specific list. "Customer name, email, phone, and the date of their appointment."
A warning sign: "Whatever they type in", or a form that asks for more than the job needs. Data you don't collect can't leak.
2. Could a stranger see that data?
This is the most common serious problem in AI-built apps, and the hardest one to spot from the outside. Many of these apps keep their data in a hosted database like Supabase or Firebase, which the app's web page talks to directly. That's safe only if the database has rules saying who may see which records. If the rules are missing or too loose, anyone who knows where to look can read every record, without logging in.
A good answer: "Yes, I checked. When I'm logged out, I can't see anything. When I'm logged in as one customer, I can't see another customer's records."
A warning sign: "It has a login page, so it's protected." A login page on the screen doesn't mean the database behind it is locked. If the app uses Supabase, this ten-minute check shows the builder exactly how to test it.
3. Whose accounts is it on?
An app usually depends on several services: the AI tool it was built in, a database, a hosting service, a domain name, maybe a payment provider and an email service. Ask who owns each of these accounts, and whose card pays for them.
A good answer: every account is in the company's name, with a company email address, and at least two people can log in.
A warning sign: it's all on the builder's personal Gmail and personal credit card. That works until they go on holiday, change jobs, or forget to renew something. If a freelancer built it, this is the first thing to sort out, before the final invoice is paid.
4. Who can log in, and what happens when someone leaves?
Ask how a new staff member gets access, and how a departing one loses it. Ask whether there's an admin area, and who can reach it.
A good answer: "There's a list of users. I remove someone and they're locked out straight away. Only two of us are admins."
A warning sign: everyone shares one login, or nobody's quite sure how to remove a user. Also check that the admin area is protected by the server, not just hidden from the menu. "You can only find the admin page if you know the address" is not protection.
5. What does it cost if someone abuses it?
If the app uses AI, such as a chatbot or something that writes text or reads documents, every request costs money. If the app sends emails or text messages, those cost money too. Someone who finds the app can run up that bill on purpose.
A good answer: "There's a spending limit set at the provider, and only logged-in users can use the AI features."
A warning sign: no spending limit anywhere, or AI features open to anyone who visits the site. Setting a monthly cap with each paid provider takes five minutes and turns a disaster into an annoyance.
6. If it takes payments, who decides that someone has paid?
This one matters only if money changes hands. In a well-built app, the payment provider tells your server that a payment succeeded, and the server unlocks the product. In a badly built one, the customer's browser says "I've paid" and the app believes it.
A good answer: "We tested a failed card and a cancelled subscription, and both were handled correctly."
A warning sign: payments were only ever tested with a card that worked.
7. Is there a backup, and has anyone restored one?
Ask where the data is backed up, how often, and whether anyone has tried getting it back. Some free and starter plans include little or no backup. And a backup nobody has ever restored is a hope, not a plan.
A good answer: "Daily backups are included in our plan, and I restored one to a test copy last month."
A warning sign: "The database company handles that", without anyone having checked what the plan actually includes.
8. Who fixes it when it breaks?
It will break at some point. A service changes, an update goes wrong, a customer finds a strange bug. Ask who gets told, and who can fix it.
A good answer: the app reports its own errors to someone, the code is stored in a company GitHub account, and there's a short written note on how it's put together.
A warning sign: the only copy of the app lives inside the builder's AI tool account, and the only way anyone hears about a problem is when a customer complains.
How worried should you be?
Not every app needs the same care. A rough guide:
- Internal only, no personal data: sort out account ownership (question 3) and spending limits (question 5), and you're in good shape.
- Staff data, or customer contact details: go through all eight questions properly, and make sure someone has actually tested question 2, not just answered it.
- Payments, health data, children's data, or anything a customer would be upset to see leaked: have someone outside the build look at it before launch. The builder is the person least likely to spot what they missed.
If you're in the EU or the UK, there's a legal side too. A leak of customer personal data usually has to be reported to your data protection authority within 72 hours, and you may have to tell the customers affected. It's much cheaper to find the problem first.
If a freelancer or agency is building it
More and more freelancers and agencies use AI tools to build faster. That's fine, and it can make the work cheaper. Just add a few lines to the agreement:
- All accounts (hosting, database, domain, payments, AI providers) are created in your company's name, or handed over before the final payment.
- The code is delivered to a GitHub account your company owns.
- You get a one-page handover note: what services it uses, where the data lives, and how to log in to each.
- They confirm they've tested that one customer can't see another customer's data.
A good freelancer will be happy to agree. If one isn't, that tells you something.
Want a second pair of eyes?
The questions above get you most of the way. If the builder wants to go deeper, the 33-point launch checklist covers the technical side, and the free launch-readiness check lets their AI tool review the code and write a plain-English report you can both read.
If the answers left you unsure, or the app is about to hold data you can't afford to leak, I can help. A quick check looks at the one area that worries you most, in a day. The launch-readiness audit covers the whole app, with a report written for the person who has to make the decision, not just the person who wrote the code. And if the tool works but has outgrown how it was built, custom workflows turns it into something your team can rely on.
Or tell me what your team built, and I'll tell you honestly whether it needs any of that.