Build and Deploy an Inventory Management System With Claude Code

Plan the Inventory App

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

Plan the Inventory System

Tell Claude what the business stocks, what each product needs and when stock should be considered low before anything is built.

I want to build a lightweight inventory-management web app with Claude Code. Business: {{BUSINESS_TYPE}} Product information: {{PRODUCT_INFORMATION}} Low-stock rule: {{LOW_STOCK_RULE}} 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. STAFF WORKFLOW Plan: 1. Staff signs in 2. Sees the Inventory Dashboard 3. Creates a product 4. Records the initial stock correctly 5. Records Stock In when inventory arrives 6. Records Stock Out when inventory leaves 7. Current stock updates 8. The low-stock state appears where appropriate 9. Staff can open a product and review its movement history The business must NOT manage normal inventory by editing rows in the Supabase dashboard. 2. PRODUCT MODEL Plan only useful fields. Possible fields: name, SKU, category, unit, current stock, low-stock threshold, and an active / archived state. Do not automatically add every possible field. 3. MOVEMENT MODEL Every normal quantity change produces an inventory movement — conceptually STOCK IN +10 or STOCK OUT -3 — and stores enough to audit what happened. Possible movement fields: product, movement type, quantity, note or reason, created time, staff user. Use only what the approved MVP needs. 4. SOURCE OF TRUTH Design a reliable stock model. Do NOT plan a fragile implementation where the browser reads stock = 10, calculates 10 - 3, and writes stock = 7. Two staff members working at the same time must not be able to silently overwrite each other's change. Plan an appropriate trusted, transaction-safe database or server-side operation instead. Keep the technical detail in the implementation — I do not need a lesson in concurrency. 5. NEGATIVE STOCK Default behaviour: a Stock Out must NOT reduce inventory below zero. If current stock is 2 and staff try to take out 5, the operation is rejected clearly. Never silently produce -3. 6. STOCK UNITS One simple unit per product — pieces, boxes, kg, liters, units. Do not plan unit conversion. "1 box = 24 pieces" is outside this version. 7. LOW-STOCK MODEL Each product may carry a low-stock threshold. Current stock at or below it reads as LOW STOCK; zero reads as OUT OF STOCK. The dashboard only identifies the problem — do not plan automatic purchasing. 8. SECURITY Only authorized staff may read the private inventory, create products, edit products or record stock movements. This is an INTERNAL business tool by default: do not plan a public inventory view unless the existing product explicitly requires one. Being signed in is not the same as being inventory staff — plan a trusted staff check. Never put a Supabase Secret or service-role key in browser code. 9. EXCLUDED FROM VERSION 1 Do not plan: barcode or QR scanning, supplier management, purchase orders, sales orders, ecommerce checkout, Stripe, invoices, accounting, multiple warehouses, warehouse transfers, serial numbers, batch or lot tracking, expiration dates, product variants, forecasting, automatic reordering, email or SMS alerts, POS / Shopify / WooCommerce integration, CSV import or export, an analytics suite, profit calculations or customer management. Return: INVENTORY APP PLAN Pages: Product fields: Stock model: Movement model: Low-stock model: Staff authentication: Authorization: Data model: 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 inventory system for?

Retail shop, coffee business, repair store, reseller...

What information should each product have?

Name, SKU, category, unit, stock quantity...

When should a product be considered low stock?

Use a different threshold per product, such as 5 units...

Review the plan before continuing. Keep version 1 focused on accurate stock, movement history and low-stock visibility.

Confirm the MVP

Make sure the approved plan includes exactly this:

Product management

Stock In

Stock Out

Movement history

Low-stock state

Protected Inventory Dashboard

No unnecessary warehouse or accounting 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 Inventory Data

Use this prompt in the same Claude Code session.

Create the Inventory Database

Create the smallest Supabase structure for products and atomic stock movements with protected staff access.

Using the approved inventory plan, create the minimum Supabase data model and access rules. Reuse correct existing authentication or admin infrastructure where appropriate. Never print secret values. 1. PRODUCTS Create only the approved product fields. Typical fields where useful: id, name, sku, category, unit, current_stock, low_stock_threshold, active, created_at, updated_at. Do not add product-commerce fields such as sale price, customer price, discount, shipping or tax unless the approved inventory use case genuinely needs them. 2. SKU If a SKU or code is included, make it unique where that is appropriate. Do not force a SKU if the approved small-business workflow does not need one. 3. STOCK MOVEMENTS Create the movement / history structure. Conceptually: id, product_id, type (IN, OUT, and ADJUSTMENT only if approved), quantity, note or reason if used, created_by, created_at, and the resulting stock where that is useful. Keep the quantity POSITIVE in the movement record — the direction comes from the movement type. Do not mix an explicit type with a negative-quantity convention. 4. ATOMIC STOCK OPERATION Implement every stock change through ONE trusted, transaction-safe operation appropriate to Supabase and Postgres — a database function or RPC, or another established pattern already used in this project. The operation conceptually: 1. verifies authenticated staff authorization 2. validates the product 3. validates quantity > 0 4. reads the current product stock safely, under an appropriate lock 5. calculates the new stock 6. rejects a Stock Out that would make it negative 7. updates the current stock 8. inserts the movement history row 9. completes both together, or neither There must be no state where the product stock updates but the movement history fails, or the reverse. The stock update and the movement record are one logical operation. 5. DO NOT TRUST BROWSER STOCK The browser may request "Stock Out 3". It must NOT supply an authoritative old_stock = 10 or new_stock = 7. The trusted operation determines the current and resulting stock. 6. INITIAL STOCK Pick one clean behaviour: either a product starts at 0 and staff then record an explicit "Initial stock" Stock In, or the initial quantity is created through the same trusted operation so it has a movement record. Do not produce a product that starts at current_stock = 50 with nothing in its history explaining where the 50 came from. 7. STAFF AUTHORIZATION Use real authenticated staff / admin authorization. Do not treat every authenticated Supabase user as inventory staff. Do not rely on hidden navigation, localStorage, frontend state or client-editable metadata. The database or server operation must enforce the permission. Reuse the closest admin authorization pattern this project already uses. Tell me how to grant the FIRST inventory admin safely — for example one reviewed SQL statement run once in the Supabase SQL Editor — never through self-service sign-up. 8. DIRECT WRITES Normal staff inventory operations must NOT be able to update current_stock through ordinary client CRUD on the product row. Stock changes go through the trusted movement operation, so nothing can bypass the history. 9. ARCHIVE Prefer an archived / inactive state over deleting a product that already has movement history. Do not casually delete audit history. Return: 1. Tables reused 2. Tables created 3. Product model 4. Stock-movement model 5. Atomic stock-operation model 6. Negative-stock protection 7. Initial-stock behaviour 8. Staff authorization model 9. Direct-write restrictions 10. ONE reviewed SQL / migration block where appropriate 11. The RPC or function setup I need to apply 12. 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.

IMPORTANT

The stock number and its history have to change together. If the app can update one without the other — or if the browser gets to say what the new total is — your inventory drifts away from reality and nobody can tell when it started.

Review the database plan and SQL, then apply it with your project's Supabase workflow — usually the SQL Editor in your Supabase project. Apply the stock function or RPC the report describes, then create your own staff account and grant it inventory access the way the report describes.

The tables and access rules exist in Supabase

The trusted stock operation exists

My staff account has inventory access

Build the Inventory Dashboard

Build the Inventory Dashboard

Create the protected dashboard staff will use every day to manage products and see stock levels.

Build the protected Inventory Dashboard using the approved data and authorization model. This is the business's operational interface — it exists so staff never edit inventory in Supabase. 1. STAFF LOGIN Use Supabase Auth. If this project already has trusted staff or admin authentication, reuse it — do not add a second login system. Otherwise add the smallest safe staff sign-in. There is no public customer account flow, and no public inventory page. 2. DASHBOARD Show useful operational summaries — typically Products, Low Stock and Out of Stock counts, plus Recent Movements. Do not add fake revenue, sales graphs or profit charts. This is inventory management. 3. PRODUCT LIST Show the concise fields staff actually work from: product, SKU where used, category, stock, unit and the stock status. Identify LOW STOCK (current stock at or below the product's low-stock threshold) and OUT OF STOCK (zero) clearly, without making the page visually aggressive. 4. FILTERING Useful simple filters: category, and stock state (All / Low Stock / Out of Stock). Add a text search if it is useful. Do not build advanced search infrastructure. 5. RESPONSIVE Keep it usable on desktop, tablet and phone — staff will use this while physically handling inventory, often one-handed. 6. SECURITY Every dashboard route and every inventory read is protected by the trusted staff check from the database layer. A signed-in non-staff user and a signed-out user must both be refused. Tell me which routes are protected and where that is enforced.

Then sign in with your staff account and check:

The dashboard opens for your staff account

A signed-out visitor cannot reach it

Add Product Management

Add Product Management

Let authorized staff create and edit products from the Inventory Dashboard without changing stock history manually.

Add product create and edit management inside the protected Inventory Dashboard. 1. CREATE A PRODUCT Let staff enter the approved fields, and validate the important values — a required name, a low-stock threshold of zero or more, and a unique SKU where one is required. 2. INITIAL STOCK Use the approved initial-stock behaviour. If staff enter an initial stock while creating the product, route it through the trusted stock operation so that quantity has a movement record like every other change. Do not bypass the movement history to seed a number. 3. EDIT A PRODUCT Let staff edit the ordinary descriptive fields: name, SKU, category, unit and the low-stock threshold. Do NOT offer "Current Stock" as an ordinary editable field. Stock changes only through Stock In, Stock Out, or an explicit Adjustment if the approved MVP includes one. 4. ARCHIVE Let a product become inactive or archived, and keep it out of the normal working list. Never delete its historical movement data. Tell me where current_stock is writable from the client, if anywhere, and confirm the product editor cannot set it.

IMPORTANT

Current stock must never be an ordinary text field staff can retype. The moment someone can set the number directly, the history stops explaining it — and the history is the only thing that makes the number trustworthy.

Add Stock Operations

Add Stock In and Stock Out

Let staff safely change stock through controlled inventory movements instead of editing the stock number directly.

Add the stock-operation workflow to the protected Inventory Dashboard. 1. PRODUCT ACTIONS Provide clear actions on a product: Stock In and Stock Out, plus Adjust Stock only if the approved MVP includes it. 2. STOCK IN Ask for a quantity and an optional reason or note — for example a new shipment, a returned item, or initial stock. Do not ask staff to calculate the resulting stock themselves. 3. STOCK OUT Ask for a quantity and an optional reason or note — for example a sale, a damaged item, or internal use. The reason is inventory context only. Do not build sales or order accounting around it. 4. TRUSTED OPERATION Submit through the trusted atomic stock operation we created. The browser supplies only the product, the movement type, the quantity and an optional note. The trusted path determines the current stock, the resulting stock and the history record. 5. NEGATIVE STOCK If a Stock Out exceeds the current stock, reject it clearly — for example "Only 3 units are available." Never partially process the requested quantity, and never let a rejected attempt write a movement record. 6. SUCCESS After a successful operation the stock number, the stock state and the movement history all reflect it. Do not require a manual page reload if the current app can update cleanly. 7. DUPLICATE SUBMISSION Prevent an accidental double-click or repeated submission where that is practical — but the trusted path must be safe on its own. A disabled button is a convenience, never the integrity guarantee. Tell me exactly what the client sends, and what the trusted operation decides.

IMPORTANT

A rejected Stock Out must leave nothing behind — no partial quantity taken, no movement row written. A refusal that still records something is worse than no check at all, because the history now says a thing happened that didn't.

Add Movement History

Add Inventory History

Show staff exactly when and why stock changed without exposing raw database records.

Add inventory movement history to the protected Inventory Dashboard. 1. RECENT MOVEMENTS On the dashboard, show the recent movements: the product, Stock In or Stock Out, the quantity, the time, and the staff member where that is useful. 2. PRODUCT HISTORY On the product detail or edit page, show that product's own movement history, newest first unless the existing UX strongly suggests another order. Present it in business language — Stock In, Stock Out, quantity, time — not as raw database records or column names. 3. HISTORY IS AUDIT DATA Normal staff must not be able to casually edit a past movement, and must not be able to delete movement history to make the numbers look different. If a mistake was made, the correction is a NEW explicit movement — an Adjustment where that pattern is included — not a rewrite of what happened. 4. LOW-STOCK VISIBILITY Confirm the low-stock states read correctly from the movement-driven stock: current stock at or below the threshold shows LOW STOCK, zero shows OUT OF STOCK, and restocking clears the warning. Staff can filter the product list down to Low Stock quickly. Do not send email or SMS alerts — the warning lives in the dashboard. Tell me where history is made read-only, and how a correction is meant to be recorded.

Then check:

Recent movements appear on the dashboard

A product's own history opens from the product

A product at or below its threshold reads Low Stock

A product at zero reads Out of Stock

Run the Full Stock Test

One product, taken all the way through. Check the number after every step.

Create a product: Coffee Beans, SKU BEANS-001, unit bags, low stock 5, initial stock 10.

History shows the initial Stock In +10

Stock Out 3 → stock is 7

Stock Out 3 again → stock is 4, and it reads Low Stock

Stock In 10 → stock is 14, and the warning clears

Try Stock Out 20 → rejected, and it says only 14 are available

Stock is still 14 after the rejection

History lists every successful operation — and nothing for the rejected one

Refresh — the stock and the history are unchanged

Verify the Inventory System

Verify the Inventory System

Verify stock accuracy, movement history and staff authorization before deployment.

Perform a focused verification of this inventory-management app. Use test products only. Do not add features. 1. PRODUCT ACCESS - authorized staff can create a product - unauthorized users cannot read or manage the private inventory - signed-out users cannot mutate products 2. INITIAL STOCK - the initial quantity has a movement record - the current stock matches the history 3. STOCK IN - a valid Stock In succeeds - the current stock increases correctly - a movement record is created 4. STOCK OUT - a valid Stock Out succeeds - the stock decreases correctly - a movement record is created 5. NEGATIVE STOCK Attempt a Stock Out larger than the current inventory. Verify the operation is rejected, the current stock is unchanged, and NO movement record was created. 6. ATOMICITY Using the smallest safe focused test available, verify the trusted stock operation keeps the product's current stock and the movement history consistent — they move together or not at all. Do not build an expensive concurrency or load-testing suite. 7. DIRECT STOCK WRITE Verify normal client code cannot bypass the history by setting current_stock through an ordinary product update. Test the data layer directly, not only the UI. 8. LOW STOCK - the threshold works - Out of Stock works at zero - restocking clears the warning correctly 9. HISTORY - movement history persists after a refresh - normal staff cannot casually rewrite or delete audit history 10. AUTHORIZATION - staff login works - a non-staff authenticated user cannot perform inventory operations - authorization is enforced beyond hidden UI 11. SECRETS Confirm no Supabase Secret or service-role credential exists anywhere in browser code. Return exactly one: INVENTORY SYSTEM VERIFIED or: NEEDS ATTENTION Use INVENTORY SYSTEM VERIFIED only if stock changes are correct, movement history stays consistent, negative inventory is blocked, the low-stock state works, and staff authorization is enforced. If NEEDS ATTENTION, list only the remaining inventory issues.

Run one final Stock In and Stock Out operation and confirm both current stock and movement history match before deployment.

Deploy the Inventory 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

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 inventory 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 Inventory App

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:

Staff: sign in and open the dashboard

Staff: create a test product and record its initial stock

Staff: Stock In and Stock Out both work

Staff: the quantity and the history are both correct

Staff: take stock down far enough to trigger Low Stock

Security: a signed-out user cannot reach inventory operations

Security: an unauthorized account cannot change stock

Data: refresh — stock and history both persist

Mobile: Stock In and Stock Out are usable on a phone

Tablet: the dashboard is still usable

Verify the Live Inventory System

Check the live Hostinger inventory workflow from product creation through stock movements before using it with real inventory.

Perform a focused production verification of this Inventory Management System now that it is live on Hostinger. Do not add features. 1. GITHUB - the approved source is what is actually deployed - no real secret file is committed 2. HOSTINGER - the deployment succeeded - the correct repository and branch are connected - every required production variable is configured - the build and runtime configuration are correct 3. SUPABASE - the intended project is used - staff authentication works - authorization is enforced - the trusted stock operation works against the production database - private credentials remain private 4. PRODUCT - a test product can be created - its initial stock is represented correctly, with a movement record 5. STOCK - Stock In works - Stock Out works - a negative-stock attempt is rejected - the current quantity stays correct 6. HISTORY - every successful change has a matching movement - the failed negative-stock operation created NO movement 7. LOW STOCK - the threshold state works 8. ACCESS - signed-out users cannot perform inventory management - unauthorized accounts cannot mutate stock Return exactly one: INVENTORY APP LIVE or: NEEDS ATTENTION If INVENTORY APP LIVE, summarize: product management, stock accuracy, movement history, low-stock behaviour, staff authorization, and the deployment. If NEEDS ATTENTION, list only launch blockers.

Perform one final live Stock In and Stock Out operation and verify the movement history before adding real inventory.