Supplier Inventory Management System
/ 3 min read
Updated:Table of Contents
This is the story of my first real data project — born from frustration, built from curiosity.
2020: The Problem
I was an Operations Analyst at a construction manufacturing company. My job? Check vendor quotations, input invoices, track order volumes, manage contracts. All in Excel.
Sounds simple. It wasn’t.
We had 10+ production units, each producing different goods:
| Unit Type | Products |
|---|---|
| Asphalt Plants | Hot mix asphalt |
| Batching Plants | Ready-mix concrete |
| Precast Factories | Concrete beams, pipes, panels |
| Stone Crusher Plants | Gravels |
Each production unit had its own suppliers. Each supplier had contracts. Each contract had orders. Each order had invoices. Everything was connected:
Invoice A → Production Unit B → Contract with Vendor C → Material DMultiply that across 10+ units, dozens of suppliers, hundreds of contracts. Thousands of data points, all related to each other. All in one Excel file.
The workbook had grown into a monster — dozens of sheets, thousands of rows, complex formulas linking everything. Opening it took minutes. Not seconds — minutes.
And then the crashes started.
I’d spend 30 minutes inputting data. Excel would freeze. “Not Responding.” I’d wait. And wait. Then it would close. Everything gone. Start over.
The stress was real. But here’s the thing — no one else seemed to care. This was just “how it was.” The tool was broken, but everyone had accepted it.
I couldn’t.
The Discovery
I started researching. There had to be a better way. Then I found an article about RDBMS — Relational Database Management Systems.
The concept clicked immediately:
- Tables instead of sheets
- Foreign keys instead of VLOOKUP
- Queries instead of complex formulas
- Designed for scale, not just convenience
I chose Microsoft Access — already installed on company computers, familiar environment, gentle learning curve. I designed my first schema with proper relationships between suppliers, contracts, orders, and invoices.
And it worked. No more crashes. No more waiting. Data stayed organized.
But I still had one problem: the users. My colleagues knew Excel, not databases. So I kept Excel as the input interface and wrote VBA macros that pushed data directly into Access.
The users saw Excel. The data lived in a proper database. Best of both worlds.
2024 - 2026: The Rebuild
Years later, I rebuilt this project from scratch with a modern stack:
| Then (2020) | Now |
|---|---|
| MS Access | PostgreSQL 16 |
| Excel VBA | AppSheet (mobile app) |
| Local files | Cloud VPS (DigitalOcean) |
| No visualization | Metabase dashboards |
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐│ AppSheet │────▶│ PostgreSQL │────▶│ Metabase ││ (Mobile Input) │ │ (Database) │ │ (Dashboards) │└─────────────────┘ └─────────────────┘ └─────────────────┘ │ │ │ Warehouse staff Cloud VPS Management enters data stores data sees insightsThis repository is a homage to that 2020 project — same problem, better tools, more experience.
The Lesson
Don’t get me wrong — I love Excel. It’s the backbone of everything.
But Excel is a tool, not a solution. When the data outgrows the tool, you need to make a move.
That 2020 frustration taught me to question the status quo, research before building, meet users where they are, and iterate as you learn. This project — from MS Access hack to PostgreSQL platform — represents my entire journey in data.
Explore the Series
-
Designing the Schema →
Database design decisions and entity relationships -
Building the Interface →
AppSheet mobile app for data entry -
Building the Dashboard →
Metabase analytics for supply chain insights