INVENTRACK : Smart Inventory Management System
Hello everyone! Welcome back to Mayur's Tech Journey. 🚀
There is a specific kind of satisfaction that comes not from building something big, but from building something correct. Something where you did not just make it work, but you actually thought about why it should work that way, and then designed it accordingly.
This blog is about that feeling. This is the story of Inventrack — my latest project, and honestly, the one I am most technically proud of so far.
But before I tell you what Inventrack does, let me tell you why it exists. Because the "why" here is the whole point.
🏪 A Real Problem That Nobody Talks About
Think about a medical shop. Or a grocery store. Or a warehouse. Every day, they are receiving new stock of the same products. Same medicine, new batch. Same biscuit packet, new expiry date. Items piling up from multiple purchase orders, each with a different expiry date, all sitting together on the same shelf.
Now when a customer comes in and asks for one unit — which batch do you sell from?
If you sell from the newest batch, the older stock keeps sitting there. Days pass. Weeks pass. And one morning you check the shelf and half your inventory has expired. That is financial loss. That is waste. In pharma, that is also a safety issue.
The correct answer is always: sell the batch that expires soonest first. This is a globally recognised supply chain principle called FEFO — First Expired, First Out.
The problem is, doing this manually across hundreds of products and dozens of batches is impossible without a system. So I built one.
🎓 Where This Idea Came From
We had just finished a chapter on Data Structures in our Engineering curriculum. Heaps. Priority Queues. Trees. The usual theoretical introduction that most students study for the exam and then put away.
But something about the Min-Heap stayed with me. A Min-Heap is a data structure where the smallest element always sits at the top, and every insertion or removal is done in O(log n) time. Fast, efficient, always giving you the minimum value instantly.
And I remember sitting with that concept and thinking: if I always want the earliest expiry date, that is exactly the minimum value I need. That is a Min-Heap problem.
That connection between a classroom concept and a real-world inventory problem was the spark. The rest was just building.
⚙️ What Inventrack Actually Does
Inventrack is a full-stack, multi-user inventory management web application built with Python Flask and SQLite. It is live at inventrack.pythonanywhere.com — you can visit it right now, register an account, add some batches, and watch the system work.
Here is what the system handles end to end:
✅ User Registration with OTP Verification — when you register, a one-time password is sent to your email. Your account does not activate until you verify it. No throwaway registrations.
✅ Batch-Level Inventory Tracking — stock is not just tracked by product name. Every batch has its own batch number, quantity, and expiry date. This is how real inventory works.
✅ FEFO Sell Algorithm — when you sell a product, Inventrack automatically finds the batch that expires soonest and deducts from that first. If that batch runs out, it moves to the next one. This happens automatically, with no manual input needed from the user.
✅ Expired Batch Auto-Removal — if a batch has expired, the system detects it during the sell flow and removes it automatically. You never accidentally sell expired stock.
✅ Expiry Alerts Dashboard — the dashboard shows you which items are expiring within 30 days (caution) and which are expiring within 10 days (critical), with colour-coded warnings so nothing sneaks past you.
✅ Complete Multi-User Isolation — every user has their own private inventory. Your data is yours alone. No information from one account bleeds into another.
🧠 The Part I Am Most Proud Of: The Min-Heap Engine
Every project teaches you something. Inventrack taught me that a data structure is not just a topic in a textbook. It is a tool. And when you use the right tool for the right problem, the elegance of the solution becomes visible.
Let me explain what is happening inside Inventrack at the technical level.
When a user logs in, their entire inventory is loaded into an in-memory Min-Heap — a private one, stored in server memory just for that user. Every element in the heap is a tuple containing the expiry date, the item ID, the product name, the batch number, and the quantity.
Python's heapq module always keeps the smallest element at position zero. Since expiry dates are stored as YYYY-MM-DD strings, the smallest date is always the one expiring soonest. So at any point, the top of the heap is the most urgent batch in the user's entire inventory.
When a sell request comes in, the system does not run a database query and sort results. It goes directly to the heap. It finds the nearest-expiry batch for that product in O(k) time — where k is just the number of batches for that specific product, not the entire inventory. It checks if that batch is expired, skips it if yes, deducts from it if no, and cascades to the next batch automatically if the quantity is not enough. The database is only written to when the deduction is confirmed.
This means zero redundant database reads during the sell flow. The heap does the heavy lifting in memory. The database is the source of truth, and the heap is the speed layer on top of it.
Here is the actual FEFO flow in plain language:
Sell 10 units of PARACETAMOL
→ Heap finds Batch A (expiry: 2025-03-01, qty: 4) — earliest
→ Check: is it expired? No.
→ Deduct 4 units. Remaining needed: 6.
→ Batch A now empty. Remove from DB. Reload heap.
→ Heap finds Batch B (expiry: 2025-06-15, qty: 9) — next earliest
→ Deduct 6 units. Remaining needed: 0.
→ Done. Batch B now has 3 units left. DB updated.
This all happens in the background. The user just types "sell 10 units of PARACETAMOL" and it works. But underneath, that Min-Heap is doing exactly the right thing, exactly the right way.
I had studied this in class. But writing it myself, seeing it run, and understanding why it is faster than a naive database sort — that is what moved it from a concept I had studied to a tool I now actually know.
🔐 Authentication That Actually Works Properly
One of the things I focused on in Inventrack that I had not fully implemented before was a proper OTP-based registration flow.
The flow works like this. A user fills in their name, email, and mobile number and submits the registration form. A one-time password is generated and sent to their email address via SMTP. The user is taken to a verification page. Only after they enter the correct OTP does the account get created in the database.
This means unverified users never sit in the database. The system is clean. No ghost accounts. No placeholder rows waiting to be confirmed that never get cleared. The database only contains real, verified users.
I also made sure that every response in the application includes Cache-Control headers that prevent stale page caching. This is something I learned the hard way on ScholarDesk — if you do not set these headers, a user can log out and then press the browser back button to return to a protected page. The cache serves the old page without checking authentication. With the headers set correctly, the browser is forced to fetch a fresh response every time, and the session check runs properly.
Small detail. But the kind of detail that separates a working prototype from an application that behaves correctly in the real world.
🏗️ How the Project Is Structured
Inventrack is built in a fully modular way. Each file has one job and does only that job.
app.py handles all the Flask routes. It is the entry point and the coordinator. It receives requests, calls the right functions, and returns the right responses.
auth.py handles everything related to user authentication — login logic, OTP generation, and the email delivery of that OTP.
inventory_management.py contains the core business logic — add a batch, sell a product, query all inventory, get expiring stock.
heap.py is the Min-Heap engine. It maintains a per-user dictionary of heaps in server memory, provides functions to push batches, get the nearest expiry, and reload from the database when the heap needs to be refreshed.
database_setup.py initialises the SQLite schema on first run. Tables are created if they do not exist, so the app is self-contained from the moment you run it.
sms.py handles the email alert utilities — OTP delivery and the welcome notification sent after successful registration.
The templates folder contains all the Jinja2 HTML files — landing page, login, register, OTP verification, dashboard, add batch, sell product, and error pages.
This structure is something I genuinely thought about before writing a single line of code. Clean separation of concerns means that if I want to improve the sell algorithm, I touch only inventory_management.py and heap.py. If I want to change how OTP emails look, I touch only sms.py. Nothing breaks anything else.
🚀 Deployment: The Third Time Gets Easier
Inventrack is live on PythonAnywhere at inventrack.pythonanywhere.com.
This is now my third deployed Flask application — after Students-ToolKit and ScholarDesk. And I can tell you honestly, deployment gets less frightening every time you do it.
The first time I deployed ScholarDesk, everything was new. WSGI configuration, virtual environments on a remote server, file paths that work differently in production, environment variables for API keys and email credentials. Every error during that deployment felt like a wall.
By the time I deployed Inventrack, those walls had become steps. I knew what the WSGI file needed to say. I knew which dependencies to install in which order. I knew to check file permissions and to verify environment variable loading before testing any feature. The process that once took hours of confused troubleshooting was now something I moved through with purpose.
That is what repetition does. Not just in coding — in everything.
📊 The Database Behind It All
Inventrack uses two SQLite tables.
The user table stores the account information — email as the unique identifier, name, password, and mobile number. Email is used as the foreign key in the inventory table so that every batch of stock is linked to the user who added it.
The inventory table stores every batch — the product name (always stored in uppercase for consistency), the batch number (unique across the entire system), the quantity, the expiry date in YYYY-MM-DD format, and the user_email foreign key.
Every time the heap is reloaded after a sell or add operation, it reads fresh from this table. The heap is the speed layer. The database is always the source of truth.
🔮 What Comes Next for Inventrack
Inventrack works. It is deployed. It solves the real problem it was designed to solve. But there are things I already know I want to improve when time allows.
Password hashing is the most important one. Right now passwords are stored in plain text in the database, which is not acceptable for a production application. Integrating bcrypt or werkzeug.security to hash passwords before storage is on the list.
Low stock alerts would make the system genuinely useful for a business — if a product's total quantity across all batches falls below a set threshold, the user should receive a notification.
A CSV export feature so users can download their current inventory as a spreadsheet for record keeping.
And eventually, a proper REST API layer so that the inventory data can be consumed by a mobile app or third-party integration.
These are not just feature ideas. They are the next chapter of learning.
🪞 What This Project Did for Me
I want to say something here that I think is worth hearing if you are a student reading this.
Every project I have built has taught me something specific. The calculator taught me how logic flows in a UI. ScholarDesk taught me full-stack architecture and collaborative development. The hackathon taught me how to build under pressure.
Inventrack taught me something different. It taught me that the gap between a classroom concept and a real-world application is smaller than you think. A Min-Heap is not just an exam question. It is the engine of a real inventory system that a pharmacy could use today.
When you build something that takes a concept from a lecture and turns it into a working feature that solves a real problem, the concept never leaves you. I will never forget how a Min-Heap works. Not because I studied it. Because I used it.
That is the kind of learning that lasts.
Gallery :
 |
| Dashboard |
 |
| Landing Page |
 |
| Add Batch |
 |
| Sell Product |
🔗 Also Read
📖 Scholar Desk : The Ego Issue
📖 Fueling the Code: New Milestones and the Power of Pride
📖 My Journey of Building a Functional Calculator
"The concepts you build with never leave you. The ones you only study for exams always do."
Signing off,
Mayur B. Gund
SY B.Tech CSE | Sanjivani College of Engineering
Comments
Post a Comment