A retail operating system for Indian shops
Most billing apps stop after the first box. Profit is only true once all six are in one ledger.
Where it started
The first version was built for one real business - a saree shop billing customers at a counter. Everything in the product came from watching that shop work.
Before Filarity
Bill book
Sales
Notebook
Stock counted by hand
Excel
Purchases
Shopify
Online orders
Expenses
The accountant
GST
“So how much did the shop actually make this month?”
Six places to look, and no single answer.
TL;DRNot a hypothetical SaaS idea. A real shop that could not tell you what it earned.
The problems
Every one of these is a business problem before it is a software problem.
The people
Pick one to see what they came for, and what the product deliberately keeps from them.
“I need to know whether my shop is actually making money.”
Primary tasks
Sees
Everything, including cost price and margin.
Never sees
Nothing.
The interface hides what a role should not see. The server refuses it regardless - the UI is not the security boundary.
Information architecture
The challenge was never fitting more features into a menu. It was finding a mental model that matched how the shop already operates.
The navigation is grouped by the question a shop is asking, not by the database table underneath. The hard part was never fitting more features into a menu - it was finding a mental model that matched how the shop already thinks about its day.
Design
Observe, ship something small, then let daily use at the counter decide what comes next.
Observe
Watched what actually happened between a customer picking a saree and the shop knowing whether it made money on it.
Map
Wrote down where every number lived, and which of them nobody could reconcile.
Ship the smallest useful thing
Version one did one job: type a bill, see it render, print it or send it on WhatsApp. It was at the counter before stock, purchases or GST existed.
Follow the money outwards
Invoices gave revenue. Purchases gave cost and stock. Expenses gave the rest. Only then did a profit number mean anything.
Refine against daily use
Everything after version one was added because real use at the counter exposed the next gap - not because it was on a roadmap.
Generalise into a product
Accounts, trials, subscriptions, an admin console, and a public read-only demo so anyone can walk the real app without signing up.
Seven steps, and a decision is needed in only three of them.
Scan or pick
Barcode at the counter, or search by name. Stock and price come with it.
Seven steps, and the cashier makes a decision in only three of them. Everything tax-shaped happens without being asked about.
Six rules the product is actually held to.
Don’t make the shop owner think like an accountant
GST is calculated and shown, never asked for.
One source of truth
Counter, Shopify and purchases all write to the same stock number.
Show consequences, not just data
A sale does not only record revenue - it moves stock and books the cost.
Capture it when it happens
Expenses take a receipt photo at the moment of spending, not at month end.
Design around business questions
Navigation is grouped by what the shop is asking, not by database table.
Never guess an irreversible default
GST registration is asked, because it can be switched on but never off.
TL;DRThe interface hides the accounting so the shop never has to think like an accountant.
The money model
This is the product’s whole argument. Click through a single sale and watch what it touches.
Step 1 of 7
₹2,360 paid at the counter.
Invoice created
Revenue minus everything - which is why the dashboard was designed last.
A billing app would have stopped at the first bar. The dashboard was designed last, on purpose - a profit number means nothing until every outflow is in.
Same total either way. The split is derived, never chosen.
The cashier never picks between these. The split is derived from the buyer’s GSTIN and the total is the same either way - but filing the wrong one is a filing error, not a display bug.
A purchase bill is only claimable if the supplier really filed it.
The bill appears in GSTR-2B, so the credit is safe to claim.
The counter, Shopify and supplier bills all move the same figure.
One inventory model
Two stock counts drift, and the customer is the one who finds out. Every channel writes to the same number.
An online order behaves exactly like a counter sale: stock moves, revenue lands, and the dashboard is already right.
Product decisions
Product management on my own work meant deciding what the app refuses to do.
Should GST complexity be visible to the user?
Hide it. Show the result.
Where should the dashboard stop?
Not at revenue. At real profit.
How does someone evaluate this without signing up?
A public read-only demo of the real app.
What should a Google sign-up assume?
Nothing irreversible. Ask instead.
How much should entering a supplier bill demand?
Two modes: fully itemised, or file it with a photo.
What should staff be able to see?
Only the sections the owner switches on.
CGST/SGST/IGST split from the buyer’s GSTIN, HSN codes, live preview, A5 print, PDF export, one-tap WhatsApp delivery.
Every sale and purchase bill moves stock. Barcode scanning at the counter, printable label sheets, low-stock views.
Supplier bills bring stock in and create a payable. Two entry modes: fully itemised, or file the bill with a photo.
Ads, rent, shipping and salaries with receipt photos - so profit is revenue minus everything, not revenue minus cost of goods.
GSTR-1 export, GSTR-2B upload and reconciliation, per-purchase ITC eligibility, and a monthly sheet emailed to the accountant automatically.
Shopify OAuth and webhooks pull orders in and push inventory back. A5 delivery slips, courier tracking, one pipeline for both channels.
Owner, staff with per-section permissions, and a read-only accountant login that can read the books and never write to them.
A separate console for accounts, trials and subscriptions. The marketing site reads the plan price from a public feed, so a price change needs no redeploy.
Engineering
The architecture exists to serve the product above it. Pick a piece to see what it does.
API routes
Around 77 endpoints. Every one sits behind a single authorisation gate rather than carrying its own permission check.
Switch role and the interface changes. The server changes too - and it is the one that counts.
Hiding a menu item is a courtesy, not a control. Every request also passes a single edge proxy that resolves the session and applies that role’s allow-list, so a write from an accountant or demo session is refused before any handler runs.
A customer must never see another customer’s books.
Shop A
Shop B
One customer must never see another’s books. Isolation is enforced on every query, and it is a rendering problem too - uploads are validated down to self-contained raster images, so one tenant cannot plant a tracking pixel that fires in another’s session.
Vercel for both sites, Neon for Postgres, an idempotent migration runner for schema changes, scheduled jobs for the monthly accountant report, and audit logging on anything that touches money.
TL;DREngineering here is in service of the experience - not the other way round.
Outcome
Not a concept, and not a prototype. A working counter uses this to bill customers.
Before
Six places to look, and no single answer.
After
One system, one ledger, one profit number.
Result
Sales, stock, expenses, GST and profit in one place.
There is a public read-only demo seeded with a fictional shop’s trading, so you can walk the real application - the dashboard, billing, stock, purchases, GST - without signing up for anything.
