Products and stock
Per-shop stock levels, purchase entry, and a stock adjustment that records who changed what and why.
CASE STUDY
Example buildCustom SoftwareInventory & Billing for Retail
Stock that matches the shelf, GST-ready bills in seconds, and an alert before a fast seller runs out.
- Type
- Custom software
- Build time
- 10–14 weeks
- Platforms
- Counter desktop, phone for stock
- Starts at
- ₹1,00,000*
This is an example build. Tavzuran is a new studio with no client work to show yet. This page describes how the project would be scoped and built — the same thinking you would get on a real one. Nothing here is a past client, and no number on this page is a result.
The price follows the feature list. The number above buys everything scoped on this page. Take features out and it comes down — the shortest route to a smaller number is a shorter list, and deciding what to drop is what the free call is for.
THE SITUATION
What's actually broken.
A retailer with two shops tracks stock in a register and bills by hand. Nobody knows what is genuinely in stock until someone counts it, and the count is wrong by the time it is finished.
The temptation is to buy an off-the-shelf POS. Sometimes that is the right answer and I will say so. It stops being the right answer when the business has a real quirk — loose quantities, custom bundles, credit for regulars — that the packaged product refuses to model.
Stock on paper never matches stock on the shelf
Fast-selling items run out before anyone notices
Bills are handwritten and GST is reconciled monthly by hand
No idea which products actually make money
VERSION ONE
What we'd build first.
Every item here earns its place by being something a real user would miss on day one.
Billing at the counter
Fast enough to use with a customer waiting: barcode or search, quantity, discount, GST-compliant invoice, print or WhatsApp.
Low-stock alerts
Per product, based on how fast it actually sells rather than a number someone guessed once.
Day-end summary
Sales, payment modes, and what left the shelf. One screen the owner reads on the way home.
Simple margins
Purchase price against selling price, so the products that look busy but earn nothing become visible.
DELIBERATELY NOT IN V1
What we'd leave out.
Not because these are bad ideas. Because each one is designed better once the first version has told you something.
- Full accounting. Export to whatever the accountant already uses instead of rebuilding Tally badly.
- E-commerce and online ordering — a separate project once the stock data is trustworthy.
- Loyalty schemes, until there is purchase history to base one on.
UNDER THE HOOD
How it's put together.
- Counter app
- A web app that works offline for billing, because a shop cannot stop selling when the internet drops
- Stock app
- The same app on a phone, for counting on the shelf
- Backend
- Node with Postgres
- Printing
- Standard thermal printers over the browser
- Invoices
- GST-compliant numbering and formats from day one — retrofitting this later is genuinely painful
HOW IT RUNS
Week by week.
-
01
Week 1
Watch a real day at the counter. What gets typed, what gets skipped, where the queue builds.
-
02
Weeks 2–7
Products, stock and purchase entry.
-
03
Weeks 8–11
Billing, printing and GST formats.
-
04
Weeks 12–14
One shop runs it alongside the register for a week or two.
THE HARD PART
Billing fast enough for a queue
Every build has one problem that decides whether the rest of it matters. This is that problem, written out.
Every design decision at the counter is governed by one number: how long the customer in front is willing to stand there. If billing is slower than the handwritten book, staff will keep the book, and every other feature — stock, alerts, margins — is built on data that never arrives.
That pushes hard on the interface. Search that matches on partial names and local spellings, because nobody types a full product name with a queue forming. Keyboard-first operation, since a mouse is slower than a barcode scanner and a numeric keypad. Quantity and discount reachable without leaving the keyboard.
And it has to keep working when the internet does not. A shop cannot stop selling because a router rebooted, so billing runs against local storage and syncs after — which then brings back the reconciliation problem, and is why invoice numbers are issued in a way that cannot collide when two terminals come back online together.
BEFORE A PRICE EXISTS
What we'd ask you first.
A quote given without these answers is a guess. These are the questions that actually move the number.
- 01Roughly how many distinct products, and how often do they change?
- 02Which GST slabs apply, and do you issue credit notes?
- 03Are products barcoded, or is it search by name at the counter?
- 04Do regular customers buy on credit, and how is that tracked now?
- 05When was stock last counted properly?
AFTERWARDS
How we'd know it worked.
Agreed before the build starts, so there is something to judge it against other than whether it looks nice.
- A typical five-item bill takes under thirty seconds end to end.
- Counted stock and recorded stock are within a couple of per cent.
- Low-stock alerts are acted on rather than dismissed.
- The day-end total matches the till without anyone reconciling by hand.
BEFORE YOU START
Worth knowing.
Getting the opening stock right is the hardest day of this project and it is your team's day, not mine. Budget a full count before go-live; every wrong number carries forward.
Websites and apps start at ₹20,000*. Final pricing depends on features and project scope. Third-party costs — cloud hosting, domains, external libraries, APIs, app-store fees and any other paid service — are billed separately and are not included.
KEEP LOOKING
Other example builds.
Web App
Clinic Appointments & Records
Appointments, patient history and prescriptions in one place, with reminders that cut the empty slots.
Read the case study Mobile AppGym Membership App
Digital membership, quick check-in, class booking and renewal reminders that actually go out.
Read the case study Mobile AppField Service Job App
Dispatch, on-site checklists, photo proof and an invoice raised before the technician leaves.
Read the case studyWant this built for your business?
Tell us what you're thinking. We'll figure out the next step together.
Free 20-min idea call · No obligation