Every unit accounted for — by VIN, or by SKU.
A car showroom sells one specific vehicle with one specific engine number. A furniture store sells three of the same sofa. Mizenzo Showroom is built for both, with the vertical chosen when the business is created and everything downstream — fields, screens, stock behaviour — following from it.
The buy side matters as much as the sell side.
Because a showroom that only records sales cannot tell you whether it made money on them.
Two verticals, one system
Automotive tracks a serialised unit — this vehicle, this VIN, this engine number — and a sale allocates that exact unit. Home Goods tracks a SKU with a quantity, and a sale decrements it. The vertical is chosen at setup and never drifts afterwards.
Landed cost, done properly
Freight and unloading are apportioned across the purchase lines by value. A vehicle that cost 85,00,000 ex-works and 85,000 to transport enters stock at 85,85,000 — so selling it at 85,40,000 is reported as the loss it is, instead of a break-even. This is the entire reason the buy side is not just typing a cost into a stock screen.
Purchases, GRN and returns
A purchase is a document: a draft does nothing to stock, and committing it receives the units, creates the movements and raises the payment voucher. Purchase returns are blocked once a unit has been sold.
Invoicing and party ledgers
An invoice allocates the specific unit or decrements the quantity, raises the receipt and updates the customer ledger. Supplier: purchased minus paid equals payable. Customer: invoiced minus paid equals receivable. Sale returns are blocked once the invoice has been paid.
Stock that cannot quietly drift
Stock movements are append-only and the stock on hand is always derived from them, never stored as a number somebody can overwrite. Issuing online refuses to oversell, because the server knows the true balance.
Locations that match the yard
Showroom Floor and Stockyard for a dealership; Display and Warehouse for a home store — with transfers between them, so "where is it" has an answer.
Documents are legal documents
An issued invoice reprints identically after any price or tax change, because its totals and line descriptions are snapshots. Document numbers carry a device segment, so two counters can never mint the same invoice number.
Money maths that never drifts
Money is stored as whole minor units, quantity is scaled by a thousand, and tax and discount rates are held in basis points. Never floating point — because 0.1 + 0.2 becomes a support call when the customer is holding the printed invoice.
Built now so the offline counter can exist later.
Phase one is the web application. The rules below cost almost nothing today and are extremely expensive to retrofit — they are what will let the same system run on a desktop counter machine with the internet down.
- Every screen talks only to a repository interface. No screen calls the network directly, so a local database can be swapped in underneath without rewriting the application.
- All money and stock maths is shared, pure code, so the server, an offline desktop and the invoice printer produce identical numbers to the paisa.
- Record identifiers are generated on the device, never by the database — an offline machine must be able to mint a final identifier before the server has ever seen it.
- Nothing is hard-deleted. A deleted row cannot replicate to a device that was offline; there would be nothing left to carry the news.
- An offline sale that is replayed is always accepted and reported afterwards, because rejecting it would make a sale disappear after the customer has taken the goods home.
What is in the system.
Phase one covers the full trading cycle, from the supplier's invoice to the customer's receipt.
1Stock
- Serialised units by VIN and engine number
- Quantity-tracked SKUs
- Locations and transfers
- Append-only movements, derived stock on hand
- Valuation at landed cost
2Buying
- Purchase orders and GRN
- Landed cost apportionment
- Supplier returns, blocked once sold
- Payment vouchers
- Supplier ledger — purchased minus paid
3Selling
- Invoices that allocate the exact unit
- Receipts and part payments
- Sale returns, blocked once paid
- Customer ledger — invoiced minus paid
- Snapshot totals that reprint identically
4Money
- Tax and discount in basis points
- Integer minor units — no floating point
- Receivables and payables
- Document numbering with a device segment
5Verticals
- Automotive — car and bike showrooms
- Home Goods — furniture and home stores
- Vertical-specific fields and screens
- Chosen once, at setup
6Roadmap
- Phase 1 — web application (in progress)
- Phase 2 — offline desktop counter
- Phase 3 — mobile app for the floor salesperson
- Phase 4 — test drive, RTO, finance EMI, trade-in
The technical detail
| Architecture | Fastify with a typed API and Drizzle on PostgreSQL; React web application |
| Data model | 25 tables, with PostgreSQL as the single source of truth |
| Verticals | AUTOMOTIVE (serialised) or HOME_GOODS (quantity), fixed when the business is created |
| Money | Stored as integer minor units; quantity scaled by 1,000; tax in basis points |
| Testing | 121 unit tests that need no database, plus 52 integration tests against a real PostgreSQL |
| Platform | Web today; an offline desktop counter and a mobile app are on the roadmap |
| Deletion | Soft deletes only — history is never destroyed |
| Numbering | Invoice and purchase numbers carry a device segment, e.g. INV-D1-000042 |
The web application is deliberately online-only. Browser storage carries no durability guarantee, and a system holding stock and money cannot rest on "probably still there". Offline belongs to the desktop and mobile applications, which own a real filesystem.
Mizenzo Showroom — common questions
Yes — that is the automotive vertical. Each vehicle is a physical unit with its own VIN and engine number, held at a location such as the showroom floor or the stockyard, and a sale allocates that exact unit rather than reducing a count.
Yes. In the home-goods vertical stock is a SKU with a quantity held at a display area or a warehouse, and a sale decrements the quantity. The fields and screens change to match; you choose the vertical once, at setup.
Because without it your margin is fiction. Freight and unloading get spread across the purchase lines by value, so each unit carries its true cost and a sale below that cost is reported as a loss instead of quietly looking like a break-even.
The web application needs a connection — by design, because browser storage is not durable enough to hold stock and money. An offline desktop counter using a real local database is the next phase, and the system has been built from the start so that it can be added without rewriting the screens.
Har gaari, har unit — poora hisaab.
Tell us whether you run a vehicle showroom or a home-goods store, and we will show you the matching setup — purchases with landed cost, the stock floor and the ledgers — on your own screen.