Build and Deploy a Lead Management CRM With Claude Code

Plan the Lead Workflow

Open your project in Claude Code, fill in the three fields, and use this prompt. It only plans — nothing changes yet.

Plan the Lead Management CRM

Tell Claude what your business does, what information you need from leads and how you normally follow up before anything is built.

I want to build a lightweight lead-management CRM for this business with Claude Code. Business: {{BUSINESS_TYPE}} Lead information we need: {{LEAD_INFORMATION}} Follow-up workflow: {{FOLLOW_UP_WORKFLOW}} Do NOT build anything yet. First inspect the existing project. If this is an empty or new project, inspect the available stack and configuration and plan the smallest appropriate implementation. 1. PUBLIC WORKFLOW Plan: 1. A visitor opens the lead form 2. The visitor enters the approved information 3. The visitor submits it 4. The visitor gets a clear confirmation 5. The lead appears in the CRM Dashboard Do not require public visitors to create accounts. 2. BUSINESS WORKFLOW Plan a proper protected CRM Dashboard. The business owner must NOT use the Supabase dashboard for normal operations. Inside the application, staff should be able to: - sign in - see their leads - create a lead manually - open a lead - update the contact and project details - change the pipeline status - write internal notes - set or change the next follow-up date - mark a lead Won - mark a lead Lost 3. LEAD DATA Plan the minimum useful model. The likely concepts are a LEAD and STAFF / ADMIN access. Use a separate notes table only if this business genuinely benefits from note history. For a simple first version a single current-notes field is often enough. Choose the smallest useful design and do not over-normalize a simple MVP. 4. PIPELINE Use a simple fixed pipeline: NEW → CONTACTED → QUALIFIED → WON or: NEW → CONTACTED → LOST Keep LOST reachable from any earlier stage. Use these names unless the approved business workflow strongly justifies different ones. Do not build user-defined pipeline configuration, and do not allow arbitrary editable status strings. 5. FOLLOW-UP The CRM needs one clear NEXT FOLLOW-UP value — a date, or a date and time if this business really works that way. Staff can change it or clear it. Do not plan calendar integration, reminders or notifications. If it can be done simply from the stored value, the dashboard may highlight follow-ups that are due today or overdue. 6. SECURITY MODEL A PUBLIC VISITOR may: - submit a new lead safely A PUBLIC VISITOR must NOT: - list leads - read leads - update a lead status - read internal notes - set a follow-up date - reach the CRM Dashboard AUTHORIZED STAFF may: - authenticate - read and manage leads - update statuses - manage notes and follow-up dates Being signed in is not the same as being staff — plan a trusted admin check. Never put a Supabase Secret or service-role key in browser code. 7. EXCLUDED FROM VERSION 1 Do not plan: email inbox integration, Gmail sync, WhatsApp, SMS, Twilio, phone calling, automatic follow-up emails, appointment booking, invoices, quotes, Stripe, subscriptions, contracts, a help desk, support tickets, marketing automation, AI lead scoring, ad attribution, analytics dashboards, multiple pipelines, complex custom fields, an automation builder, a team permissions matrix or multiple businesses. Return: CRM PLAN Public page: CRM pages: Lead fields: Pipeline: Follow-up workflow: Data model: Staff authentication: Public permissions: Staff permissions: Existing components to reuse: Features deliberately excluded: Then return exactly one: READY TO BUILD or: NEEDS A DECISION Do not modify anything yet.

What type of business is this?

Marketing agency, cleaning company, contractor, consultant...

What information should you collect from a lead?

Name, email, phone, service needed, project details...

How do you normally follow up with leads?

Call them, send a proposal, schedule another follow-up, mark won or lost...

Review the CRM plan before continuing. Keep version 1 focused on leads, follow-ups and pipeline status.

Confirm the MVP

Make sure the approved plan includes exactly this:

Lead capture

Protected CRM Dashboard

Pipeline status

Notes

Follow-up date

Won / Lost

No unnecessary CRM features

Create or Reuse Supabase

If this project is already connected to the right Supabase project, reuse it — don't create a second one.

Open Supabase

https://supabase.link/r4gdwhi

Create a new project if you don't have one Open the project's Connect panel Copy the Project URL and the Publishable key Ask Claude Code which environment variable names this project uses, then add both values locally

IMPORTANT

The browser app only needs the Project URL and the Publishable key. A Secret key belongs only in a trusted server environment, and only where one is genuinely needed — never in browser code and never committed to GitHub.

Create the CRM Data

Use this prompt in the same Claude Code session.

Create the CRM Database

Create the smallest Supabase structure for leads, follow-ups and protected staff access.

Using the approved CRM plan, create the minimum Supabase data model and access rules. Reuse correct existing structures where appropriate. Do not duplicate existing profiles or admin infrastructure. Never print secret values. 1. LEADS Create the lead model using only the approved fields. Typical fields where useful: id, name, email, phone, service or enquiry type, details, status, notes, next_follow_up_at, created_at, updated_at. Use only what the approved plan actually needs, and do not collect unnecessary personal information. 2. STATUS Use a constrained status model rather than free text. The normal values are: new contacted qualified won lost Use this project's existing database convention for constrained values. Public visitors must never choose the status during submission. 3. FOLLOW-UP DATE Store a proper date or timestamp, matching the approved UX. Never store a human string such as "next Friday" as the authoritative value. 4. PUBLIC SUBMISSION Public visitors must be able to create a new lead safely. Do NOT grant broad anonymous table permissions just to make inserts work — use the smallest safe approach the existing architecture supports. The public request path may set only the approved customer-supplied fields. Trusted logic sets the id, the initial status, the timestamps and every internal field. A public visitor must NOT be able to control the status, the notes, the follow-up date, any owner or admin field, or a won/lost state. 5. VALIDATION Validate the important fields on the trusted path: required values present, reasonable text lengths, and a valid email format where an email is required. Add simple duplicate-submission protection where appropriate. Do not turn this into an anti-spam project, and do not add CAPTCHA or a paid anti-bot product. 6. STAFF AUTHORIZATION Use proper authenticated admin / staff authorization. Do not treat every authenticated Supabase user as CRM staff. Do not rely on hidden navigation, localStorage, frontend role state or a profile field the user can edit about themselves. The database or server rules must enforce staff permissions. Reuse the closest admin authorization pattern this project already uses. Tell me how to grant the FIRST staff account safely — for example one reviewed SQL statement run once in the Supabase SQL Editor — never through self-service sign-up. 7. PUBLIC READ Public visitors must NOT be able to read the leads table. Submitting a lead does not entitle anyone to read leads afterwards, including their own. Give me: 1. Tables reused 2. Tables created 3. The public lead-submission model 4. The staff authorization model 5. Lead access rules 6. The status model 7. The follow-up model 8. ONE reviewed SQL / migration block where appropriate 9. Any server route, RPC or Edge Function required 10. Any blocker Do not use destructive DROP statements. If a table with the same name already exists, warn me instead of replacing it. Do not execute destructive database changes automatically, and do not build the UI yet.

Review the database plan and SQL, then apply it with your project's Supabase workflow — usually the SQL Editor in your Supabase project. Create your own staff account and grant it CRM access the way the report describes.

The lead table and access rules exist in Supabase

My staff account has CRM access

Build the Lead Form

Build the Lead Capture Form

Build a public lead form that creates real CRM records without exposing private lead data.

Build the public lead-capture experience from the approved CRM plan, using the Supabase structure and trusted submission path we just created. Reuse the current website design and components. Do not redesign unrelated sections. 1. PAGE OR SECTION Reuse an existing contact page, enquiry form or lead form if one is suitable — do not create a duplicate form. If no suitable form exists, create the smallest appropriate page or section. 2. FIELDS Use only the approved lead fields. Each gets a clear label, an appropriate input type and useful validation. Never ask the public visitor for internal CRM information. 3. SUBMIT On submit: validate, then create the lead through the safe submission path. Trusted logic assigns the initial NEW status. Do not expose database internals, and prevent accidental repeated submission where practical. 4. SUCCESS Show a concise confirmation, for example: "Thanks — we've received your request and will get back to you." Do not promise email or SMS notifications; those are outside this guide. Do not fake a success state. 5. FAILURE If submission fails: preserve the entered data where practical, show a useful generic error, allow a retry, and never display raw Supabase or database errors. 6. RESPONSIVE Keep the form usable on mobile. Do not add complex visual effects. Use the Supabase Project URL and Publishable key through this project's environment-variable pattern. No Secret or service-role key in browser code. When finished, report: - the public route and components - the lead fields - where validation happens - duplicate protection - success and error behaviour

Test Lead Capture

Run the app and submit one lead with test information:

Open the public form

Submit one test lead

The confirmation appears

The lead exists

Its initial status is New

A public visitor cannot read the CRM lead list

Checking the stored lead in Supabase is fine while you test. The business itself will use the dashboard you build next.

Build the CRM Dashboard

Build the Lead Management Dashboard

Create the protected dashboard the business will use every day to manage leads and follow-ups.

Build the protected CRM Dashboard for this lead-management app, using the approved Supabase staff authorization model. This dashboard is the business's normal operational interface. Do NOT tell the owner to manage leads by editing Supabase rows. 1. LOGIN Use Supabase Auth. If this project already has staff authentication, reuse it. If it has normal user authentication but no trusted staff model, add the smallest required authorization using the approved pattern. Do not add public customer accounts. 2. AUTHORIZATION After sign-in, verify the account is actually allowed to use this CRM. A signed-in account without staff access sees a clear "no access" state. Do not rely on hidden navigation, localStorage, frontend role state or editable browser data. The database rules must enforce staff permissions. 3. DASHBOARD HOME Show useful operational information — for example how many leads are New, Contacted, Qualified and Won, plus the follow-ups that are due. Do not add revenue charts or vanity analytics. 4. LEAD LIST Show concise useful information such as the name, the service or enquiry type, the status, the next follow-up and the created date. Keep rows or cards quickly scannable, with the work that needs attention first. Include search or filtering only where it genuinely improves the dashboard — filtering by status or by follow-up due is usually enough. Do not build an advanced query builder. 5. VISUAL PRIORITY Make an overdue follow-up easy to notice using the existing design system. Do not drown the dashboard in red or error styling. 6. RESPONSIVE This must work on desktop, tablet and phone — a small-business owner will open it from a phone between jobs. 7. SECURITY CRM routes and database operations must be protected by real authorization. A public visitor, or a signed-in account that is not staff, must not be able to list leads, read lead details, read internal notes or change a status. Do not change the public lead form. When finished, report: - the CRM routes - how sign-in and the staff check work - where staff permissions are enforced in the database - the dashboard summary, lead list and filtering behaviour

Then sign in with your staff account and check:

Your test lead appears in the dashboard

The lead list shows the status and the next follow-up

A signed-out browser cannot open the dashboard

Build Lead Details

Add Lead Details and Follow-Ups

Let staff update lead status, notes and next follow-up date from one clear screen.

Add a lead-detail view inside the protected CRM, using the approved lead model. Show only useful lead information, and keep the screen calm enough to use during a phone call. 1. CONTACT Show the approved fields such as the name, email, phone, service and enquiry details. Let staff correct the contact and project details when a customer gives better information. 2. PIPELINE Let staff move the lead through: New Contacted Qualified Won Lost Use clear controlled actions or select values. Never allow arbitrary status text, and the database must reject a status change from anyone who is not authorized staff. 3. NOTES Allow internal CRM notes. These are private and must never reach a public visitor. If the approved model uses a simple current-notes field, keep it simple. If this repository already has a good append-only note-history pattern and it is genuinely useful here, reuse it. Do not invent a complex activity feed without a reason. 4. FOLLOW-UP Let staff set the NEXT FOLLOW-UP value, change it, and clear it when it is no longer needed. When a lead becomes WON or LOST, a pending follow-up may be cleared where that matches the approved workflow. Do not build notification or reminder automation. 5. SAVE Use clear save behaviour with a visible result. Never silently overwrite a different lead, and report errors cleanly instead of failing quietly. 6. SECURITY Only authorized staff can read or write CRM data. Do not rely on the protected page alone — database and backend authorization is still required. Keep the detail screen usable on a phone. When finished, report: - the lead-detail route - which fields staff can edit - how status changes are constrained - how notes and the follow-up date are stored - where write permissions are enforced

Then open your test lead and check:

Move it New → Contacted

Write an internal note and save it

Set a next follow-up date

IMPORTANT

Internal notes are private business information about a real person. A protected page is not enough on its own — the database rules must refuse to return notes to anyone who is not authorized staff.

Add Leads Manually

Plenty of leads arrive by phone, WhatsApp, a walk-in or a referral. Staff need to record those too.

Add Manual Lead Creation

Add a New Lead action so phone, referral and walk-in leads enter the same CRM workflow.

Add manual lead creation to the protected CRM Dashboard, using the same lead model and the same authorization rules. Plenty of real leads never touch the website — they arrive by phone, WhatsApp, a walk-in or a referral. Staff must be able to record those without leaving the CRM. Do NOT integrate any of those external services. 1. ACTION Add a clear New Lead action inside the dashboard. Reuse the existing lead form components where that is sensible rather than building a second parallel form. 2. FIELDS Use the same approved lead fields as the public form. Staff may additionally set the internal fields the approved plan allows them to set. 3. STATUS Default a manually created lead to New, unless staff explicitly choose another valid pipeline status. 4. VALIDATION Staff creation must not bypass validation entirely. Keep the required fields, the length limits and the email-format check, even where staff can fill in less than a public visitor would. 5. RESULT A manually created lead is an ordinary lead: it appears in the same list, opens in the same detail view, moves through the same pipeline and supports the same notes and follow-up date. When finished, report: - where the New Lead action lives - which fields staff can set - the default status - which validation still applies

New Lead creates a lead from inside the dashboard

It defaults to New unless you choose another status

It opens in the same lead detail view

Run the Full CRM Flow

Open the public form in a signed-out or incognito window and the CRM Dashboard in another, then run one lead all the way through.

Test lead

Test Lead — Website Redesign

Public: submit the test lead

Admin: sign in and see the new lead

Admin: open it and change New → Contacted

Note to add

Spoke with the client. Send proposal Friday.

Admin: save the note

Admin: set the follow-up date to Friday

Admin: move it Contacted → Qualified → Won

Refresh the page — the status, note and follow-up are still there

Create one more lead manually inside the CRM

Verify CRM Access

Verify the Lead Management CRM

Verify lead capture, staff access, pipeline updates and private CRM data before deployment.

Perform a focused verification of this lead-management CRM. Use test data only. Do not add features. Never print secret values. 1. PUBLIC LEAD CAPTURE Verify: - a public visitor can submit an allowed lead - the initial status is assigned by trusted logic, not by the browser - a public request cannot inject a Won state, internal notes, staff fields or a follow-up date - a public visitor cannot list or read leads 2. STAFF AUTHORIZATION Verify: - an authorized staff account can sign in - public users cannot reach CRM data - an authenticated account that is not staff cannot reach CRM data - staff authorization is enforced beyond the UI, in the database or backend rules 3. PIPELINE Verify New → Contacted → Qualified → Won works, and that Lost works from an earlier stage. 4. FOLLOW-UP Verify: - the follow-up date saves - the dashboard correctly identifies due and overdue follow-ups where that is implemented - a refresh preserves the value 5. NOTES Verify: - staff can save notes - notes persist - public users cannot read them 6. MANUAL LEAD Verify: - staff can create a lead manually - it enters the same CRM workflow as a captured lead 7. SECRETS Confirm no Supabase Secret or service-role credential exists in browser code. Return exactly one: CRM VERIFIED or: NEEDS ATTENTION Use CRM VERIFIED only if public capture works, the private CRM works, status updates work, the follow-up date works, notes stay private, and staff authorization is enforced. If NEEDS ATTENTION, list only the remaining CRM issues. Do not perform a broad security or performance audit.

Submit one final test lead and move it from New to Qualified inside the CRM before deployment.

Deploy the CRM

Before pushing to GitHub, check:

The project builds successfully

No .env or other secret files are being published

No Supabase Secret or service-role key is in browser code

You know the production environment variable names

Push the project to GitHub with Claude Code or your normal GitHub workflow. If it already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the CRM's repository Review the detected framework and build settings Add the environment variables with your project's exact names Click Deploy and wait for the result

IMPORTANT

Add the Supabase Project URL and Publishable key under the names your project already uses. Private server keys stay private — never rename one to a VITE_ or NEXT_PUBLIC_ variable to make the deployment work.

Fix a Failed Website or Web App Deployment with AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Test the Live CRM

First add your live Hostinger URL in Supabase so staff sign-in works in production:

Supabase Authentication URL Configuration

Set the Site URL to your live URL and add it to the Redirect URLs. Then ask Claude Code to update any other production setting that depends on the live address. Then open the live app and check:

Public: the live lead form loads

Public: submit one test lead and see the success state

Admin: staff login works

Admin: the test lead appears

Admin: change the status, add a note and set a follow-up date

Admin: refresh — the values remain

Security: a signed-out user cannot reach the CRM

Security: a public visitor cannot read lead data

Mobile: the public form works on a phone

Mobile: the CRM stays usable on tablet and phone

Verify the Live CRM

Check the live Hostinger CRM from public lead capture to staff follow-up before using it with real customers.

Perform a focused production verification of this lead-management CRM, now live on Hostinger. Do not add features. Never print secret values. Do not claim to inspect Hostinger or Supabase dashboard state you cannot access — ask me for the live URL and to confirm specific settings when needed. 1. GITHUB - the approved source is current - no real secret files are committed 2. HOSTINGER - the deployment succeeded - the intended repository and branch are connected - the required environment variables are configured - the build and runtime configuration is correct 3. SUPABASE - the production app uses the intended Supabase project - staff authentication works - CRM access is protected - private server credentials remain private 4. PUBLIC - lead submission works on the live site - the public cannot read leads 5. CRM - the new lead appears - status changes persist - notes persist - the follow-up date persists - manual lead creation works 6. ACCESS - signed-out users cannot read CRM data - an unauthorized account cannot gain staff access 7. RESPONSIVE - the lead form works on mobile - the dashboard remains usable on tablet and mobile Return exactly one: CRM LIVE or: NEEDS ATTENTION If CRM LIVE, summarize: lead capture, authentication, the CRM workflow, follow-up, and the deployment result. If NEEDS ATTENTION, list only launch blockers.

Submit one final live test lead, update it from the CRM and confirm the change persists before using the app with real leads.