You’ve built a website or app with AI. Is it ready for customers?

It might be. AI building tools have become good at producing something that looks finished and works when you try it. Whether it's ready for customers depends on what happens when something goes wrong: a failed payment, two people booking the same slot, or a visitor looking for a way into other people's data.

Building a prototype yourself is a good way to work out what you need. Even if you hire someone later, a working version explains your idea far better than a written brief. This post is a set of checks for the step after that, when real customers, real money or personal information are about to be involved.

Why a prototype can look more finished than it is

When you test your own app, you follow the path you had in mind. You enter sensible details, click the buttons in order and use one browser. Customers will not all do that.

AI tools tend to build what you describe, and they are usually good at the main path. The less obvious cases are often handled only if you ask for them: what happens when a card is declined, a form is sent twice, or someone changes a number in the address bar. Many of the checks below come from those cases.

Check that each customer can see their own information and no one else’s

This is the check to do first, because a failure here can expose other customers' details.

Log in as one test customer and open something that belongs to them, such as an order or a booking. Look at the address bar. If it ends in something like /orders/124, change the number to 125 and see what appears. Then try the same pages while logged out, and try any admin pages from a customer account.

If you can see anything that is not yours, the app is checking that someone is logged in without checking what they are allowed to see. That's a common problem in prototypes, and it needs fixing before anyone else uses it.

Find out where your data lives, and whether you could get it back

Your customers' details, orders and bookings are stored in a database somewhere. Find out:

• which service holds it, and whether the account is in your name
• whether it's backed up automatically, and how often
• whether you have ever restored a backup, since a backup you have not tested may not work when you need it
• which country the data is stored in, if your customers are in Europe.

If the answer to any of these is that you do not know, ask the tool you built with. It can usually tell you what it set up.

Keep the keys to other services out of sight

Many apps connect to other services, such as a payment provider, an email service or an AI model. Each connection uses a kind of password that lets your app use that service. This is called an API key.

These keys belong on the server, where visitors cannot see them. In a prototype they sometimes end up in the code that runs in the visitor's browser, where someone who knows where to look can copy them and run up charges on your account. Ask your tool to list every key the project uses and where each one is stored. If any are in the part that runs in the browser, move them before you launch.

Try the awkward cases on purpose

Spend an hour trying to break it, the way a busy or careless customer might.

• Use a test card that is declined, and check that no order is created and the customer is told what happened.
• Press the payment or booking button twice, quickly.
• Book the same slot from two browsers at once.
• Enter an email address with a typo, a very long name, or a phone number with spaces.
• Open it on a phone with a slow connection.

Payment providers such as Stripe offer test cards for declined and failed payments, so you can do this without spending money. Note what goes wrong and fix the problems that would cost a customer money, time or trust first.

Check what the law expects of you

If the app collects personal information, data protection rules apply to you as well as to large companies. At a minimum, you will usually need a privacy notice that says what you collect and why, a way for people to ask for their data to be deleted, and consent before setting cookies that are not needed for the site to work.

Taking payments or storing health or financial details brings further rules. This is an area where it's worth checking the specifics for your situation rather than relying on what the tool generated.

Know what it will cost to run

A prototype can be free or cheap while you are the only user. Once customers arrive, several costs can grow with use: hosting, the database, email sending, and especially AI features, which are often charged for each request.

Check the pricing page for each service the app uses, and set spending limits or alerts where they are offered. It's much easier to adjust a price or a plan before launch than after an unexpected bill.

Decide who will look after it

Software needs looking after once it's live. The libraries it's built on receive security fixes, the services it connects to change, and customers find problems you did not. Someone has to notice and respond.

It's also worth checking whether you own what you have built. Can you export the code and run it somewhere else, or does it only work inside the tool you built it with? Neither answer rules the tool out, but you should know which one you have before customers depend on it.

Ask the tool to review its own work, then get a second opinion

Some AI coding tools now include an automated security review, and asking any of them to look for security problems in your project is worth doing. It can find common issues, such as the permissions problem above.

It has limits. Anthropic's own guidance for its review feature says it should complement, not replace, manual code review. The tool that made a mistake may not spot it, and an automated check can miss problems that depend on how your business works, such as which staff should see which records. For anything that handles payments or personal information, a review by a person who builds software is a sensible step before launch.

If it’s a website rather than an app

A website that presents information and takes enquiries carries fewer of these risks, because it holds little data and takes no payments. The checks that matter most are whether it loads quickly, works on a phone, can be read by search engines and AI assistants, and can be used by people with disabilities. Our free website health check covers several of these in a few seconds.

Build on it, or start again?

A prototype is often worth developing further when the code can be exported, it uses common, well-supported tools, and fixing one thing does not keep breaking another.

Starting again can be the better choice when the code cannot leave the tool it was built in, when no one can follow how it works, or when the checks above turn up problems throughout. Even then, the prototype keeps its value. Like a spreadsheet a business has outgrown, it's a detailed record of what you need, and it will make the new version quicker to specify and easier to test.

The more a mistake would cost, the more checking it needs

A landing page to test whether anyone wants your idea may be fine as it is. An app that takes money, holds personal details or runs part of your business needs the checks in this post, and a second pair of eyes.

If you'd like someone to look over what you have built, or help take it further, get in touch. Tell us what it does and which tool you built it with, and we'll reply with what we would check first.