Skip to main content

For founders who never wrote their own auth code

Your Lovable App Has a Bot Problem

AI builders ship you an app, not a bouncer. Find the fake accounts that got in while you were shipping.

Check My App

Reads the auth table only. Never write access.

What a finished report looks like

Illustrative sample — not customer data

  • q9v4@yopmail.comDisposable domain
  • lena@brightfern.studioReal
  • chris+9x2@gmail.comAlias flood — 63 from one inbox
  • t7k0@sharklasers.comBurst signup — 03:47
  • omar@tidewell.appReal
  • hb3z@dispostable.comNever activated — 0 actions
  • chris+kk4@gmail.comAlias flood — 63 from one inbox

In this sample, 903 of 2,860 accounts carry at least one flag, and the burst cluster lands at 03:47. Your own numbers will be your own.

The four detectors

Four things that give a fake account away

Bouncer does not guess at intent and does not hand you a risk score to interpret. It looks for four patterns a real person does not produce, and it names the one that applies to each account.

Disposable domain

The address belongs to a throwaway inbox service. It was never meant to receive a second email, and nobody is reading it now.

@mailinator.com

Alias flood

Many accounts built from one real inbox using plus-addressing. One person, dozens of rows, all of them counted as users.

you+7f2@gmail.com

Burst signup

A cluster of accounts created within minutes of each other, far faster than people find an app and decide to join it.

created_at, clustered

Never activated

The account was created and then did nothing at all. No sign-in, no action, not once since the day it appeared.

last_sign_in_at: null

Three steps, in this order

You grant the access. Bouncer reads it.

  1. Run one snippet in your own SQL editor

    Bouncer writes it for you. It builds a view over four columns and a role that can read only that view — you paste it into Supabase yourself, so nothing is handed over that you did not read first.

    CREATE ROLE bouncer_ro
  LOGIN PASSWORD '<you choose>';
CREATE OR REPLACE VIEW public.bouncer_users AS
  SELECT id, email, created_at, last_sign_in_at
  FROM auth.users;
REVOKE ALL ON public.bouncer_users
  FROM PUBLIC, anon, authenticated;
GRANT USAGE ON SCHEMA public TO bouncer_ro;
GRANT SELECT ON public.bouncer_users TO bouncer_ro;

  2. Paste the connection string back

    Bouncer checks the credential really is read-only, turns down anything over-privileged with a specific reason, and encrypts what it stores.

  3. Read the report

    How many accounts you have, how many are flagged, which reason applies to each one, and the SQL to quarantine them when you are ready.

The boundary

What Bouncer never touches

Never your customer data

The grant names four columns on one table. Bouncer cannot read your orders, your messages or your profiles, because nothing else was ever granted.

Never write access

SELECT only. Bouncer cannot create, update or delete a row in your database, and it never runs the quarantine SQL for you.

Gone the moment you say so

Disconnecting destroys the stored credential and every cached account row, and confirms the deletion on screen.

Bouncer is new. There are no customer logos on this page because there are no customers to name yet — only the grant you can read before you run it, and the report it gives back.

Every day undetected costs storage, email quota and trust. Check tonight.

A security check for an app you did not hand-code.

Check My App