OM ENTERPRISE Catalogue, counter billing and GST invoices for a building-materials shop.

OM ENTERPRISE sells paints, water tanks, bathware, CPVC, PVC, UPVC and SWR pipes and fittings, and plumbing accessories from a counter on Bodeli Road in Naswadi, Chhota Udaipur district, Gujarat.

StackWise built the shop one connected system: a public website where customers browse 357 products across 8 categories and 9 brands and send an enquiry list as an order request; a point of sale where counter staff complete a sale with prices calculated on the server; an admin dashboard for products, pricing, approvals, payments, bills, customers, staff and reports; and a phone app for the owner to approve discounts and see the day's money from anywhere. All of it reads one price list in one PostgreSQL database.

A building-materials counter carries hundreds of items in many sizes and pressure classes, and the prices live in supplier price lists: PDFs, Excel sheets and scanned pages, some with Hindi or Gujarati headings. Customers phoned to ask what was in stock and what it cost, and every answer depended on who picked up.

Billing had its own rules. The shop issues GST documents, so each sale needs the right document type, a gapless number per financial year, and a layout the accountant and customers already trust. Staff needed room to give a discount within a limit, with anything larger approved by the owner even when he was out of the shop.

No online payment on the public site: customers send a list, the shop confirms availability and price, and payment happens at the counter. The bill PDF had to match the shop's existing A4 bill exactly, down to the layout the owner was used to.

The system had to run on hosting that costs little or nothing (Vercel and Neon), need no paid service to work, and print names in Hindi and Gujarati. Real bills stay blocked until the owner confirms the GST registration type, because the document rules follow from it.

Three apps in one Next.js 16 codebase: the public site, the counter POS and the dashboard, plus the owner's phone app. Every one of the 98 API routes passes through the same wrapper: origin check, session, permission, then validation, so authorization is enforced on the server and never by hiding a button.

Pricing is one engine, written with exact decimal arithmetic, used by the POS, quotations, website order requests, bills, credit notes and reports. The browser never sends a price; every cart change is re-priced on the server from the active price version.

PostgreSQL (Drizzle, 39 tables, hosted on Neon) protects financial history itself: triggers keep audit logs append-only, freeze a finalized sale, allow issued documents to be cancelled but never edited, and keep document numbers moving forward. Each issued bill stores a complete snapshot, and the A4 PDF renders from that snapshot, so a reprint years later is identical.

The catalogue importer accepts Excel, CSV, PDF, Word, ODS, HTML and photos; scanned price lists go through OCR in English, Hindi and Gujarati, then into a review queue before anything is published. Payments cover an exact-amount UPI QR with manual UTR verification, cash, card, bank transfer, cheque and split payments, with a Razorpay webhook path built against the published API. Bills go out by email, WhatsApp or a share link.

No online payments on the website, on purpose. For a counter that deals in pipe lengths and tank sizes, confirming availability and price before money changes hands avoids refunds and arguments, and it matches how the shop already works.

Re-pricing every cart change on the server costs a round trip, but it removes a whole class of bugs where the browser and the bill disagree.

The database enforces rules the application also enforces. That is deliberate duplication: if a future change to the app gets something wrong, the history of bills and payments still cannot be edited or deleted.

Two parts are honest about their limits. The Razorpay path was built and tested against simulated signed webhooks, not a live account, and the GST document rules follow published CBIC guidance that the shop's accountant has to confirm before real bills are issued.

Start with the import. Getting 357 products in from seven file formats and scanned pages took more care than any screen, and until the catalogue was real nothing else could be judged.

The bill mattered more to the owner than any dashboard. Matching the existing A4 layout exactly was the moment the system felt like his, and it should have come earlier.

The owner's phone app came last and should have come first. Approving a discount from wherever he is was the feature he used on day one.