You are about to open your application to real users. The recurring question is always the same: what has to be checked before pressing the button?
Here is the list we apply to applications produced with generation tools. It is ordered by consequence rather than difficulty: the first items cover what cannot be undone.
What cannot be undone
A user sees only their own data. Create two trial accounts with distinct data. Log into the first, open a record, note the address in the browser bar. Log out, log into the second, paste that address. If the first account’s record appears, the rule is missing. This defect tops the application risk ranking published by OWASP, and in 2025 it produced a flaw catalogued as CVE-2025-48757 affecting more than 170 applications built with Lovable.
No secrets in the browser. Open the developer tools with F12, sources tab, and search for sk_, secret, service_role, password. A key that appears there has been handed to every visitor.
Uploaded files are protected. Copy the address of a document sent by a user and open it in a private browsing window. If it displays, your storage is public and will stay so for any address already circulating.
Roles are enforced on the server. A distinction between administrator and user that rests only on hidden buttons protects nothing.
What the law requires
Legal notices are present and accurate. Company name, legal form, share capital, registered office, registration number, publication director, host.
The privacy policy describes reality. What you collect, why, how long you keep it, who you share it with. A generic text that does not match your application exposes you more than it protects you.
Consent for trackers, where there are any. Audience measurement configured to work without consent follows precise rules. An advertising tool never does.
The breach procedure is known. You know who to call and what to do if data escapes. The notification window is 72 hours from the moment you become aware, under the French authority’s procedure.
What breaks on day one
Odd input. Test every form with an empty field, a very long text, an apostrophe, a leading space in an email address, an impossible date. A form that crashes on an apostrophe is a form that crashes on the first morning.
The double click. Submit an order or a payment twice in a row. If two records appear, the problem will happen.
The back button. Use the browser’s back button in the middle of a journey. Many generated applications never recover.
The phone. Open the application on a six-inch screen. Generation tools often produce a layout designed for a large display.
Emails actually arrive. Sign-up confirmation, password reset, order notification. Check they do not land in spam either, which depends on how your domain is configured.
What breaks in the first month
Volume. Fill a copy of the database to the level you expect in six months, then reopen your main screens. The comfort threshold for the largest element on a page is 2.5 seconds.
Scheduled tasks. A weekly reminder, a monthly report, an overnight synchronisation. Check they genuinely run and that a timestamped trace proves it. A task that stops produces no visible error.
Errors are visible somewhere. When a user hits a problem, someone should be able to see it without waiting for them to write in.
You can retrieve your code. Open the repository on your own account, with your own credentials. List the services in use and the owning address of each account. The tools support this synchronisation, provided it has been switched on.
How to run the check
This list takes half a day on a modest application, provided you work in the right order and write things down as you go.
Start by creating the test accounts you will need, with genuinely different data: two customers, two orders, two documents. Most access defects only appear with two distinct data sets.
Record each finding in a three-column table: what you did, what happened, what you expected. The format looks schoolish, and it prevents vague discussions with whoever does the fixing.
Fix nothing during the check. A mid-course correction moves the problem and you lose track of what has already been tested.
Run the whole list again after the fixes, not only the corrected items. A change often touches what it was not supposed to touch, particularly in code produced by a generation tool.
The rollout order that limits damage
Opening to everyone on the same day concentrates every problem into one day, with the same people to answer them.
The progression that works starts with a handful of internal users for a week, on real data. Then a small group of friendly customers, warned that they are first in and willing to report what sticks. General opening comes after that.
Each step produces feedback internal testing never generates, because your users work the application differently from you.
What not to do
Open on a Friday. Open to everyone at once when a staged rollout costs the same. Open with nobody answering messages during the first week.
What we do
We run this list against your application and hand you the result in plain language, each item with its severity and what the fix represents.
You decide what gets handled before opening and what can wait. Each batch is quoted at a fixed price, and we show you how to repeat these checks yourself before each later release.