Build and Deploy a Quote Request System With Claude Code

Plan the Quote Workflow

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

Plan the Quote Request System

Tell Claude what your business does, what customers need to provide, and what your quotes should contain before anything is built.

I want to build a real quote request and quote-management system with Claude Code. Business type: {{BUSINESS_TYPE}} Information customers should provide: {{REQUEST_DETAILS}} Information the final quote should show: {{QUOTE_DETAILS}} 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. CUSTOMER WORKFLOW Plan: 1. Customer opens the Quote Request page 2. Completes the request form 3. Submits it 4. Gets a clear confirmation 5. The business reviews the request 6. The business creates a quote 7. The customer opens a private quote link 8. The customer reviews the offer 9. The customer accepts or declines 10. The business sees the result Do not require customer accounts. 2. BUSINESS WORKFLOW Plan a proper protected Admin Dashboard. The business owner must NOT use the Supabase dashboard for normal operations. Inside the application, staff should be able to: - see new requests - open request details - update request status - create and edit the quote - set the price - enter the scope and details - create or copy the customer quote link - see the accepted or declined result 3. DATA MODEL Plan the minimum data required. The likely concepts are a QUOTE REQUEST, a QUOTE, and ADMIN / STAFF access. Do not create separate CRM entities unless they are actually necessary. If the request and the quote can cleanly live in one record, consider that. If separating them produces a safer or cleaner workflow, use two related records. Choose based on the real implementation, and do not over-normalize a simple MVP. 4. STATUS FLOW Use a simple status flow: NEW → REVIEWING → QUOTED → ACCEPTED or: NEW → REVIEWING → QUOTED → DECLINED Add CLOSED only if it is genuinely useful for this business. Do not build a workflow engine, and do not allow arbitrary editable status strings. 5. SECURITY MODEL A PUBLIC CUSTOMER may: - submit a new request - open only a valid private quote intended for them - accept or decline that quote A PUBLIC CUSTOMER must NOT: - list quote requests - read another customer's request - read another quote - change the price - change the quote scope - change the internal status - reach the Admin Dashboard ADMIN / STAFF may: - authenticate - read requests - create and update quotes - update statuses - see customer decisions 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. 6. PRIVATE QUOTE ACCESS Plan an unguessable public quote-access mechanism — for example a high-entropy random access token generated on a trusted server or database path, or another established pattern that is already safe in this project. Do not use a predictable database id as the only security mechanism. A token must never reach an unrelated quote or customer record, and private customer data must not be placed in the URL itself. Choose the smallest secure approach the existing architecture supports. 7. EXCLUDED FROM VERSION 1 Do not plan: Stripe payments, deposits, invoices, subscriptions, contracts, e-signatures, a CRM pipeline beyond this quote workflow, appointment booking, real-time chat, customer accounts, email automation, SMS, PDF generation, a proposal builder, itemized accounting, tax calculations, multi-currency, recurring quotes, team permissions, multiple businesses, analytics dashboards, AI quote generation or an automatic pricing engine. Return: QUOTE SYSTEM PLAN Public pages: Admin pages: Request fields: Quote fields: Status flow: Data model: Staff authentication: Customer quote access: Public permissions: Admin permissions: 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?

Web design agency, cleaning business, photographer, contractor...

What should customers tell you when requesting a quote?

Service needed, project details, preferred date, property size, budget...

What should the customer see in the final quote?

Price, scope of work, timeline, notes, validity date...

Review the workflow before continuing. Keep the first version focused on request → quote → accept/decline.

Confirm the MVP

Make sure the approved plan includes exactly this:

Public quote request

Protected business dashboard

Quote creation

Private customer quote page

Accept / Decline

No unnecessary CRM or payment 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 Quote Data

Use this prompt in the same Claude Code session.

Create the Quote System Database

Create the smallest Supabase data model for quote requests, private customer quotes and protected staff management.

Using the approved quote-system plan, create the minimum Supabase data structure and access rules. Reuse correct existing structures where appropriate. Do not duplicate existing profiles or admin infrastructure. Never print secret values. 1. QUOTE REQUEST Store only the request information approved earlier. Typical fields where relevant: id, customer name, email, phone if genuinely needed, service type, project or request details, status, created_at. Do not collect unnecessary personal information. 2. QUOTE A quote may include: the request reference, the quoted amount, the scope and details, an optional timeline, an optional validity date, the quote status, the secure access token or a reference to it, and created / updated timestamps. Use only the approved fields. 3. PRICE Use an appropriate numeric or decimal money representation, consistent with this project's database pattern. Do not use floating-point behaviour that can produce obvious money errors. Do not build a tax engine, discounts or multi-currency conversion unless the approved MVP explicitly requires one. 4. PUBLIC REQUEST SUBMISSION Public visitors must be able to submit a quote request safely. Do NOT grant broad anonymous table permissions just to make inserts work — use the smallest secure approach the existing architecture supports, and validate important fields on the trusted path. A public visitor must NOT be able to set the internal status, the quoted amount, admin notes, the quote token, or an accepted state. 5. SPAM AND ABUSE Keep anti-abuse proportional: validation, reasonable field-length limits, duplicate-submission protection, and any app-level protection this project already has. Do not turn this into a CAPTCHA or rate-limiting project, and do not add a paid anti-bot service. 6. STAFF AUTHORIZATION Use proper authenticated admin / staff authorization. Do not treat every authenticated Supabase user as staff. Do not rely on hidden admin navigation, localStorage, frontend role checks or a profile field the user can edit about themselves. The database or server rules must enforce staff access. Reuse the closest admin authorization pattern this project already uses. Tell me how to grant the FIRST admin safely — for example one reviewed SQL statement run once in the Supabase SQL Editor — never through self-service sign-up. 7. PRIVATE QUOTE TOKEN Generate quote-access tokens on a trusted path, using sufficiently random, unguessable values. Do not let the browser choose the token. If the established architecture supports safer hashed-token verification, avoid storing the raw token unnecessarily. Choose the smallest secure implementation consistent with this project — this does not need to become a cryptography exercise. 8. PUBLIC QUOTE READ Do not make the quotes table broadly anonymous-readable. A valid private quote token should return only the customer-facing information needed for that one quote. Do not expose internal admin notes, unrelated customer information, database metadata, or any other quote. 9. ACCEPT AND DECLINE A customer action is limited to ACCEPT or DECLINE, for the quote associated with the valid private token. The customer must not be able to change the amount, the scope, the request status arbitrarily, or another quote. Do not trust a quote id supplied by the browser without validating its relationship to the token. Give me: 1. Tables reused 2. Tables created 3. Public request submission model 4. Staff authorization model 5. Private quote-access model 6. Accept / decline model 7. RLS and access approach 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 admin access the way the report describes.

The tables and access rules exist in Supabase

My staff account has admin access

Build the Customer Request Form

Build the Quote Request Flow

Build the public request form using the approved customer fields and securely submit new requests to Supabase.

Build the customer-facing Quote Request experience from the approved plan, using the Supabase structure and trusted submission path we just created. Reuse the current website design and components. Do not redesign unrelated pages. 1. PAGE Create or reuse an appropriate route, such as /quote, /request-a-quote or /get-a-quote — choose the best fit for the existing project. Do not create a duplicate route if a suitable page already exists. 2. FORM Use only the approved request fields. Each field gets a clear label, an appropriate input type and useful validation. Do not collect unnecessary information. 3. VALIDATION Validate the important fields on the trusted submission path, not only in the browser. Apply reasonable limits to long text fields. Never expose raw database errors. 4. SUBMISSION On submit: create a real persisted request, assign the trusted internal default status, and prevent accidental duplicate submissions where practical. The customer must not be able to choose any internal field. NEW is the normal initial status. 5. SUCCESS Show a professional confirmation, for example: "Your request has been received. We'll review the details and prepare your quote." Do not promise email delivery — email automation is outside this guide — and do not fake an immediate quote. 6. FAILURE If submission fails: keep the customer's entered data where practical, show a useful generic error, allow a retry, and never show raw Supabase or database details. Never show a fake success. 7. 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 request fields - where validation happens - duplicate protection - success and error behaviour

Test a Request

Run the app and submit a request with test information:

Open the public quote page

Complete the required fields

Submit the request

The confirmation appears

The request exists in the system

Its initial status is New

A public visitor cannot reach the Admin Dashboard

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

Build the Quote Admin Dashboard

Build the Quote Management Dashboard

Create a protected business dashboard where staff can review requests, create quotes and manage the full quote workflow.

Build the protected Admin Dashboard for this quote system, using the approved Supabase admin authorization model. This dashboard is the normal operational interface for the business. Do NOT tell the owner to manage quotes by editing Supabase rows manually. 1. ADMIN LOGIN Use Supabase Auth. If this project already has admin authentication, reuse it. If it has normal user authentication but no trusted admin model, add the smallest required admin authorization using the approved pattern. Do not add customer authentication. 2. ADMIN AUTHORIZATION After sign-in, verify the user is actually allowed to administer this business. A signed-in user without admin 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 admin permissions. 3. DASHBOARD Show the quote workflow information staff actually needs across NEW, REVIEWING, QUOTED, ACCEPTED and DECLINED. Use counts, tabs or filters only where they improve the workflow. No fake analytics charts. 4. REQUEST LIST Show useful information such as the customer name, the service or request type, the created time and the current status. Keep rows or cards quickly scannable, newest work first. 5. REQUEST DETAIL Show the customer and contact information, the request details, the current status, and the quote information if one exists. Keep internal fields and customer-facing fields visually clear. 6. STATUS Let staff move the request through the approved flow. Status is never free text, and the database must reject a status change from anyone who is not authorized staff. 7. SECURITY Admin routes and database operations must be protected by real authorization. A public visitor, or a signed-in non-admin account, must not be able to list quote requests, read private customer details, change statuses or create quotes. Keep the dashboard usable on a laptop, a tablet and a phone. Do not change the public request form. When finished, report: - the admin routes - how sign-in and the admin check work - where admin permissions are enforced in the database - the request list, detail and status behaviour

Then sign in with your staff account and check:

Your test request appears in the dashboard

Open the request and see the customer's details

Move it New → Reviewing

Create and Manage Quotes

Add Quote Creation

Let authorized staff turn a customer request into a professional quote and create a secure customer link.

Inside the protected Quote Management Dashboard, add the ability for authorized staff to create or update a quote for a request. Use the approved quote structure. 1. QUOTE EDITOR Allow authorized staff to enter the approved quote fields, such as the quote amount, the scope and details, an optional timeline, an optional validity date, and a customer-facing note. Use only fields approved in the plan. Do not build a rich document editor. 2. CREATE THE PRIVATE LINK When a quote is ready, create or reuse its secure private access token through the trusted backend or database path, and show the business the customer-facing quote URL — for example /quote/view/<secure-token>, or another route that is safe in this project. Do not expose a predictable quote id as the access mechanism. 3. QUOTE STATUS When the quote is published or shared, set the appropriate state, such as QUOTED. Do not mark it accepted until the customer actually accepts. 4. COPY LINK Add a clear Copy Quote Link action in the dashboard. Do not add email sending — the business sends the link with whatever it already uses. 5. EDITING Allow staff to edit a quote before it is accepted. An accepted quote must not be silently changed into a different agreement: make accepted quotes read-only unless the user explicitly creates a new or revised quote. Do not build quote versioning complexity. 6. RESULT The business must be able to run the entire normal workflow inside the app: new request → review → create quote → copy link → see accepted or declined. No Supabase row editing. When finished, report: - the quote editor fields - how the token and customer URL are created - what the quote status becomes when it is shared - what happens when staff edit an accepted quote - where quote write permissions are enforced

Then check:

Enter a price and scope for your test request

The request moves to Quoted

Copy Quote Link gives you a private customer URL

Build the Private Quote Page

Build the Customer Quote Page

Create a clean private quote page that works from the secure link and lets the customer accept or decline the offer.

Build the customer-facing private quote page using the approved secure quote-access model. 1. ACCESS Read the secure access token from the route and validate it through the trusted backend or database path. Do not query all quotes, do not open broad anonymous read access, and do not trust a quote id without the secure token. 2. INVALID TOKEN If the token is missing, invalid, or expired where expiry is implemented, show a generic state such as: "This quote link is no longer available." Do not reveal whether another quote exists. 3. QUOTE DISPLAY Show only useful customer-facing information, such as the business or project name, the quote amount, the scope, the timeline, the validity date and the customer-facing note. Do not expose internal notes, admin user ids, token data or database metadata. 4. ACCEPT Add an Accept Quote action, with a confirmation step if appropriate. The trusted mutation path must verify that the token is valid, that the quote is still eligible for acceptance, and that the request-to-quote relationship is correct, before setting the accepted state. 5. DECLINE Add a Decline Quote action. Keep it simple. Do not require a reason unless it was explicitly approved; if a reason is offered, make it optional. 6. ALREADY DECIDED Once the customer has accepted or declined, show the final state clearly. Do not leave active Accept and Decline buttons available afterwards. 7. RESPONSIVE Many customers open this link from email, WhatsApp, SMS or another messaging app, so the quote must look professional on a phone. Do not build those delivery integrations here. When finished, report: - the quote route - how the token is validated - which fields the customer can see - how accept and decline are validated - what an invalid or already-decided link shows

IMPORTANT

The private quote link is the only thing standing between one customer and another customer's price. It must be an unguessable token, not a database id like /quote/123 that anyone can count up from.

Verify the Full Quote Flow

Open the private quote link in a signed-out or incognito window and the Admin Dashboard in another:

Customer: the private link opens the quote

Customer: the price, scope and details look right

Customer: accept the quote

Admin: the dashboard shows Accepted

Create a second test quote and decline that one

Admin: the dashboard shows Declined

Change a few characters in the quote URL — nothing is exposed

Verify the Quote System

Test the complete customer-to-business workflow and prove private quote links cannot expose other customers' data.

Perform a focused verification of this quote-request system. Use test data only. Do not add features. Never print secret values. 1. PUBLIC REQUEST Verify: - a public visitor can submit a valid quote request - the request begins with the correct internal status - the customer cannot choose admin or internal values - a public visitor cannot list all requests 2. ADMIN Verify: - an authorized admin can sign in - the request appears in the dashboard - the admin can review it - the admin can create a quote - the admin can get the private quote link 3. PRIVATE LINK Verify: - a valid link opens the correct quote - an invalid or random token exposes no data - changing visible values in the URL does not expose another quote - a public user cannot list or query unrelated quotes 4. CUSTOMER INFORMATION Verify the private page returns only the intended customer-facing fields. Internal notes and private business fields must not be exposed. 5. ACCEPT Using the valid test link, accept the quote. Verify that the customer sees Accepted, the dashboard shows Accepted, and repeating the request does not corrupt the state. 6. DECLINE Using another test quote, decline it. Verify the customer sees Declined and the dashboard sees Declined. 7. ADMIN AUTHORIZATION Verify a public or non-admin user cannot reach Admin Dashboard data, change a quote amount, create quote tokens, or change internal statuses. 8. SECRETS Confirm no Supabase Secret or service-role credential exists in browser code. Return exactly one: QUOTE SYSTEM VERIFIED or: NEEDS ATTENTION Use QUOTE SYSTEM VERIFIED only if request submission works, the business dashboard works, private quote access works, accept and decline work, cross-customer quote access is blocked, and admin actions require authorization. If NEEDS ATTENTION, list only remaining quote-system issues. Do not perform a broad security or performance audit.

Complete one full test from public request → Admin Dashboard → quote link → Accept before deploying.

Deploy the Quote App

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

You know which settings depend on the production URL

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 quote app'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 Quote System

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 — including the base URL used to build customer quote links, so a live quote never points at localhost. Then open the live app and check:

Public: the Quote Request page loads

Public: submit a test request and see the confirmation

Admin: sign in and see the new request

Admin: create a test quote and copy the private link

Customer: open the private link in a signed-out or incognito browser

Customer: the quote displays correctly, then accept it

Admin: the dashboard shows Accepted

Security: a random invalid token exposes no quote

Security: the Admin Dashboard is unavailable to public users

Mobile: the request form and the private quote page are usable

Verify the Live Quote System

Check the full live Hostinger workflow from customer request to accepted quote before using it with real customers.

Perform a focused production verification of this quote request system, 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 correct repository and branch are connected - the framework and build configuration are correct - the required environment variables are present 3. SUPABASE - the intended production Supabase project is used - staff authentication works - admin access is enforced - private server credentials remain private 4. PUBLIC REQUEST - a new test request works 5. ADMIN - the request appears - a quote can be created 6. PRIVATE QUOTE - the generated production URL is correct - a valid token opens only the intended quote - an invalid token exposes nothing - accept and decline work 7. STATUS - the dashboard reflects the customer's decision 8. RESPONSIVE - the request page and the quote page work on mobile - the dashboard remains usable on common screen sizes Return exactly one: QUOTE SYSTEM LIVE or: NEEDS ATTENTION If QUOTE SYSTEM LIVE, summarize: the request result, the dashboard result, the private quote result, the accept / decline result, and the deployment result. If NEEDS ATTENTION, list only launch blockers.

Submit one final quote request on the live site, create the quote from the dashboard and accept it from the private customer link before giving the system to the business.