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

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   Write AGENTS.md before anything is scaffolded

   Codex reads AGENTS.md at the start of every task, so writing it first means your vocabulary is loaded before there is any code to be inconsistent with. The scaffold follows in the same task.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root. The stack is React 18, Vite, TypeScript, Tailwind and the Supabase JS client, and this project is a lead capture CRM, so fix the vocabulary you should hold to (lead, form, submission, activity, rep, source, status) along with any conventions you want followed. You load that file automatically at the start of every later task, so nothing in it needs repeating by hand. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots before you stop.

   Writing AGENTS.md first is what stops task five inventing a second name for what task two already called a submission.

2. 02

   Have Codex write the schema, and read the SQL before it runs

   Four tables carry the product. Ask to see the migration before it is applied, because this is the one shape that is expensive to change once real leads exist.

   PromptSet up your recordsCopy

   Write the Supabase migrations for a lead capture CRM. A lead is a person who might buy: name, email, company, phone, a source (form, chat, import or manual), a status (new, contacted, qualified, converted or rejected), a score, and the rep it is assigned to. A form is what collects them: title, slug, published flag, and its fields as JSON. A submission is one raw set of answers, linked to its form and to the lead it produced. An activity is anything that happened to a lead, with a type and a note. Every table gets a created_at. Print the SQL for me before it runs, and regenerate the TypeScript types once it is applied.

   A submission and a lead are two different things: one is what somebody typed, the other is who you decided they are. Collapsing them is the modelling mistake that costs a rewrite.

3. 03

   Narrow permissions, then wire up sign-in and roles

   This task touches authentication, which is exactly the kind of change worth scoping Codex down for rather than leaving the wider settings you would use for routine edits.

   PromptAdd logins and the two rolesCopy

   This task touches authentication, so narrow your permissions to it rather than keeping whatever you had set for routine edits. Set up Supabase Auth with email and password: sign-up, login, logout, a session that survives a refresh, a useUser hook, and a guard sending signed-out visitors to /login while the public form route stays open to anyone. Then create an app_role enum with 'admin' and 'rep', and a user_roles table linking a user_id to a role. Roles belong in that table and never on the user record itself, because a user can edit their own metadata and would simply grant themselves admin. Add a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) so the next task's policies can call it without recursing.

   Everything in the next task is written against these two roles, so they come before the rules rather than after.

4. 04

   Read this diff properly: it is the one holding your list

   Of every diff in this build, this is the one to actually read. A stranger with no account has to be able to create a row and must not be able to read one, and those are two separate policies that have to be right at the same time.

   PromptLock the tables to the two rolesCopy

   Turn on row-level security for leads, forms, submissions and activities. A rep may select, insert and update only rows where assigned_to = auth.uid(). An admin, checked through has_role, reaches every row. Every insert and update needs its own WITH CHECK clause, so no one can file a row under another rep’s name or move an existing lead onto them. One migration, and show me the SQL before it runs.

   PromptLet a stranger write one row and read nothingCopy

   Now the public path, which is the whole point of this app. Add a policy letting the anonymous role INSERT into submissions and do nothing else: no select, no update, no delete, and no anonymous reach into leads, activities, form content or user data. A server-side function turns the submission into a lead, so the browser never writes to leads directly. Then walk me through proving it with no session at all: submitting the form should succeed, and a request for the leads table should come back empty rather than with an error I could mistake for a network fault.

   Get this backwards and everyone who ever filled in your form is readable by anyone who opens the browser tools on it.

5. 05

   Point Codex at the form builder, a few files at a time

   The builder, the embedded form, and the rule that assigns what comes through it. Codex only needs the files each piece touches rather than the whole project.

   PromptBuild the form builder and its embedCopy

   Build the form builder on top of what exists. A screen where I add fields (text, email, phone, select, checkbox), mark which are required, and publish. A public route at /embed/forms/:slug rendering only the form, with no navigation and no app chrome, so it looks like part of whatever page it lands on. An Embed tab on each form showing the iframe snippet to paste elsewhere. Submitting writes a submission through the anonymous policy from the last task and shows a thank-you state rather than a blank screen. Keep the data access in typed hooks rather than spread through the components.

   PromptAssign each new lead to a repCopy

   Add the server-side function that turns a submission into a lead: map the answers onto the lead fields, set the source, check whether that email already exists and attach an activity to the existing lead 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

   Walk it end to end, then hand the next piece to a cloud run

   Test it as a stranger first, from a browser with no session. After that, live chat and the campaign sequences are long, well-scoped pieces of work, reasonable ones to hand to a cloud task while you do something else, as long as you read the diff before it merges.

   PromptWalk it end to end and plan what is nextCopy

   Run the app and take it end to end yourself: sign in as an admin, publish a form, then open its embed URL in a private window with no session and submit it. Confirm the lead appears with the right source, that a rep was assigned, and that the same email submitted twice becomes one lead with two activities rather than two leads. Sign in as that rep and confirm they see their own leads and nobody else’s. Fix what does not hold up, then list what to build next (live chat, campaign sequences, AI enrichment) in priority order, and tell me which of them are self-contained enough to hand you as a single cloud task.

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.

Any of them will serve this app, and your AI coding tool can wire up whichever you pick. Two things are worth checking before the price. The licence comes first, because free does not always mean free for business use, and Vercel’s Hobby tier says plainly that it is for personal projects. The second is in the warning below, and it is the one that catches people out.

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.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.