Godam

Problem

Distributors run their business across spreadsheets: who owes what, what left the warehouse, which cheque is still out, which salesperson visited which shop. The real problem isn't "there's no app". It's ending up with two different numbers for the same customer.

So the app has to be built around how trading actually works: a business can be a supplier, a customer or both; stock items have reorder levels; amounts are in Nepali rupees. A generic template wouldn't fit.

Constraints

I built it alone. The screens are designed for phones (at most 480px wide), because daily sales reports and collections are entered out in the field.

There are three kinds of users (admin, staff and view-only), and view-only users must never be able to change the books.

How it works

It's a Next.js app hosted on Vercel, with the data in Supabase (Postgres). Each screen matches a real task: accounts (businesses and stock items), warehouse stock, cash, collections, supplier payments, outgoing cheques, trade deals, daily sales reports, field visits and reports.

Every business record carries its VAT and PAN numbers, amounts are shown in Nepali rupees, and each user's role decides what they're allowed to add or change.

There's no AI model involved in the day-to-day work. Reliability here comes from the database keeping the records consistent and from checking who's allowed to change what, not from a prompt.

How I made it reliable

The database is the official record. What the phone shows is just a copy of what's in the database, never a separate version of the books.

The app checks each user's role (admin, staff or view-only) before any change is saved. That check runs in the app, on top of Supabase's login system. It isn't a replacement for rules inside the database itself, which I plan to tighten.

I haven't published an automated test set for Godam. The real test is whether a day's collections and stock movements match the records, and that's checked by reconciling, not by a model score.

Known failure modes

• Permissions are checked in the app, not yet in the database

  The app stops view-only users from changing the books. But if someone went around the app and talked to the database directly, that rule would only hold if the database enforced it too (Postgres row-level security). Moving those checks into the database is the next step (see below).

• No automated test of the books yet

  Unlike Stacksift, there's no set of example cases with known correct answers. A mistake in how an entry is recorded would be caught by a person reconciling the day, not by an automated check.

What I would do differently

• Move the key rules into the database itself (who can change what, no duplicate cheque numbers, credit never more than the invoice balance), so the app isn't the only thing enforcing them.
• Record a full example trading day that can be replayed automatically, with checks that every balance comes out right: the ledger equivalent of Stacksift's answer sheet.