Build and Deploy an Invoice Generator With Claude Code

Plan the Invoicing Workflow

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

Plan the Invoice App

Tell Claude what your business does, what your invoices need to show and how you normally get paid before anything is built.

I want to build a focused invoicing web app with Claude Code. Business: {{BUSINESS_TYPE}} Invoice information: {{INVOICE_INFORMATION}} Payment instructions: {{PAYMENT_INSTRUCTIONS}} Do NOT build anything yet. First inspect the existing project. If this is an existing project, preserve the correct stack, design and working functionality. If this is a new project, plan the smallest appropriate implementation. 1. BUSINESS WORKFLOW Plan this exact path: 1. Staff signs in 2. Creates or selects a client 3. Creates a Draft invoice 4. Adds line items 5. Reviews the calculated totals 6. Generates the invoice preview or PDF 7. Shares or downloads the PDF 8. Marks the invoice Sent 9. Later marks the invoice Paid 10. The dashboard highlights overdue unpaid invoices The business owner must never edit Supabase rows for normal invoice operations. 2. BUSINESS PROFILE Plan only the minimum issuer information the generated invoices actually need — business name, address and contact details, a business or tax identifier only if I said I need one, and payment instructions where approved. Do not invent legal requirements. 3. CLIENT MODEL Plan only useful information: name or company name, email, billing address, phone where required, a tax or business identifier only where I specifically need it, and notes if useful. Do not collect unnecessary personal information. Clients do not get accounts. 4. INVOICE MODEL Plan only approved fields: invoice number, client, issue date, due date, status, notes, payment instructions, subtotal, tax or discount only where I explicitly approved it, and total. 5. LINE ITEMS Each line item supports the smallest useful structure: description, quantity, unit price and line amount. Line items belong to the invoice. Do not build a product catalog. 6. MONEY Use ONE approved currency for this MVP and a proper money representation. Do not use floating-point arithmetic that creates rounding errors, and do not build currency conversion. 7. TOTAL AUTHORITY Do not treat a browser-supplied subtotal, line total or total as an authoritative persisted financial value. Trusted application or database logic calculates invoice totals from the approved line items. 8. TAX Do not decide this business's legally correct tax or VAT rules. If I said tax must be included, support the approved field and rate model — but do not invent a rate, do not infer a jurisdiction and do not claim compliance. 9. STATUS AND OVERDUE Use a small controlled workflow: Draft, Sent, Paid, and Cancelled only if it clearly improves the MVP. Do NOT store Overdue as a manually editable status. Derive it: an invoice that is not Paid and whose due date has passed shows as Overdue. 10. DRAFT VS FINALIZED Draft invoices are editable. Once an invoice is marked Sent, protect its financial content from casual silent editing. If the business must change a sent invoice, use one explicit controlled action such as Reopen as Draft, and make the consequence clear. Do not build an invoice revision or versioning system, and never silently change a PDF the client may already have received. 11. PDF Plan a professional invoice PDF built from the trusted saved invoice data, containing only approved business, client and invoice information. Return: INVOICE APP PLAN Business profile: Client fields: Invoice fields: Line-item model: Currency: Tax behavior: Status workflow: Overdue behavior: PDF model: Staff authentication: Authorization: Features deliberately excluded: Then return exactly one: READY TO BUILD or: NEEDS A DECISION Do not modify files yet.

What type of business is this invoice app for?

Freelancer, web agency, consultant, photographer, contractor...

What should your invoices include?

Business details, client details, services, quantity, price, due date, notes...

How do clients normally pay you?

Bank transfer details, cash, existing payment method...

Review the plan before continuing. Keep version 1 focused on clients, invoices, PDF generation and payment-status tracking.

Confirm the MVP

Make sure the approved plan includes exactly this:

Clients

Draft invoices

Line items

Trusted totals

PDF

Sent / Paid

Overdue visibility

Protected Invoice Dashboard

No accounting or payment automation

This is a client and invoice app, not bookkeeping or accounting software. Invoice requirements differ by business and country, so the app carries the fields you approve — this guide does not decide what your invoices legally need.

Create or Reuse Supabase

If this project already uses the intended Supabase project, reuse it — do not create another. If Supabase is missing, create the project first:

Open Supabase

Create the project, or open the one this invoice app should use.

https://supabase.link/r4gdwhi

The browser side of the app needs only the Project URL and the Publishable key, under the environment-variable names this project already uses.

IMPORTANT

The Supabase Secret key and the service-role key are server-side values only. Never put either one in browser code or in the repository.

Add a Database to Any AI-Built Website or Web App With Supabase

Use this if this is your first Supabase project.

/video/add-a-database-to-any-ai-built-website-or-web-app-with-supabase

Create the Invoice Data

Now create the clients, invoices and line items the approved plan needs.

Create the Invoice Database

Create the smallest Supabase structure for clients, invoices and invoice line items with protected staff access.

Using the approved Invoice App Plan, create the minimum Supabase data model and access rules. Reuse correct existing authentication or admin infrastructure where possible. Never print secret values. 1. BUSINESS PROFILE If the issuer information needs persisting, use the smallest appropriate model. This app represents ONE business — do not build multi-company architecture. 2. CLIENTS Create only the approved fields. Client data is private business information, so no anonymous or public read access. 3. INVOICES Use the approved fields. Ensure the invoice number is unique where appropriate. Do not use the database row id as the human invoice number. Use a simple, predictable, business-friendly numbering model such as INV-0001 alongside secure internal identifiers. Do not overengineer the numbering. 4. LINE ITEMS Create line items related to the correct invoice, with correct money and quantity types. 5. TRUSTED TOTAL CALCULATION Create a safe model where invoice totals are derived from or validated against the invoice line items. The normal client application must not authoritatively choose the subtotal, any calculated tax amount, or the final total independently of the stored line items and rules. Choose the smallest safe pattern this project's architecture supports — a database function or a trusted server path is usually enough. Do not build a financial ledger. 6. STATUS Use constrained statuses: draft, sent, paid, and cancelled only if approved. Never allow arbitrary free-text status. 7. OVERDUE Derive overdue from the due date plus an unpaid status rather than maintaining an independent, manually editable overdue flag. 8. FINALIZED INVOICE PROTECTION Enforce the approved Draft versus Sent/Paid behavior. Normal client code must not be able to change financial line items on a finalized invoice, and disabling an Edit button is not enforcement — use the smallest trusted backend or database rule appropriate to this architecture. 9. HISTORICAL ACCURACY Preserve whatever recipient and issuer detail is needed to reproduce a finalized invoice accurately later. Editing a client's current address must not rewrite an invoice that was already sent. Use the smallest correct model. 10. STAFF AUTHORIZATION Use proper authenticated staff or admin authorization. Do not treat every Supabase user as business staff, and do not rely on hidden navigation, localStorage, frontend role state or client-editable metadata. The database rules protect client and invoice data. Tell me how to grant the FIRST staff account safely — for example one reviewed SQL statement run once in the Supabase SQL Editor. 11. ROW LEVEL SECURITY Enable appropriate RLS. This is a private internal business application by default. Do not disable RLS to make CRUD easier, and do not use a broad USING (true) on these tables. Return: 1. Tables reused 2. Tables created 3. The business-profile model 4. The client model 5. The invoice model 6. The invoice-number model 7. The line-item model 8. The trusted-total model 9. The status and overdue model 10. Finalized-invoice protection 11. Staff authorization 12. ONE reviewed SQL / migration block where appropriate 13. Any RPC or server function required 14. 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 interface yet.

Review the SQL before running it in the Supabase SQL Editor, and grant your first staff account the way the answer describes.

Build the Invoice Dashboard

This is the screen the business opens every day.

Build the Invoice Dashboard

Create the protected dashboard the business will use every day to manage clients and invoices.

Build the protected Invoice Dashboard using the approved authorization model. This is the business's operational interface — the owner must never manage invoices or clients through the Supabase dashboard. 1. STAFF LOGIN Use Supabase Auth, reusing trusted staff or admin authentication if the project already has it. Otherwise add the smallest secure staff sign-in required. There is no customer account flow. After sign-in, verify the account is actually business staff. A signed-in account without access sees a clear "no access" state. 2. DASHBOARD HOME Show only useful operational information — how many invoices are Draft, Sent, Overdue and Paid, plus recent invoices. Do not add revenue charts, profit graphs or accounting metrics. A single total outstanding amount may be included only if it is calculated correctly from the invoice data and is genuinely useful. This is not analytics software. 3. INVOICE LIST Show the invoice number, the client, the issue date, the due date, the total and the status. Make an overdue invoice easy to notice using the existing design system, without drowning the screen in red. 4. SEARCH AND FILTER Support a simple search over the client name and invoice number, and a filter by status. Do not build advanced search. 5. RESPONSIVE Keep normal invoice operations usable on desktop, tablet and phone. When finished, report the routes, how sign-in and the staff check work, where staff permissions are enforced in the database, and the dashboard and list behaviour.

Supabase is the backend you configure once. Everything the business does with an invoice happens here.

Add Client Management

Invoices are addressed to someone, so clients come first.

Add Client Management

Let authorized staff create and edit invoice clients from the protected dashboard.

Add a Clients area inside the protected Invoice Dashboard. 1. CLIENT LIST Show concise identifying information — enough to find the right client quickly. 2. ADD CLIENT Let authorized staff create a client using the approved fields, validating the required values. 3. EDIT CLIENT Let authorized staff update the client's contact and billing information. 4. HISTORICAL INVOICES — IMPORTANT Changing a client's current details must NOT silently rewrite an invoice that was already finalized. A sent invoice should still reproduce the recipient and issuer details it carried when it was issued. Use the approved model for this and keep it as simple as it can be — yesterday's PDF must not change because an address changed today. When finished, report the client routes, the fields, where validation happens, and exactly how a finalized invoice is protected from a later client edit.

IMPORTANT

An invoice you already sent is a financial record the client is holding. Changing a client's address today must never rewrite what that document says — make sure the approved model preserves the details a finalized invoice was issued with.

Build Invoice Creation

Draft invoices, line items and totals the app calculates.

Build Invoice Creation

Let staff create draft invoices, add line items and review trusted totals before finalizing them.

Build the invoice create and edit workflow inside the protected dashboard. 1. CREATE Let staff select a client, choose the issue date, choose the due date, add the approved notes and payment instructions, and add or remove line items. 2. LINE ITEMS Each item has a description, a quantity, a unit price and a calculated line total. Validate that the quantity is greater than zero and the price is not negative, according to the approved business rules. Do not create negative line items unless an approved discount model explicitly requires them. 3. TOTALS Display the subtotal, any approved tax or discount, and the total. But persist and retrieve the authoritative totals through the trusted model we created — browser arithmetic is a preview for the user, never the financial authority. 4. SAVING A clear Save Draft workflow is enough. Do not add complex autosave unless this project already has a pattern that makes it reliable. 5. STATES Add proper loading, empty, success and error states, and never show a raw Supabase error to the user. When finished, report the invoice routes, the line-item editor, how totals are calculated and stored, and what validation runs.

What the screen adds up is a preview. What the app stores and later prints is the number that counts — and it comes from the line items.

Generate the Invoice PDF

Turn the saved invoice into the document you actually send.

Generate Professional Invoice PDFs

Generate a clean downloadable invoice PDF from trusted saved invoice data.

Add professional invoice PDF generation to the invoice workflow. 1. CONTENT Build the PDF from the approved information only: Business: name, approved address and contact details, and the approved business identifier if one was approved. Client: name or company, and the billing information. Invoice: invoice number, issue date, due date, and the status only where that is appropriate. Items: description, quantity, unit price and amount. Totals: subtotal, any approved tax or discount, and the final total. Other: payment instructions and any approved notes. 2. DESIGN Keep the PDF clean, professional, readable and print-friendly. This is a business document, not a website page — no flashy web styling. 3. TRUSTED DATA Generate the PDF from the persisted, trusted invoice data. Do not accept an arbitrary browser-supplied total for PDF output, and never produce a PDF whose figures differ from the stored invoice. 4. FILENAME Use a useful, safe filename such as INV-0001-client-name.pdf, and sanitize any value that goes into it. 5. PRIVACY An invoice PDF contains private business and customer information. Generating it on demand and downloading it directly is usually better than permanently storing it. If this architecture must store PDFs, use private access. Never create public, permanent or enumerable invoice URLs. When finished, report how the PDF is generated, where the data comes from, the filename rule, and exactly how the PDF is kept private.

IMPORTANT

An invoice PDF holds your client's billing details and what they were charged. Never expose invoice PDFs at public or guessable URLs — generate them on demand, or keep them behind private access if your setup has to store them.

Finalize and Track the Invoice

Draft → Sent → Paid, with overdue derived from the due date.

Add Invoice Status Tracking

Move invoices from Draft to Sent to Paid, protect finalized invoices and show overdue automatically.

Add the invoice status workflow to the protected dashboard, using the approved model. 1. TRANSITIONS Let authorized staff move an invoice Draft to Sent, and later Sent to Paid. Use clear controlled actions, never free-text status. 2. MARKING SENT When an invoice is marked Sent, apply the approved finalized-invoice behavior so its financial content is protected from casual silent editing, enforced in the database rather than by a disabled button. If the business genuinely must change a sent invoice, provide the one approved controlled action — such as Reopen as Draft — and make its consequence clear in the interface. Do NOT automatically email the PDF to anyone. The business downloads it and sends it however it already communicates with clients. 3. OVERDUE Where the due date has passed and the invoice is still unpaid, show it clearly as Overdue in the dashboard and the list. Overdue is derived, never stored as an editable status, and a Paid invoice must never be shown as Overdue because a date passed. 4. PAID Let authorized staff mark an invoice Paid manually, recording a paid date if that is useful. Do not add any payment-provider integration — this app records that payment happened, it does not collect it. When finished, report the transitions, how finalized invoices are protected, how overdue is derived, and what marking Paid records.

Nothing is emailed automatically. You download the PDF and send it the way you already talk to clients — automated invoice email is a separate workflow.

Run a Full Invoice Test

Bill a fake client end to end. Use your own currency where the example shows dollars:

Create the client Acme Studio

Create invoice INV-0001 for that client

Add line 1: Website Design, 1 × 1,500

Add line 2: Hosting Setup, 1 × 200

Confirm the total reads 1,700

Save the draft, then generate the PDF

Check the PDF: business details, client details, line items, totals, dates and payment instructions

Mark it Sent, then try a normal financial edit and confirm the approved finalized behavior

Mark it Paid

Create a second test invoice with a due date already in the past and confirm it shows Overdue while unpaid

Then change the test client's address and reopen the invoice you already sent. It should still show the details it was issued with.

Verify the Invoice App

Run a focused check before anything is deployed.

Verify the Invoice App

Verify client privacy, invoice totals, PDFs and finalized invoice behavior before deployment.

Perform a focused verification of this invoicing app, using test clients and test invoices only. Do not add features. 1. AUTHORIZATION Verify that authorized staff can reach clients and invoices, that a signed-out user cannot reach private invoice data, that an authenticated account without staff access cannot either, and that this is enforced beyond hidden interface elements. 2. CLIENTS Verify creating a client works, editing a client works, and that a client edit does not improperly rewrite a finalized historical invoice. 3. TOTALS Create known test line items and verify the line totals, the subtotal, any approved tax or discount, and the final total. Then attempt a modified client request supplying a fake total, and verify the trusted logic does not accept it as authoritative. 4. PDF Verify the PDF generates, that its totals match the stored invoice, that the correct client and business appear, that the filename is safe, and that invoice PDFs are not publicly enumerable. 5. STATUS Verify Draft to Sent to Paid, and the approved finalized-edit rules. 6. OVERDUE Verify that a past-due unpaid invoice shows as Overdue, and that a Paid invoice does not. 7. SECRETS Confirm no Supabase Secret or service-role credential is exposed client-side. Return exactly one: INVOICE APP VERIFIED or: NEEDS ATTENTION Use INVOICE APP VERIFIED only when clients work, trusted totals work, the PDF works, the status workflow works, finalized invoices behave correctly, and private data is protected. If NEEDS ATTENTION, list only the invoice-app blockers.

Create one final test invoice, generate its PDF and move it from Draft to Sent before deployment.

Deploy the Invoice App

Before pushing to GitHub, check:

The project builds successfully

No .env or other secret files are being published

No real client or invoice data sits in source or sample files

No Supabase Secret or service-role credential 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 the app 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 invoice 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

If staff sign-in needs it, set the production Site URL and Redirect URLs once the live address exists:

Supabase Authentication URL Configuration

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 Invoice App

Bill one more fake client, this time on the production app:

Staff sign-in works

Create a test client and a draft invoice with line items

Save it and confirm the totals persist

Generate the PDF and confirm it matches the invoice

Mark it Sent, refresh, and confirm the status persists

Overdue appears correctly on the past-due test data

A signed-out visitor cannot read invoices

An unauthorized account cannot reach business data

The dashboard and the invoice editor work on the screen sizes you actually use

Verify the Live Invoice App

Check the complete Hostinger invoicing workflow before using it for real clients.

Perform a focused production verification of this invoicing app. Do not add features. 1. GITHUB Verify the approved source is current, that no secrets are committed, and that no real client or invoice data is committed. 2. HOSTINGER Verify the deployment succeeded, the correct repository and branch are connected, the build and runtime configuration are correct, and the required environment variables exist. 3. SUPABASE Verify the intended project is in use, that staff authentication works, that authorization is still enforced, and that private client and invoice data stays private. 4. INVOICE WORKFLOW On production, verify creating a client, creating a draft invoice, adding line items, correct trusted totals, PDF generation, marking Sent, marking Paid, and correct overdue derivation. 5. HISTORICAL DATA Verify that a finalized invoice's content does not change incorrectly when the current client information changes. Return exactly one: INVOICE APP LIVE or: NEEDS ATTENTION If INVOICE APP LIVE, summarize client management, invoice creation, totals, the PDF, status tracking, authorization and the deployment. If NEEDS ATTENTION, list only the launch blockers.

Create one final production test invoice and verify its PDF before entering real client data.