Wholesale Stock Management App (Tamil Nadu)

The problem

The wholesale business is a real wholesale shop in Tamil Nadu — the kind of business that's been operating the same way for decades. Three locations: a shop, a godown warehouse, and a retail counter. Around 978 different products. Stock boys who walk through the godown every morning counting cartons. Customers walking up to the counter asking "do you have this?". An owner who needs to know what's where, what's running out, and who's been doing the work.

The whole operation was running on paper count sheets.

• Every morning a stock boy would print or pull out a fresh count sheet
• He'd walk through the godown writing down quantities next to product names
• At the end of the round, the sheet would go back to the office
• Somebody — usually the owner himself — would re-enter it into an Excel file
• The shop counter would call the godown to ask "do we have any of this?" because the Excel file was always 6 hours behind reality
• Sheets got lost, smudged, mixed up between days
• Nobody knew exactly who had counted what or when
• Items would run out before anyone noticed they were getting low

The problem wasn't lack of effort. It was that the information lived in the wrong format — on paper, in someone's head, in an outdated Excel file — instead of in one live system that everyone could see.

The owner's brief was simple but specific:

1. Build a mobile app the stock boys can use right in the godown. Not a desktop tool. Not a web form they have to walk back to. Something on their phone, while they're standing next to the product.
2. It has to work in Tamil. Not just menu labels — the actual product names. The workers read Tamil better than English. The system has to speak their language.
3. The owner needs to control who can log in from which phone. Not via SMS (unreliable in a Tamil Nadu wholesale neighborhood). The owner himself approves each device — face to face — by telling the worker a code.
4. The shop counter, the godown, and the office all need to see the same numbers in real time.
5. Reports and minimum stock alerts so the owner doesn't have to remember to check anything.
6. Workers must be restricted to specific godowns — a worker assigned to the shop shouldn't accidentally enter stock for the warehouse.

---

The approach

A wholesale shop in Tamil Nadu is not a SaaS user persona that exists in any product playbook. We had to build for the actual people who would actually use the app, in the actual conditions they'd use it in: a worker holding a phone in one hand and a stack of cartons in the other, in a noisy godown, in 35°C heat, with patchy mobile signal, in Tamil.

That meant several decisions up front:

The app has to be mobile-first and one-handed. Not "responsive web." Not "we'll build a website and hope it works on phones." A real mobile app, installable from the Play Store and App Store, with tap targets sized for thumbs and a navigation that works while you're walking.

Tamil is not an afterthought. The system stores every product name in both English and Tamil, and the worker picks the language at login. The whole UI — labels, buttons, error messages, validation messages — gets translated. The Tamil version isn't a Google-translate slap-job; it's the same translations the owner himself uses when talking about his products.

Authentication has to fit the owner's actual workflow. SMS-based OTP is the standard SaaS pattern. It would have failed here. SMS is unreliable in the area, telecom costs add up, and the owner specifically wanted to be the one approving new phones — not a third-party SMS service. So we built a device-trust system where the owner sees the OTP in his admin panel and tells the worker face to face. When the worker enters the code, that specific phone is trusted forever for that worker. New phone? New code. The owner is always in the loop.

The data lives in the existing system. The wholesale business already had a legacy "Nova" inventory database with all 978 products, 36 units of measurement, and 3 godown codes. We didn't replace it. We connected to it directly so the master data stayed where the business already trusted it, and only the new app-specific data (users, devices, login codes, activity logs) lived in our own database.

This is the same architectural decision we keep making: don't fight the systems the client already trusts. Bridge to them.

---

What we built

A real mobile app — installable, fast, Tamil-friendly

• Native-feeling mobile app for both Android and iPhone
• Tab-bar navigation: Dashboard, Stock, Entry, Reports, Settings
• Tap targets sized for thumbs
• Voice search to find an item without scrolling
• Smooth list rendering even with 978 products in the catalogue
• Cards designed for one-handed use while the other hand is holding a carton
• Tamil + English throughout — including the actual product names

The stock-counting flow — the most-used screen

• Pick a location (Shop, Godown, or Retail)
• See the full list of items for that location, with their codes, names, units, and current quantities
• Tap an item, type the new quantity, save
• Move to the next item
• The whole catalogue can be counted in one continuous session, or split across multiple sessions over multiple days
• The app remembers exactly who counted which item, in which location, on which date — full audit trail

Master data that talks to the legacy system

• 978 products pulled live from the existing Nova inventory database
• 36 units of measurement (pieces, kilos, litres, packets, bags, etc.)
• 3 godown locations (Shop, Godown, Retail)
• All updates to product names, units, or godowns happen in the legacy system and the app picks them up automatically — the owner doesn't have to maintain two product catalogues

Min stock level alerts

• Each item has a minimum stock level the owner can set
• If actual stock drops below the minimum, the item shows up in a low-stock report
• The owner sees what to reorder before it runs out
• Min levels can be set per item, edited any time, and apply across all godowns

Reports — pulled by the owner himself

• Daily stock report — what was counted today, by which worker, in which location
• Stock summary — total items, total stock, how many are low, how many are out
• Low stock report — everything below minimum
• Activity log — every action by every user, timestamped, filterable
• Entries report — stock entries grouped by date, by worker, by location

The owner used to wait for these reports. Now he runs them himself in 2 seconds.

User management built for trust

• Two roles: Admin (the owner) and Stock Boy (workers)
• Admins manage users and have access to everything
• Stock boys are restricted to specific godowns they're allowed to work in — a worker assigned to "Shop only" cannot accidentally enter data for the godown
• Each user has their own login, their own activity history
• Users can be deactivated (e.g. if a worker leaves) without losing their historical data

The device-based authentication flow (the part the owner specifically asked for)

This is where the project gets interesting. The owner wanted total control over which phones could log into his system, without depending on SMS:

1. A new stock boy installs the app on his phone
2. He enters his username and password the owner gave him
3. The system checks: is this device already trusted? If yes → log him in, done.
4. If no → generate a 6-digit code, save it in the database with a 5-minute expiry
5. Show the worker an "OTP required" screen: "Ask the admin for your code."
6. The owner opens his admin panel and sees a list of "Pending OTPs" — every active code with the worker's name and the device it came from
7. The owner reads the code aloud to the worker (no SMS, no email — face-to-face only)
8. Worker types the code in
9. Device is now permanently trusted for that worker
10. Future logins from that exact phone are instant — no OTP needed

The owner has total control. A worker who shares his password is harmless because the new phone still needs the owner's approval. If a worker leaves, the owner can revoke device trust with one click. New phone? Worker walks up to the owner and gets a fresh code in 30 seconds.

Activity logging

Every action by every user is logged: who logged in, who counted which item, who created which entry, who edited what. Filterable by user, action type, date range. The owner can answer "who did this?" in 5 seconds for any change in the system, going back as far as he wants.

Real-time visibility across locations

The shop counter, the godown, and the office are all looking at the same numbers. When a stock boy enters a count in the godown at 9:15 AM, the shop counter sees the updated number at 9:15 AM. No "let me call the godown and ask." No "I'll check after lunch."

Production-grade deployment

• The app is published on Android (with the APK file ready) and is set up for iPhone deployment
• The backend runs on a dedicated cloud server with a real domain
• HTTPS / SSL throughout
• Automatic database backups
• The owner's data is safe even if the server has a bad day

---

The hard part — and how we solved it

There were two really interesting design challenges on this project, and they came from the same root: building software for a Tamil Nadu wholesale shop in 2026 means the user is not the user product playbooks were written for.

Hard part #1 — Tamil-first product names

Most apps that "support Tamil" mean "the menu labels are translated, the data is still in English." That's useless when the entire product catalogue is in Tamil. A worker who knows the product as "அரிசி கட்டு" (rice bag) can't be expected to find it under "Rice Bag" in an English list.

We solved this by storing two names for every product — the English name and the Tamil name (called font in the legacy database). The worker picks his preferred language at login, and the entire product list switches. Search works in both languages — type "rice" in English mode and you find rice products; type "அரிசி" in Tamil mode and you find the same products. Voice search works the same way.

For the owner, this had a side benefit: he could let any worker — regardless of which language they read better — use the same app. New workers stopped needing English literacy as a job requirement.

Hard part #2 — Authentication that fits the actual workflow

The default SaaS authentication pattern (login → SMS OTP → done) does not work for the wholesale business. SMS is unreliable in their area. The owner specifically wanted to be in the loop on every new device — that's part of how he runs his business. And a Tamil Nadu wholesale shop doesn't want to depend on a third-party SMS gateway.

We built the owner-mediated OTP flow: when a worker tries to log in from a new device, the system generates a code and shows it in the owner's admin panel. The owner reads it to the worker. Worker types it in. Device trusted.

This sounds simple but it required getting several things right:

• Pending OTPs screen for the admin (with auto-refresh, expiration timers, the worker's name, the device fingerprint)
• Device fingerprinting that's stable enough to recognize the same phone but private enough not to leak personal data (we used a UUID stored in the device's secure storage)
• Trust persistence — once trusted, the device stays trusted forever for that user, no re-verification on every login
• Trust revocation — the owner can revoke trust for any device with one click (e.g. when a worker leaves)
• Edge cases — what if two workers try to log in from the same phone? What if the phone is reset? What if the worker uninstalls the app and reinstalls? Each one handled.

The result: a login flow that fits how the owner actually wants to run his shop, instead of forcing him to fit how the typical SaaS sign-up works.

---

The outcome

• Live in production at the wholesale business in Tamil Nadu, running their daily stock operations
• 978 products managed across 3 locations (Shop, Godown, Retail)
• Replaced paper count sheets with a mobile app workers actually use in the godown
• Tamil + English throughout — product names, UI labels, search, voice search
• Owner-mediated device trust — the owner approves every new phone face-to-face, no SMS dependency
• Per-godown access control for workers
• Real-time visibility across all 3 locations — shop counter, godown, office all see the same numbers instantly
• Min stock level alerts so the owner sees what to reorder before it runs out
• 5 reports the owner runs himself (daily stock, summary, low stock, activity log, entries by date)
• Connected to the legacy Nova system so master data stays in one place and the app picks up product updates automatically
• Native mobile for Android and iPhone, with HTTPS production deployment on a dedicated cloud server

The bigger outcome: a real Tamil Nadu wholesale shop stopped running on paper, started running on a system that fits the language they speak, the trust model the owner uses, and the actual conditions in the godown.

This is what real software for real Indian businesses looks like. Not a SaaS subscription. Not a generic inventory tool from somewhere else. Software built for the wholesale business, in Tamil, in the owner's hand.