An app that works on test data usually lacks the things you cannot see while clicking it together: who can sign in and what they can see, whether the database lets data leak out, where the secret keys are stored, how data gets restored and who fixes the app when it stops working. Before you put real customers, invoices or employees into it, go through these six areas.

How much you need to add depends on three things: what data the app holds, how many people use it and whether it is reachable from the internet. An order tracker for three colleagues is a different case from a portal where customers sign in and upload contracts.

A working app is not yet an app ready for production

Today, even someone with no programming background can build an app with AI. The tool generates the screens, the database and the sign-in. What it does not do is check whether everything is configured securely.

As The Next Web reported this April, a large number of projects on the Lovable platform were left publicly accessible for 48 days. According to a study cited in the article, roughly seven in ten of the apps examined had database row-level security turned off. And of more than 200 apps reviewed, the vast majority had at least one vulnerability.

This is not a flaw in one particular tool. A working app and an app that is safe for everyday use are simply two different things. The gap between them can be checked point by point.

How much checking you need

What the app holds and who can access it Minimum requirements
Internal records with no personal data, a few colleagues individual accounts, public sign-up disabled, backup
Customer or employee data plus rules in the database itself, roles, access testing, review of personal data obligations
Money, invoices, accounting integration plus keys on the server only, protection against duplicate submission, change log
External users sign in (customers, clients) all of the above and an independent expert review before launch

Set up sign-in and roles so everyone sees only what is theirs

A login screen does not mean the app is locked. Verify it with a few simple tests.

  • Try an internal page without signing in. Copy the URL of the page with your order list and open it in a private browser window.
  • Disable public sign-up. A common mistake: anyone can create an account on the login page and gain access to everything.
  • Everyone has their own account. A shared password such as “warehouse” makes it impossible to see who changed what or to revoke access for one person.
  • Define the roles. Who can only read, who can edit, who can delete and who can see prices, margins or salaries.
  • Plan for employees leaving. How you will revoke their access on the day they leave.
  • Administrators use two-factor authentication, if the tool supports it.

One thing to watch out for: hiding a button in the interface is not protection. If regular users must not delete records, the server or database has to prevent it, not just a missing button.

Turn on data protection in the database itself and test it

Many rapid app-building tools store data in a database that the user’s browser connects to directly. In that case, the only thing stopping a stranger from reading an entire table is the set of rules inside the database. These are usually called row-level security.

Follow these steps:

  1. Go through every table and confirm that protection is enabled on each one, not just some.
  2. Check that the rules match the roles you defined. A rule like “a signed-in user sees everything” is often not enough.
  3. Sign in as a regular user and try to open a record that belongs to someone else.
  4. Review file storage. Uploaded invoices, contracts or photos must not be reachable through a public link that can be guessed or forwarded.

If the app holds data about people, including your own employees, data protection rules apply to you. Check with a specialist in this area what exactly they mean for your situation.

Move secret keys out of the code and onto the server

An app usually connects to other services: a payment gateway, email delivery, a language model or accounting software. It has an access key for each one. If a key sits in code that is downloaded to the browser, anyone can read it. They can then spend money on your account or read your data.

Checklist:

  • Search the code for words like “key”, “secret” or “token”.
  • Distinguish between a public key, which belongs in the browser, and a service key with full privileges, which must never be there.
  • Store secret keys in the server’s environment settings, not in code files.
  • If a key was ever in the code or you pasted it into a chat with an AI tool, replace it with a new one. Deleting it from the code is not enough; older versions remain in the history.
  • Set spending limits and alerts for paid services.

Each key should have only the permissions the app actually needs.

Test restoring from a backup before you need it

A backup you have never restored anything from is just an assumption. Work through these questions:

  • Is the database backed up automatically? How often, and how far back? Check exactly what your plan includes.
  • Is there a copy of the data outside a single provider?
  • Are uploaded files backed up too, or only the database?
  • Have you tried restoring the data into a test copy of the app at least once?

Changes made after launch are a separate risk. When you ask an AI tool for a new feature, it may change the database structure and delete a column containing real data in the process. Keep a test environment separate from production and try changes there first.

Also check whose account the app is registered under with the provider. It should belong to the company, not to one employee’s personal email.

Design the accounting integration for the moments when it fails

As soon as the app sends data to accounting software or reads from it, errors are no longer purely internal. An invoice sent twice or a lost document then has to be sorted out with a client or your accountant.

Before launch, answer these questions:

  1. Where is the source of truth? Which record prevails when data in the app and in the accounts differ.
  2. What happens during an outage? When a transfer fails, who finds out and how is it retried.
  3. What prevents duplicate entries? A repeated click or retry must not create a second invoice.
  4. Can you see who changed what? A change log for amounts and documents saves a lot of tracing.

Consult your accountant or tax adviser about document numbering sequences, archiving and other accounting and tax rules. The app has to comply with them no matter who built it.

Decide who fixes the app when it breaks

The weak spot is often not the technology. One colleague clicked the app together and nobody else knows how it works. What happens when they go on holiday or leave?

Make sure of at least the following:

  • The company owns the code. Download it to your own repository or a company account, not just the tool it was built in.
  • A short one-page description. What the app does, where it runs, which services it uses, where the keys are and how to restore from backup.
  • Uptime monitoring. When the app stops working, a specific person should find out, not the users first.
  • Updates. The libraries the app depends on receive security fixes. Someone has to deploy them.
  • A named backup person. A colleague, external developer or company that knows the code and can step in.

If the checklist reveals more gaps than you can fix, that does not mean the work was wasted. A working prototype is a good specification. It shows what the business actually needs, and an expert can use it to finish the app or rebuild it.

Conversely, for an internal tool with no sensitive data and a handful of users, adding sign-in and backups may be enough. More checking often makes little sense there.

Sources

Frequently asked questions

Is it enough if the app is only used by people inside the company?

It reduces the risk, but it does not replace sign-in and roles. Rapid app-building tools often publish apps to the internet automatically. Check by opening the URL on your phone outside the company network.

Can the AI tool check security by itself?

Some tools offer a built-in security scan, and it will help catch obvious mistakes. But it does not know who in your company is allowed to see salaries or margins. Whether the rules match your roles is something you have to verify yourself by signing in as a regular user.

How do I know if a key to a paid service has leaked?

You will not always know right away. Look at the usage dashboard of the service provider and watch for unusual spikes. Treat any key that was ever publicly accessible as compromised and replace it.

When is it better to rebuild the app than to fix it?

When fixing it would mean changing the data structure and adding permissions to almost every screen. Or when nobody understands the code and every AI-driven change breaks something else. In that case it is usually simpler to treat the prototype as a specification and rebuild the app.

What should I do with an app people are already using without these checks?

You do not have to shut it down immediately. Start with what cannot be undone: back up the data, replace any keys that may have leaked and disable public sign-up. Then work through the rest of the list according to how sensitive the data in the app is.