Built Your App With AI? Check These Before Your Customers Do

AI coding tools have changed who can build software. A founder with a clear idea can have a working app in a weekend, and a business owner can replace a spreadsheet with something that looks like a real product.

That is genuinely good. The catch is that these tools build exactly what you ask for, and nobody asks for the things that only matter once real customers and real money arrive. The demo works. The first hundred customers find what the demo never had to handle.

This post covers what AI-built apps most often leave out, how to check your own in about thirty minutes, and when it is worth getting a second pair of eyes.

Why it looks finished but is not

An AI tool optimises for the screen in front of you. You ask for a customer dashboard and you get a good-looking dashboard. What you do not get, unless you ask, is the rule that a customer may only ever see their own records - and the tool has no reason to raise it.

The result is software that passes every test you can think of while you are the only user, and fails the moment a second customer, a bored teenager or a payment provider behaves differently from you.

Eight things that break most often

1. One customer can see another customer's records

The most common and most serious gap. A customer opens their own invoice, changes the number in the address bar, and sees someone else's. Apps built on hosted databases often ship with the per-user access rules switched off, because everything works without them.

This is the one you cannot take back. Under Kenya's Data Protection Act 2019, exposing customers' personal data is a breach you may have to report, with penalties of up to KES 5,000,000 or one percent of turnover.

2. Admin screens reachable by typing the address

The admin menu is hidden from normal users, but the admin pages themselves do not check who is asking. Anyone who guesses the address gets in.

3. Secret keys in the app itself

Payment keys, database passwords and API tokens pasted into the part of the app that runs in the customer's browser or phone. Anyone who knows where to look can read them, and use your accounts.

4. Prices and payments trusted from the customer's side

The total is worked out on the customer's phone and sent to your server, which believes it. Or an M-PESA confirmation arrives twice and the order is paid twice, or never arrives and the order stays unpaid. If money moves through your app, this is where it leaks. Our guide to M-PESA webhooks and polling covers the payment side in detail.

5. Backups that have never been restored

Backups are often switched on by default. Almost nobody has tried restoring one. You find out whether yours works on the worst possible day.

6. Logins and password resets that do not quite work

Reset links that never expire, sessions that survive a password change, staff who have left but can still sign in. Each is small; together they decide who can get into your business.

7. Fast when empty, slow when real

It flies with fifty records. A year later there are fifty thousand, and the same page takes ten seconds on mobile data. Customers do not complain; they leave.

8. Nobody else can take it over

No tests, no documentation, and code only the tool and you understand. That is fine until you need to hire a developer, raise money, or answer a big customer's security questions.

A thirty-minute self-check

Do these with two test accounts, not your own admin account:

1. Swap the ID. Sign in as customer A, open one of their records, and change the ID in the address bar to one belonging to customer B. You should get an error, not B's data.
2. Visit admin as a normal user. Copy an admin page address and open it while signed in as a regular customer.
3. Search your code for keys. Look for anything that starts like a payment or API key in the files that ship to the browser or phone.
4. Change a price in transit. If you can, edit the amount your app sends at checkout. Your server should recalculate it and refuse the change.
5. Pay twice. In your payment provider's test mode, send the same confirmation twice. You should see one payment, not two.
6. Restore a backup into a scratch copy and check the records came back whole.
7. Reset a password twice and try the first link. It should no longer work.
8. Remove a staff member and try signing in as them.

If every one of these behaves, you are ahead of most AI-built apps we see. If even one does not, fix it before you spend money on advertising.

When to get a second pair of eyes

It is worth an outside check when:

• Real money or personal data will run through the app
• You are about to launch, run ads or sign a large customer
• A bank, investor or customer has asked a security question you could not answer
• The person or tool that built it is no longer around to ask

A Launch Check does this properly: security, money, speed, staying up, your records and whether anyone else could take it over, written up in plain words with a straight go or no-go in three working days. The full checklist is published on that page, so you can work through it yourself first.

Found problems and want them fixed? Our custom systems service picks up where the AI tool left off, and Care keeps it watched, patched and backed up once it is live.

Not sure where you stand? Book a free scoping call and we will tell you honestly - including when the answer is that it is fine.