How to build a CRM with OpenAI Codex

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 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 conventions are loaded before there is any code to be inconsistent with. The scaffold comes second, 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 CRM, so fix the vocabulary you should keep consistent (contacts, leads, deals, stages, activities) along with any conventions you want held to. You load that file automatically at the start of every later task, so nothing in it needs repeating by hand. Then scaffold the project itself: 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 from inventing its own name for what task two already called a deal.

2. 02

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

   Three tables carry the whole product. Ask to see the migration before it is applied. This is the one shape that is expensive to change once records exist.

   PromptSet up your recordsCopy

   Write the Supabase migrations for a CRM. Contacts are the people: name, email, company. Leads are potential customers, each linked to a contact and carrying a source and a status. Deals are the opportunities, each linked to a lead and carrying a value, a stage, and an expected close date. Give every table a user_id owner column and a created_at. Print the SQL for me before it runs, and regenerate the TypeScript types once it is applied.

   A contact is a person, a lead is an opportunity to sell to them, and a deal is the money. Collapsing any two of those is the modelling mistake that costs a rewrite.

3. 03

   Narrow permissions, then wire up sign-in

   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 loginsCopy

   This task touches authentication, so narrow your permissions to just this one rather than keeping whatever you had set for routine edits. Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a useUser hook, and a route guard that sends signed-out visitors to /login. Keep the screens minimal for now. We will design them properly once the data is behind them.

   Everything after this step assumes there is a signed-in user to attach records to, so it comes before the screens rather than after.

4. 04

   Read this diff properly: it is the one protecting customer data

   Roles, then the database rules that enforce them. Of every diff in this build, this is the one to actually read rather than approve on trust.

   PromptAdd rolesCopy

   Create an app_role enum with 'admin' and 'member', and a user_roles table linking a user_id to a role. Keep roles in that table rather than in the user's auth metadata, which the user can edit themselves. A role stored there would let anyone promote themselves to admin. Add a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) that reads user_roles, so the policies in the next task can call it without recursing. One migration, and show me the SQL before it runs.

   Roles in user metadata is the classic Supabase privilege-escalation hole. This prompt exists to avoid it.

   PromptLock the data to those rolesCopy

   Turn on row-level security for contacts, leads, and deals. A member may select, insert, update, and delete only rows where user_id = auth.uid(). An admin, checked through has_role, reaches every row. Give every insert and update an explicit WITH CHECK clause, so nobody can create a row owned by someone else or move an existing one onto another user. Put the policies in a migration, then walk me through proving it: a second member reading the first member's records should come back empty, an admin should see both, and a member should be refused when inserting a row assigned to anyone but themselves.

   Skip this and every signed-in user can read every record, however carefully the screens filter.

5. 05

   Point Codex at the screens, a few files at a time

   The list, the record view, the forms, and the board are what your team looks at all day. Codex only needs the files each screen touches, not the whole project.

   PromptBuild the screensCopy

   Now the screens, on top of what is already there. A searchable contacts list. A detail view for a lead or a deal showing its fields and a timeline of activity. Create-and-edit forms validated with zod and react-hook-form, so a half-filled record cannot be saved. And a drag-and-drop board for deals where moving a card writes the new stage straight back to Supabase. Keep the data access in typed hooks rather than spread through the components.

6. 06
   Destination

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

   Click through the whole flow yourself first. After that, the dashboard and the CSV import are long, well-scoped pieces of work, reasonable ones to hand to a cloud run while you do something else, provided you read the diff before it merges.

   PromptTry it and plan what’s nextCopy

   Run the app and take it end to end yourself: sign up, add a contact, create a lead and then a deal against it, and drag that deal across the pipeline. Fix whatever does not hold up. Then list what to build next (a dashboard, CSV import, an AI helper) in priority order, and tell me which of them are self-contained enough to hand you as a single cloud task rather than working through interactively.

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.

All of them will serve this app, and your AI coding tool can wire up whichever you pick. The thing worth checking first is not the price but the licence: free does not automatically mean free for *business* use, and Vercel’s Hobby tier says plainly that it is for personal projects. An internal CRM is company use even if only three people ever sign in.

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.

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.