How to build a lead capture CRM for your business with Lovable (no coding required)

Rule of thumb: if your lead volume moves around, or the four products above are already talking to each other through a fifth, building your own pays for itself inside a year and never charges you by the response again. If you are one person still finding out whether anybody wants the thing, rent it for now and come back when a meter starts deciding your marketing for you.

* Supabase’s free tier is a building tier rather than a running-a-business tier: 500 MB of database, 2 active projects, and a pause after a week without activity. That pause matters more here than on most apps, because the form embedded on your website goes down with the project, and a lead that arrives while nobody was signed in is not queued anywhere. The Pro plan, from $25/mo, keeps it awake.

Both columns end the same way: the code is yours, nothing charges you by the response, and the thousandth lead in a month costs exactly what the first one did. The difference is whose hours go in: a developer’s, invoiced at $13k-$53k, or your own, spent describing the app and checking what comes back.

Prices and rates from supabase.com, developex.com and docs.lovable.dev, checked August 2026.

Only the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.

1. 01

   Start the project and tell it what you are building

   The first message sets the vocabulary for everything after it. Say what the app is for and what your nouns mean before you ask for a single screen.

   PromptOpen the projectCopy

   I am building a lead capture CRM. Leads are people who might buy from us, forms are what collect them, a submission is one raw set of answers from a form, an activity is anything that happened to a lead, and a rep is a salesperson who owns leads. Set up the project with React, Tailwind and Supabase, and hold to those words for the rest of this build. Do not create any tables yet, just tell me the shape you would use so I can correct it first.

   Asking for the shape before the tables costs one message and saves the rename that otherwise runs through every screen.

2. 02

   Have it design the tables

   Lovable connects your Supabase project and designs the tables in the same chat, so this is one message rather than a separate database exercise. Read the shape it proposes before saying yes.

   PromptSet up your recordsCopy

   Connect my Supabase project and create the tables. Leads: name, email, company, phone, source (form, chat, import or manual), status (new, contacted, qualified, converted or rejected), a score, and the rep it is assigned to. Forms: title, slug, published flag, and its fields stored as JSON. Submissions: the raw answers, the form they came from, and the lead they created. Activities: a lead, a type and a note. Every table gets a created_at. Show me the columns before you create anything.

   Keeping the raw submission beside the lead it created is what lets you fix a bad field mapping later without losing what somebody actually typed.

3. 03

   Add sign-in and the two roles

   An admin who runs everything and a rep who works their own leads. Both exist before the next step, because the next step is written entirely in terms of them.

   PromptAdd logins and the two rolesCopy

   Add Supabase authentication with email and password: sign-up, login, logout, a session that survives a refresh, and signed-out visitors sent to the login page. Then add two roles, admin and rep, stored in their own user_roles table rather than in the user's auth metadata, because users can edit their own metadata and would be able to make themselves an admin. Add a SECURITY DEFINER has_role function so the access rules in the next step can use it safely.

   Storing a role where the user can edit it is the classic Supabase privilege-escalation hole, and this prompt is written to close it.

4. 04

   Open the public door, and only that door

   This is where a lead CRM stops looking like every other app. Somebody with no account has to be able to create a row and must not be able to read one. Ask for the two rules separately, and test the second one yourself.

   PromptLock the tables to the two rolesCopy

   Turn on row-level security for leads, forms, submissions and activities. A rep can read, add and edit only the leads assigned to them. An admin, checked through has_role, reaches all of them. Put an explicit check on every insert and update, so no one can file a row under another rep’s name or move an existing lead onto them.

   PromptLet a stranger write one row and read nothingCopy

   Now the public part. Allow an anonymous visitor to insert into submissions and do nothing else: no reading, no editing, no deleting, and no anonymous access to leads, activities, form content or users. Create the lead itself from the submission in an edge function rather than from the browser. Then tell me exactly how to check it in a private window with no account: submitting the form should work, and asking for the leads table should come back empty rather than with an error I could mistake for a network problem.

   Get this backwards and every lead you have ever collected is readable by anyone who opens the browser tools on your own form.

5. 05

   Build the form builder, the embed and the routing

   The part your visitors meet, and the rule that decides who calls them. Ask for one at a time and look at the preview after each, because this is where a chat build is fastest and easiest to steer.

   PromptBuild the form builder and its embedCopy

   Build the form builder: a screen where I add fields (text, email, phone, select, checkbox), mark which are required, and publish. Add a public page at /embed/forms/:slug that shows only the form, with no navigation and no app chrome, so it sits inside somebody else’s page without looking borrowed. Add an Embed tab on each form with the iframe snippet to copy. Submitting writes a submission and shows a thank-you state rather than a blank screen.

   PromptAssign each new lead to a repCopy

   Add an edge function that turns a new submission into a lead: map the answers onto the lead fields, set the source, check whether that email is already a lead and add an activity to the existing one instead of creating a duplicate, then assign it to the next active rep in turn. Make the assignment mode a setting with round-robin and unassigned as its options, and record each assignment as an activity so I can see who got what and when.

   Round-robin is one rule among several. Building it as a setting is what lets you switch to territory or product later without touching the capture path.

6. 06
   Destination

   Try it as a stranger, then publish

   Open the preview address in another browser with no session and follow one lead all the way through. When it holds up, publishing is a button in the same tab, and everything after that is one more message.

   PromptWalk it end to end and plan what is nextCopy

   Walk me through testing the whole flow. Signed in as an admin, publish a form. Then open its embed address in a private window with no account and submit it. Confirm the lead appears with the right source, that a rep was assigned, and that submitting the same email twice makes one lead with two activities rather than two leads. Sign in as that rep and confirm they see only their own. Fix what does not hold up, then list what to add next (live chat, campaign sequences, AI enrichment) in priority order.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks everything above it: the secret key that bypasses your access rules stays on the server. If it ever turns up in the app, in a repository, or pasted into a support ticket, rotate it in the Supabase dashboard before you do anything else.

One button, and the app you have been previewing is live.

Do the multiplication before you pick. A four-step sequence sent to a thousand new leads is four thousand messages, which sits inside Resend’s free tier and costs about forty cents on SES, so at that size the price is not what you are choosing between. What you are choosing is who takes the blame when mail stops arriving. Volume changes the answer, and it changes it slowly: at a hundred thousand a month the same four steps cost $10 on SES and about $90 elsewhere.

Add one server-side "ai" function that talks to your AI provider, with the key held in server secrets and never anywhere the browser can reach. Then put an "Enrich" action on the lead view that sends the email domain and any fields we already have, asks for the company name, industry and rough size, writes them onto the lead, and marks personal-email domains as not enrichable rather than guessing. This runs on every new lead, so use the cheapest and fastest model tier.

Add a "Score" action that sends the lead’s fields, its source, and its recent activity to the ai function, asks for a 0-100 score and a one-line reason, stores both on the lead, and colours the badge by band. Sort the leads list by score by default and let a rep override it. Scoring runs on every lead too, so keep it on the same cheap, fast tier as enrichment.

Add a "Draft reply" button on the lead view that sends what the lead submitted, the page or form it came from, and any chat transcript to the ai function, and returns a short editable first email in the rep’s own tone. Show it in a modal with copy and insert actions, and never send it automatically. This is everyday writing, so use a mid-tier model rather than the cheapest or the strongest.

You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.