← All work
Hindustan Auto SuppliersLive

Hindusthan Earthmovers CRM

A branch-aware customer, follow-up and stock system for a heavy earthmoving equipment dealership. Nine users work inside the same system without crossing the boundaries of their role or branch.

Client
Hindustan Auto Suppliers
Sector
Heavy earthmoving equipment dealership, multi-branch, eastern India
Status
Live, in daily use
Live since
July 2026
Stack
React + Vite + Tailwind / Express + better-sqlite3, session auth
Scale
9 users across multiple branches
01

The problem

The branch sales operation ran on memory and spreadsheets. Customers were tied to individual sales officers, but follow-ups promised on calls could be forgotten. Stock lived across separate registers.

The owner needed to see across the dealership. Branch managers needed only their branch. Sales officers needed only their own customer book. A single shared spreadsheet could not make those boundaries real.

The system had to bring customers, follow-ups, products, stock and machines together without making visibility an informal rule that staff had to remember.


02

What we built

The operating surface used across the dealership.

M-01Customers
M-02Follow-ups
M-03Sales officers
M-04Offices & branches
M-05Products
M-06Price lists
M-07Vendors
M-08Stock book
M-09Stock balance
M-10Stock entry
M-11Stock transfer
M-12Machines
M-13Locations
M-14Users & roles
M-15Dashboard
M-16Data entry

03

The hard parts

The work behind a CRM people can trust with branch data.

A permission model with two independent axes

data_scope controls what a role can see. edit_scope separately controls what it can change. Both are enforced server-side and re-checked on every route.

A branch manager sees their branch. A sales officer sees their own customers. The owner sees everything. The client UI mirrors those rules, but it never decides them.

Visibility was keyed to the wrong column

Customers are tagged to people through customers.officer_idsales_officers. The assigned-scope filter was reading the unused customers.assigned_tousers path instead.

One sales officer, Punam, could log in and see nothing. We replayed her exact queries against a copy of production. After the fix, her view moved from 0 to 13 customers and from 0 to 18 follow-ups.

An eight-finding security sweep before it was trusted

The review found an IDOR on the officer detail route, a privilege-escalation path in user management, a roster leak through the pickers endpoint, and a cross-branch escape.

Users did not find them. Review did. All eight findings were fixed and verified live before the system was treated as trusted.

No seed script, on purpose

The original demo seeder wiped data, so it was deleted. migrate.js only adds columns and tables. It does not reset the database.

The database is excluded from every rsync. The deploy’s --delete cannot reach an excluded file.


04

How we know it works

0→13customers restored for the officer who could see nothing
8security findings fixed before the system was trusted
21scenario permission smoke test
7-daybackup retention, taken hourly
← Previous caseParts & Pricing Next case →TIPL Operations

Tell us what your business runs on today.

Show us the registers, spreadsheets and hand-offs that hold the operation together. We will map where a custom system would pay for itself.