You built your app with AI. Find out if it really holds up.

Sound familiar?

You need a check-up if at least one of these is true.

What I check

Eight areas, each scored from 1 to 10. The Express focuses on the three most critical.

What I found in AI-built apps

Real cases from my clients, anonymised.

Security cases with a security problem

1. Rev. 1 Security Resolved

   The OpenAI key in the browser

   App with an AI assistant built with Lovable

   What I found

   To make the assistant answer, the OpenAI key sat in the code running in the browser: anyone could copy it from the developer tools and use it at the client’s expense

   Outcome

   Key revoked and replaced, calls moved to the server with usage limits

2. Rev. 2 Security Resolved

   One table without access rules

   E-commerce on Lovable and Supabase

   What I found

   Every table was protected except the orders table, added later: with the app’s public key anyone could read the names, addresses and purchases of all customers

   Outcome

   Access rules on every table and a check that flags unprotected ones

3. Rev. 3 Security Resolved

   The Pro plan you could unlock from the browser

   Subscription SaaS written with Claude and Cursor

   What I found

   The "has this user paid?" check ran only in the browser and the payment webhook did not verify the signature: changing one variable was enough to use the paid plan for free

   Outcome

   Subscription checked on the server and webhook with signature verification

4. Rev. 4 Security Resolved

   The admin panel that was not hidden

   Internal management app built with Lovable

   What I found

   The admin page did not appear in the menu, but its address worked for anyone who had logged in: every user could see and change everyone’s data

   Outcome

   Roles and permissions checked on the server, page by page

5. Rev. 5 Security Resolved

   The uploaded documents were public

   Client portal built with Lovable and Supabase

   What I found

   The identity documents users uploaded ended up in public storage: the link alone was enough to open them, no login needed

   Outcome

   Private storage, expiring links and access only for the document’s owner

6. Rev. 6 Security Resolved

   The database key in a public repository

   Booking platform written with Cursor

   What I found

   The all-powerful database key was in a repository made public by mistake, and there was no backup: anyone who found it could read or delete all the data

   Outcome

   Key revoked before anyone used it, repository made private, automatic backups and a check that blocks secrets before every release

7. Rev. 7 Security Resolved

   The management app that could not talk to the ERP

   Production management app built with Lovable

   What I found

   The ERP only accepted authorised addresses and the app had no fixed IP. On top of that, the main database key was published in the repository

   Outcome

   A secure, logged API bridge between app and ERP, with automatic synchronisation at the end of production

8. Rev. 8 Security Found in the audit

   The tests that did not exist

   Complete management platform with an AI assistant

   What I found

   The documentation promised automated tests on every release: there were none in the code. A working copy was connected to the production database

   Outcome

   Risks documented by priority, with an action plan

9. Rev. 9 Security Resolved

   The code in production was not the one in the repository

   Management app with connected devices and a new panel built with Lovable

   What I found

   An external service was configured against a test environment. The code on the server was newer than the repository, and key custody was undocumented

   Outcome

   Devices integrated into the new panel

10. Rev. 10 Security Resolved

    The prototype ran on fake data

    Company management app born on Lovable

    What I found

    The prototype was convincing, but it ran on fake data with an architecture unfit for production. Candidates’ personal data had no protected storage

    Outcome

    Backend with APIs and tests, installable mobile app, candidates’ data in private storage with automatic deletion

11. Rev. 11 Resolved

    Slow, and spending money even when idle

    AI platform that collects and classifies data from several sources

    What I found

    APIs downloading far more data than needed and a filter that found nothing. Scheduled jobs making AI calls at regular intervals, running even while the project was on hold

    Outcome

    Leaner APIs, filter fixed, hidden costs flagged

12. Rev. 12 Resolved

    Every save ended up in production

    Management app with users, payments and invoicing

    What I found

    Every change pushed to the main branch went straight to production, with no staging environment. No documented database backup

    Outcome

    Integration with electronic invoicing, with credentials kept on the server only and never in the browser

13. Rev. 13 Resolved

    Invisible to Google

    Websites and web apps born on Lovable, including the Ailligence site

    What I found

    The content was built in the browser: search engines received an almost empty page and link previews on social media stayed blank

    Outcome

    Titles, descriptions and content of the public pages rendered on the server

14. Rev. 14 Resolved

    Beautiful, but the data lived in the browser

    Management web app born on Lovable

    What I found

    The app looked complete, but the data was saved only in the user’s browser, with no backend or database. Switch computer and everything was gone

    Outcome

    Backend with APIs, authentication and database, and the move from demo data to real data

15. Rev. 15 Resolved

    From prototype to app in the stores

    Client area with a mobile app, front end born on Lovable

    What I found

    The prototype had to be connected to the company CRM and brought to iOS and Android. Along the way, an iPhone build was published pointing at a development address instead of the real server

    Outcome

    API gateway to the CRM with automatic retries and protection when it does not respond, payments on a page hosted by the card network, real-time notifications, apps in the stores and a check that blocks the build if the address is wrong

16. Rev. 16 Resolved

    The newspaper Google News could not see

    News website born on Lovable

    What I found

    The editorial team could not manage the site, and it was not built to be found by search engines

    Outcome

    Backend with a CMS for the editorial team, role-based permissions, full-text search and a Google News sitemap

17. Rev. 17 Resolved

    Supabase swamped by requests

    Management app built with Lovable and Supabase

    What I found

    One component kept re-rendering and every page repeated the same database calls: a handful of users was enough to push Supabase to its plan limit, and the app slowed down until it froze

    Outcome

    Fewer, batched calls, cached data, real-time only where needed: usage back within the plan

No names: confidentiality applies to the clients who came before you too.

How it works

No sales call: it starts with a form, and the video call comes after the report.

1. 1

   You fill in the form

   What you built, with which tool, what worries you.

2. 2

   I reply within 1 day

   I confirm whether I can help and which package you need.

3. 3

   Confidentiality and access

   You sign the NDA, pay, and give me read-only access to the code.

4. 4

   You get the report

   Within the time frame of your package.

5. 5

   We talk it through

   On a video call. Then you decide what to do.

Pricing

Fixed price, agreed before I start.

If you then hire me for the fixes within 30 days, the cost of the audit is deducted.

Gross, final prices. Proper invoice.

Frequently asked questions