How to build a CRM with Claude Code

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 claude.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 Claude Code runs the commands.

1. 01

   Get the project running

   Boot up an empty app wired to your database, and hand Claude Code a short notes file so it keeps your conventions straight from here on. One prompt covers the whole setup.

   PromptSet up the projectCopy

   Scaffold a new React 18 + Vite + TypeScript project, add Tailwind and the Supabase JS client, then wire it to read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, putting .env straight into .gitignore in that same step so neither value ever reaches GitHub. Put a typed Supabase client under src/lib, then write a short CLAUDE.md that describes this CRM’s stack and conventions so later edits stay consistent with it.

   Sets up the project Claude Code will keep building on, plus a memory of its conventions.

2. 02

   Decide what you’ll track

   Tell Claude Code the things your CRM holds: people (contacts), potential customers (leads), and deals. It sets up where each one is stored. This is the shape of your CRM.

   PromptSet up your recordsCopy

   Create the CRM data model as Supabase migrations: contacts (name, email, company), leads (linked to a contact, with source and status), and deals (linked to a lead, with value, stage, and close date). Give every table a user_id owner and created_at. Write the migration SQL, let me review it, apply it, then regenerate the TypeScript types.

   Sets up where each kind of record lives, in a way that’s easy to change later.

3. 03

   Let people log in

   Add sign-up and login so only the right people can get in. Everything else sits behind this.

   PromptAdd loginsCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a useUser hook, and a route guard that redirects signed-out visitors to /login. Keep the screens minimal for now.

4. 04

   Set up roles, and lock the data to them

   Decide who can see what, then let the database enforce it. Members work their own records. Admins see the whole team, which is what makes assignment, a manager view, and a team dashboard possible later. Far easier to set up now than to bolt on afterwards.

   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, never in the user's auth metadata, which users can edit themselves, so a role stored there would let anyone make themselves an admin. Add a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) that reads user_roles, so the policies in the next prompt can call it without recursing. Put it in a migration.

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

   PromptLock the data to those rolesCopy

   Enable row-level security on contacts, leads, and deals. Add policies so a member can select, insert, update, and delete only rows where user_id = auth.uid(), while an admin, checked with has_role, can reach every row. Name the WITH CHECK clause explicitly on insert and update, so nobody can create a row owned by someone else or move one onto another user. Put the policies in a migration, then show me how to verify that a second member cannot read the first member's records, that an admin can, and that a member cannot insert a row assigned to anyone but themselves.

   Skip this and anyone could read everyone’s data.

5. 05

   Build the main screens

   Now the CRM you actually use: a searchable list, a detail page, forms to add and edit records, and a drag-and-drop board to move deals through your stages. This is the core.

   PromptBuild the screensCopy

   Build the core screens against these tables: a searchable contacts list, a lead/deal detail view, create-and-edit forms with zod + react-hook-form validation, and a drag-and-drop Kanban board for deals where moving a card updates its stage in Supabase. Keep all data access in typed hooks.

6. 06
   Destination

   Try it and keep adding

   Open the app and click through it (sign up, add a contact, move a deal) and fix anything that’s off. From here, every new feature (charts, importing your spreadsheet, an AI helper) is just one more prompt.

   PromptTry it and plan what’s nextCopy

   Run the app and walk me through testing the full flow: sign up, add a contact, create a lead and a deal, then move it across the pipeline. Fix anything that breaks, then list the next features to add (dashboard, CSV import, 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.

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 picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.