Know who's working where — and whether their access is actually gone.
A focused internal tool for HR/Ops teams to onboard vendor-supplied warehouse workers, track daily attendance, control their access to Increff and Unicommerce, and offboard them — with a hard guarantee that nobody keeps live system access after they leave.
- WMS systems
- Increff · Unicomm
- Access states tracked
- 6
- Warehouses
- Multi-site
- Stack
- Django + Postgres
What this is
One job, done properly
It's not a full HRMS. Gross + OT pay, rate-history aware. No statutory compliance (PF/ESI/TDS). No leave engine. No self-service portal. It's a focused operational tool: know who's working where, for which vendor, what they're owed this month, and whether their WMS access has been cleaned up.
WMS access accountability that can't be skipped
An employee can't be marked Offboarded while they still have any open WMS access — the system blocks it and shows exactly what's pending, on a dedicated Removal Pending dashboard.
Attendance that doesn't lie about history
Eligibility for a given day is computed from actual joining/exit dates, not current status — someone who left mid-month keeps correct, permanent records for the days they worked.
Auto-generated, never-reused employee IDs
IDs like WH-BLR-00001 come from a transaction-safe counter per warehouse — safe under multiple HR users onboarding at once, never recycled even if a record is deleted.
Forms that match your real paperwork
Onboarding and offboarding capture exactly the fields your actual intake forms use — Aadhaar, PAN, LDAP ID, sourcing type, exit reason — not a generic template.
Email routing that matches who actually acts
Onboarding confirmations go to HR; WMS access-request and removal emails go to Ops — the team that flips access in the real WMS. Configurable from Settings, no code changes.
Analytics that answer real questions
Month-on-month attendance trend, headcount by warehouse, and a WMS access funnel showing exactly where requests stall — required → requested → granted → removed.
Payroll that respects rate history
Gross pay from attendance-weighted payable days, OT at 2× the hourly rate unless a vendor-specific OT rate is set — and a past month re-run after a later rate revision still uses the rate that was effective then.
Cheap to run, cheap to change
No SaaS fees, no vendor lock-in — plain Django + Postgres, self-hosted, all logic in one readable codebase an ordinary web developer can modify.
Hard guarantees
What the system enforces, not just suggests
These aren't process reminders — they're rules the application itself won't let anyone break.
What actually changes
Where this moves your numbers
Not features for the sake of features — here's exactly what each one fixes for an HR/Ops team running off-roll warehouse workers.
The system physically blocks offboarding while any WMS access is still open — enforced, not a checklist.
Instead of: An offboarded worker still has live WMS access weeks after their last day.
Gross + OT pay computed automatically from actual attendance and the rate on file that month.
Instead of: Payroll is a manual timesheet-to-Excel exercise every month.
Point-in-time-correct pay — a past month re-run after a rate change still uses the rate that was effective then.
Instead of: A rate revision retroactively changes what a past month's payroll 'should have been'.
Vendor-wise headcount and payroll spend, warehouse by warehouse, live.
Instead of: Nobody knows vendor-wise headcount or spend until someone builds a report.
Onboarding and offboarding forms capture exactly the fields your real paperwork uses.
Instead of: Onboarding paperwork gets re-typed into a generic HR form that doesn't match your intake sheet.
Custom email routing — onboarding to HR, access changes to Ops — configurable from Settings, no code changes.
Instead of: Alerts about access removal or attendance issues, if they exist, go to the wrong inbox.
Inside the build
What the HRMS looks like
This is the actual interface layout of the tool — sidebar, navigation, tables, and the WMS access lifecycle all match the real app. Every figure below is synthetic sample data, not a client's real workforce.
Dashboard
Total Employees
90
Active
64
Pending Onboarding
6
Offboarding
9
Offboarded
11
New Joiners This Month
4
Exits This Month
10
| Warehouse | Code | Active |
|---|---|---|
| CWH_Gurgaon | GGN | 20 |
| CWH_Bangalore | BLR | 20 |
| CWH_Bhiwandi | BHW | 24 |
| Metric | Count |
|---|---|
| Applicable employees | 70 |
| Present | 44 |
| Absent | 8 |
| On Leave | 5 |
| Weekly Off | 0 |
WMS Access Removal Pending
8
89
2
19
Deploy it your way
AWS-managed or fully self-hosted
The exact same Django + Postgres codebase runs either way — pick based on your team's constraints, not ours. This is the real stack: plain Django templates, HTMX for the inline attendance grid, no SaaS, no vendor lock-in.
Amazon Web Services
- 1HR/Ops traffic hits an Application Load Balancer over HTTPS.
- 2The ALB routes to Django (Gunicorn) running on ECS Fargate — no servers to patch.
- 3The app reads/writes employee, attendance, and WMS-access records in RDS Postgres.
- 4Aadhaar/PAN/exit documents upload straight to S3 instead of local disk, encrypted with KMS.
- 5Secrets Manager supplies DB and SMTP credentials — nothing in a .env file on a box.
- 6A scheduled ECS task (replacing the cron job) sends the daily removal-pending reminder digest.
- 7CloudWatch collects logs/metrics and alarms if the removal-pending queue spikes. IAM governs least-privilege access throughout.
Docker · Any Server
- 1Nginx terminates traffic and reverse-proxies to Gunicorn (3 workers) serving Django.
- 2Django talks to Postgres 16 directly via psycopg2 — no connection pooler needed at this scale.
- 3Uploaded documents and collected static files are served by Nginx straight from shared Docker volumes.
- 4The whole stack — db, web, nginx — starts with one docker-compose up, on any server you control.
- 5The removal-pending reminder digest runs as a plain Django management command on a cron entry — no Celery, no Redis, nothing extra to operate.
Runs anywhere
Same modular design, different runtime — this app has zero AWS-specific code today (no S3 storage backend, no managed queue). Moving between AWS, GCP, Azure, or a bare server is a settings change, not a rewrite.
How the engagement works
Week by week, start to handover
Week 1
Discovery & scoping
Map your actual onboarding/offboarding paperwork, WMS systems, and warehouse structure.
Week 1-2
Data & pipeline
Model warehouses, vendors, departments, and the WMS access lifecycle to match your reality.
Week 2-3
Build
Onboarding/offboarding forms, the attendance grid, and the Removal Pending dashboard, wired live.
Week 3
UAT & iteration
HR and Ops run real onboarding/offboarding cases through it before go-live.
Week 4
Handover
Training, documentation, and a clean handoff — plus an optional support retainer.
Want the full order-ops picture too? See the Warehouse Ops Control Tower.
Get in touch
Still tracking orders in a spreadsheet?
Let's talk about what a control tower would look like for your operation — built around how your team actually works.
Book a free 15-minute session
No pitch — just 15 minutes to understand what you're trying to solve and whether a build like this actually fits. Share two times that work and I'll confirm one.