How to build a CRM with Lovable

Rule of thumb: if you have a handful of seats and a process that does not fit an off-the-shelf CRM, building your own pays for itself within months and never charges you again. If you need deep third-party integrations and enterprise support today, buy, then revisit once the subscription outgrows the value.

* The free Supabase tier is sized for building rather than for a team selling on it: 500 MB of database, 2 active projects, and a pause after a week of no activity, which for a CRM means your reps arriving at a dead app on Monday morning. The Pro plan, from $25/mo, keeps it awake.

Both columns end with the code belonging to you, no per-seat subscription, and the tenth rep costing exactly as much as the first: nothing. No transaction fee appears in either column, because a CRM records what a deal is worth rather than charging for it. The one place a percentage ever shows up is if you later invoice or take payment from inside the app, and the payments section below prices what that costs.

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

   Connect Supabase before you ask for a single screen

   The most common way a Lovable build goes sideways is designing screens first and adding the database later. Connect it from the chat now, and every screen after this has somewhere real to write to.

   PromptConnect the backend and set the ground rulesCopy

   Connect this project to Supabase before we build anything. Once it is linked, note the conventions for the rest of this build: this is a CRM, so we will use contacts, leads, deals, stages, and activities as the names throughout, and every screen should read and write real Supabase data rather than placeholder content.

   Connect it first and Lovable designs tables as it goes. Connect it later and you rebuild the screens that were saving nowhere.

2. 02

   Describe what you track, and keep the three things separate

   Ask for the data model in one message. Be explicit that a contact, a lead, and a deal are three different records. Described loosely, they arrive as one table you will regret.

   PromptSet up your recordsCopy

   Design the database for this CRM. Contacts are people (name, email, company) and a contact exists on their own. Leads are potential customers: each one links to a contact and carries a source and a status. Deals are the money: each links to a lead and carries a value, a stage, and an expected close date. Give every table an owner column for the user it belongs to, and a created-at timestamp. Show me the tables and how they relate before you build any screens on them.

   Say “a contact exists on their own” in the prompt. Left implicit, the three collapse into one table and every later report gets harder.

3. 03

   Bookmark this version, then add logins

   Changes to the data model and the access rules are the ones worth being able to undo in a click. Bookmark first, then ask for sign-in.

   PromptAdd loginsCopy

   Bookmark the current version first, then add authentication: email-and-password sign-up, login, logout, a persisted session, and a profile row for each person. Signed-out visitors should land on the login screen rather than an empty dashboard. Keep the screens plain for now. We will make them look right once there is real data behind them.

   Bookmarking before a change to the data model is the difference between one click back and a long scroll through history.

4. 04

   Ask for roles and access rules, then check them with the audit prompt

   This is the step that decides whether one rep can read another rep’s pipeline. Ask for it explicitly, then have Lovable read its own work back to you in simple terms.

   PromptAdd roles and lock the data to themCopy

   Add two roles, admin and member, stored in their own table rather than on the user account itself, because anything on the account can be edited by the person it belongs to. Add a helper the access rules can call to check a role without the rule calling back into itself. Then turn on row-level security for contacts, leads, and deals: a member can read and change only the rows they own, an admin can reach every row, and every insert and update needs an explicit check that the new row is not being assigned to somebody else. Then show me how to confirm that a second member gets nothing back when they query the first member’s records.

   A role kept on the user account is a role the user can edit. That is the one detail worth spelling out in the prompt.

5. 05

   Build the list and the board, previewing between them

   Two messages rather than one. The board is the screen people judge a CRM on, so give it its own turn and click through it properly.

   PromptBuild the lists and formsCopy

   Build the record side first: a searchable contacts list, a detail page for a lead or a deal showing its fields and a timeline of activity against it, and create-and-edit forms that refuse to save a half-filled record. It all has to work on a phone as well as a laptop.

   PromptBuild the pipeline boardCopy

   Now the pipeline: a board of deals with a column per stage, dragging a card between columns to move the deal, and the new stage saved to the database as soon as the card lands. Use Select elements to point me at anything you want me to adjust rather than describing where it sits.

6. 06
   Destination

   Use it as a rep would, then keep adding

   Click the whole flow through in the preview from a second account. The view your teammates get is the one you will otherwise never see.

   PromptTry it and plan what’s nextCopy

   Walk me through the whole flow in the preview: sign up, add a contact, create a lead and then a deal against it, drag that deal across the pipeline, and check from a second account that neither person can see the other’s records. Fix anything that breaks, then suggest what to add next (a dashboard, CSV import, an AI helper) 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.

The one rule that matters: never put your secret (master) key in the app or a public repo. If it ever leaks, reset it in the Supabase dashboard right away.

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

Do the multiplication before you sign up for any of them. Unlike the database and the host, this is not a monthly bill you can size but a share of your revenue, forever. Closing $200,000 of business in a year costs about $5,800 to collect through Stripe and about $10,000 through Paddle. If your customers already pay you by bank transfer against an invoice, the cheapest payment system remains the one you have.

Create a server-side "ai" function that calls an AI model with the key kept in server secrets, never in the browser. Then add a "Score this lead" action to the lead view that sends the lead’s fields and recent activity to it, asks for a 0-100 score and a one-line reason, stores both on the lead, and colours the badge by score band. Lead scoring runs on every new lead, so pick the fastest, cheapest model tier for this one.

Add a "Draft follow-up" button on the deal view that sends the deal stage, recent notes, and last-contact date to your ai function and returns a short, editable email draft in the rep’s tone. Show it in a modal with copy and insert actions. This one is everyday writing, so use a mid-tier model rather than the cheapest or the strongest.

Schedule a nightly job (either pg_cron inside Supabase or a scheduled Edge Function, tell me which you picked and why) that asks your ai function to review open deals and flag ones at risk (no activity in 14 days, time in stage past ~1.5× the stage median, or an overdue close date), then surface a "Needs attention" filter on the pipeline board. Weighing those signals against each other is the one job here worth the strongest model tier, and it only runs once a night.

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.