AgeBridge
AgeBridge Guided Project · AdvancedAbout 14 hoursPro

Lead-scoring app with a dashboard

A public form anyone can fill in, a private dashboard only you can see, and a score with a written reason on every lead, decided on the server.

What you'll have at the end

A published app with email login, a public form address per account, a Supabase table where one account can never read another's leads, and an Edge Function that scores every submission with Claude before it is stored.

What it proves

deployed productauth and access rulesserver-side scoring

Accounts to create

LovableWeb apps from a description, with Supabase built inDocsFree offerSupabasePostgres, auth and vectors, free tierDocsFree offerClaude APIThe model behind the steps; pay per useDocsFree offer

What it costs: Free tiers: one Lovable project and one Supabase project, plus a few cents of model usage per scored lead.

Have this ready

  • A made-up company you collect leads for, in one line
  • A terminal with Node 20 or newer, for the Supabase command line
  • A second email address, to prove one account cannot read another's leads
  • No separate hosting account: Lovable publishes the app itself

How it fits together

Public form /f/:idno login, one owner per addressEdge Function score-leadthe only thing that writesClaudescore 0-100 and one written reasonleads tablewritten with the service keyRow level securityyou read your own rows onlyDashboardsorted by score, with the reason
  1. Public form /f/:id: no login, one owner per address
  2. Edge Function score-lead: the only thing that writes
  3. Claude: score 0-100 and one written reason
  4. leads table: written with the service key
  5. Row level security: you read your own rows only
  6. Dashboard: sorted by score, with the reason

The steps

  1. 1. The app shell, with login

    A working app with an email login, an empty dashboard and a public form page. Nothing is scored and nothing is stored yet, but every screen you need exists.

  2. 2. The table, and the rule that protects it

    One table and the access rules around it. This is the part a client cannot see and the part that matters most: one account must never be able to read another's leads.

  3. 3. The function that scores and writes

    The only thing in this build allowed to write a lead. It takes a public submission, asks Claude for a score and a reason, and stores the row with the owner it was addressed to.

  4. 4. The form reaches the function

    One lead travelling the whole way: a stranger's form, a function, a model, a row. Until this works, the dashboard has nothing to show.

  5. 5. The dashboard, and proof of the access rule

    The dashboard doing the job a person came for, and the test that separates a toy from a product: a second account that cannot read your leads even though it is looking at the same table.

  6. 6. Publish, and hand over two addresses

    The two addresses that make this a deliverable: one a stranger fills in, one only the owner can open. Both on the published app, not on a preview.