← services

AI-built app check.
Before real users find it.

Your app was built with Lovable, Bolt, Replit, Cursor or Base44. It works in the demo. Then real people sign up, and every fix breaks something else.

I spend two working days going through it: who can read your data, how logins and payments hold up, what is actually deployed, and what happens with real users. You get a report you can act on.

€350 fixed, for the check

Book the check Book a 15-min intro call

app check · report
  1. 01Data accessCan a visitor who isn't logged in, or a second customer, read rows that aren't theirs?
  2. 02KeysIs a secret key shipped to the browser, where anyone can copy it?
  3. 03LoginsCan someone make themselves an admin, or reset a password that isn't theirs?
  4. 04PaymentsDoes a plan switch on because a page loaded, or because the payment was confirmed?
  5. 05DeploysIs what's live the code you think it is, and has the backup ever been restored?
  6. 06Real usersWhat happens with two people at once, a slow phone, or a form filled in wrong?

Each finding

how to reproduce it
the exact steps
how serious it is
critical · high · medium · low
what the fix costs
a price per item
The questions the check asks, and how every finding is written up. No real app's findings are shown here.

// what gets checked

The parts where wrong is expensive.

These problems all look fine in the demo. They show up when somebody uses the app in a way the demo didn't.

  1. 01 Who can read your data

    Tools like Lovable and Bolt often put your data in Supabase, where access rules decide who sees which rows. I test them as a visitor who isn't logged in and as a second customer, against the database directly, not only through your screens.

  2. 02 Keys in the browser

    Some keys are meant to be public; others give full access to your database, your email sender or your payment account. I check which ones your app sends to every visitor.

  3. 03 Logins and roles

    Password resets, sessions, and the flag that makes someone an admin. A role stored where the browser can write it reads fine in a code review and fails the first time someone edits it.

  4. 04 Payments

    Whether a paid plan turns on only after the payment provider confirms it, or whenever someone lands on the "thank you" page. Also refunds, cancellations and what happens when a card fails.

  5. 05 Deploys and backups

    What's live compared with what's in the code, which settings production actually uses, and whether there is a backup that has been restored at least once.

  6. 06 Real users

    Two people editing the same thing, a slow phone, a form filled in wrong, an error page that shows your internals. The everyday things a demo never tries.

// what you get

A report you can act on.

  1. Two working days, then the report. Every finding comes with the steps to reproduce it, how serious it is, and a fixed price to fix it, or what it takes to find out where the cause isn't clear yet. You can check each one yourself, or hand it to whoever builds next.
  2. You choose what gets fixed. I fix any item at its price from the report, or by the day at €250. Where a fix can be tested in code, the test stays in your code, so you can check it's still fixed later.
  3. After that, if you want it. Changes and new features once it's solid, booked by the day, like ongoing work on any other build.

What I need from you: access to the code, and a login on the app. If something can only be tested in production, we agree how before I touch it.

// where this comes from

I checked my own first.

The list above comes from my own product. I built iziwerk, a multi-tenant app with accounts, payments and documents, by directing AI. After launch I ran an adversarial audit on it, where every finding counted as wrong until it could be shown. It found the kind of problem that reads fine in a demo: a plan change that could charge twice, an account deletion the site promised and hadn't built, a delete path nothing guarded. A twelve-pass fix program followed, with the tests left in the code. The full record.

The same rules apply to everything I ship: how I check work before it ships.

// the fine print

Your app, and only yours.

  • I only check apps you own, or that you have written permission to have tested. Accessing somebody else's system without authorisation is an offence under the UK's Computer Misuse Act 1990, and under similar laws elsewhere, such as the US Computer Fraud and Abuse Act. Written permission is how the check records that its access was authorised, so it comes first.
  • It's a check, not a certificate. The report covers what I tested in those two days. It's not a penetration-test certificate or a compliance sign-off.
  • Small apps. This is for apps built with AI tools by a founder or a small team. A large codebase where nobody can say what it should do is a different job, and usually not one I take.

Tell me what you built and what keeps breaking. If the check isn't what you need, I'll say so on the call.

The check is a fixed €350. Fixes are priced per item in the report, so you know the cost before anything is fixed. All the offers

Book the check Book a 15-min intro call

Building it yourself? What to check in an app built with AI · Is vibe coding bad?