How to build a lead capture CRM for your business with Replit (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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   Start the workspace and fix the vocabulary

   No installs and no separate database account. The first message is worth spending on what your words mean, because every later one is read against it.

   PromptSet up the projectCopy

   Start a React, Vite and TypeScript project with Tailwind. This is a lead capture CRM, so hold to these words throughout: a lead is a person who might buy, a form is what collects them, a submission is one raw set of answers, an activity is anything that happened to a lead, and a rep is a salesperson who owns leads. Do not create a database yet. Get the app booting and tell me the table shape you would use so I can correct it first.

   Asking for the shape before the database costs one message and saves a rename that would otherwise run through every screen.

2. 02

   Ask for a database, and say what goes in it

   This is the step that differs most from the other five guides: the database is provisioned inside the workspace on request, so there is no second account to open and nothing to copy between dashboards.

   PromptProvision the database and set up your recordsCopy

   Add a Postgres database to this app 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 fields 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 SQL before you run it.

   The database lives in this workspace rather than in a separate service, so the connection details go into Secrets rather than into a file you copy across.

3. 03

   Add sign-in and the two roles

   A Replit build runs its own small backend, so sessions live on your server rather than with a hosted identity service. An admin who runs everything and a rep who works their own leads.

   PromptAdd logins and the two rolesCopy

   Add email and password sign-in to the app: sign-up, login, logout, a session that survives a refresh, and a guard that sends signed-out visitors to the login page while leaving the public form route reachable by anyone. Add two roles, admin and rep, in their own table rather than on the user record itself, and a server-side helper that answers whether a given user holds a given role, so the rules in the next step can rely on it. Put the session secret in Secrets rather than in the code.

   The guard has to let the embedded form through. Say so, because a guard added later is the usual way that page stops working.

4. 04

   Open the public door, and only that door

   The awkward requirement at the centre of this app. A stranger with no account has to create a row and must not read one, and on this stack that is checked twice: once by your server and once by the database.

   PromptLock the tables to the two rolesCopy

   Turn on row-level security for leads, forms, submissions and activities, and have the server announce who is asking at the start of each request so the policies can be written against it. A rep may read, add and edit only the leads assigned to them. An admin 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. Every route must rely on these rules rather than filtering in the page.

   PromptLet a stranger write one row and read nothingCopy

   Now the public path. Add one unauthenticated route that accepts a form submission, writes a submission row, and returns nothing but success. No unauthenticated route may read leads, activities, form content or users, and the browser must never talk to the database directly. Create the lead from the submission on the server. Then show me how to prove it with no session at all: submitting should succeed, and any attempt to read leads should come back empty rather than with an error I could mistake for a network problem.

   Get this backwards and everyone who ever filled in your form is readable by anyone who finds the route.

5. 05

   Build the form builder, the embed and the routing

   What your visitors meet, and the rule that decides who calls them. Both in this step, because a form nobody owns is a form nobody answers.

   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 route at /embed/forms/:slug rendering only that form, with no navigation and no app chrome, plus an Embed tab on each form showing the iframe snippet to paste onto another site. Submitting posts to the unauthenticated route from the last prompt and shows a thank-you state rather than a blank screen.

   PromptAssign each new lead to a repCopy

   Add the server-side step 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 attach an activity to the existing one rather than creating a duplicate, then assign it to the next active rep in turn. Make the assignment mode a setting whose options are round-robin and unassigned, and record every assignment as an activity so the history shows who got what and when.

   Building the rule as a setting rather than as code is what lets you move to territory or product routing later without reopening the capture path.

6. 06
   Destination

   Try it as a stranger, then publish

   Test it from another browser with no session, on the workspace address, before you publish. Then look hard at who the published app answers to, because a form is meant to be public and the rest of it is not.

   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 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. Then explain what Publishing exposes and how to keep the app itself private while the embedded form stays open to anyone, and finish with what to build next in priority order.

One rule outranks everything above it: anything that would let a caller bypass your access rules stays in Secrets and on the server. If a key ever turns up in the app, in the repository, or pasted into a support ticket, rotate it before you do anything else.

All four are Replit, so the question is shape rather than supplier. Most people want Autoscale, moving to Reserved VM once the traffic is worth paying to keep warm, with Scheduled kept in mind for campaign steps that come due overnight. Before that first release, look hard at one thing Publishing controls: who the app answers to. This is the rare app where part of it has to be open to everybody and the rest of it must not be.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.