How to build a CRM with Bolt

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 bolt.new, checked August 2026.

The GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.

1. 01

   Create the repository, then import it

   Bolt has no upload button, so the project has to exist on GitHub before Bolt can open it. Create a private repository, import it, then set the ground rules in your first message.

   PromptSet the project up after importingCopy

   This project is a CRM. Set it up as React 18 + Vite + TypeScript with Tailwind, and keep this vocabulary consistent everywhere from here on: contacts, leads, deals, stages, activities. Note that we will add a database in the next step and every screen after that should read and write real data rather than placeholders.

   Keep the repository private. Bolt commits to it automatically as you build, and a CRM holding customer records has no business being public.

2. 02

   Talk the schema through in Plan Mode before it is written

   The data model is the one thing that is expensive to change later, so use Plan Mode to agree it before Bolt writes a line, then connect the database and have it built.

   PromptSet up your recordsCopy

   Use Plan Mode for this one. I need the database for a CRM. Contacts are people, with a name, an email, and a company, and a contact exists independently of any deal. Leads are potential customers: each 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. Every table needs an owner column for the person it belongs to and a created-at timestamp. Talk me through the plan first, then connect a database and build it.

   Plan Mode costs a message and can save a rebuild. The schema is exactly the change worth spending it on.

3. 03

   Clear the context, then add sign-in

   Authentication has nothing to do with the schema conversation you just had, so clear the context first. Bolt reloads the whole project each message, and a clean slate makes this one cheaper.

   PromptAdd loginsCopy

   Add authentication: email-and-password sign-up, login, logout, a persisted session, and a profile row per person, with signed-out visitors sent to the login screen instead of an empty dashboard. Keep the screens plain for now. We will design them once there is real data behind them.

   Clearing the context between unrelated features is Bolt’s own advice, and it is the single easiest way to slow the token burn.

4. 04

   Point one prompt at the database layer and lock it down

   Name the layer rather than letting the prompt range over the whole project. Then read what it produces. This is the step that keeps one rep out of another rep’s pipeline.

   PromptAdd roles and lock the data to themCopy

   Working on the database layer only: add two roles, admin and member, kept in their own table rather than on the user account, because anything on the account is editable by the person it belongs to, plus a helper the access rules can call without calling back into themselves. Then turn on row-level security for contacts, leads, and deals: a member reads and changes only their own rows, an admin reaches every row, and every insert and update carries an explicit check that the new row is not being assigned to someone else. Show me how to verify a second member gets nothing back when querying the first member’s records.

   Naming the layer keeps the prompt narrow, which Bolt charges you less for and which makes the result easier to check.

5. 05

   Build the records and the board, checking the preview between them

   Two prompts, and a look at the live preview after each. The preview is the running app, so what you click is what your team would click.

   PromptBuild the lists and formsCopy

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

   PromptBuild the pipeline boardCopy

   Then the pipeline: a board of deals with a column per stage, drag-and-drop between the columns, the new stage written to the database the moment a card lands, and a running total of deal value per column.

6. 06
   Destination

   Click the whole flow through, then publish

   Click the whole flow through from two accounts, then publish, to Bolt’s own hosting by default, or to Netlify if you would rather keep the domain there.

   PromptTry it and publishCopy

   Walk me through the full flow in the preview: sign up, add a contact, create a lead and then a deal against it, drag the deal across the pipeline, and check from a second account that neither person can read the other’s records. Fix anything that breaks, then publish it and list 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.

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.

Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.