skip to content
fakhrimhd
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 TypeProducts
Asphalt PlantsHot mix asphalt
Batching PlantsReady-mix concrete
Precast FactoriesConcrete beams, pipes, panels
Stone Crusher PlantsGravels

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 D

Multiply 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 AccessPostgreSQL 16
Excel VBAAppSheet (mobile app)
Local filesCloud VPS (DigitalOcean)
No visualizationMetabase dashboards
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ AppSheet │────▶│ PostgreSQL │────▶│ Metabase │
│ (Mobile Input) │ │ (Database) │ │ (Dashboards) │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
Warehouse staff Cloud VPS Management
enters data stores data sees insights

This 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

  1. Designing the Schema →
    Database design decisions and entity relationships

  2. Building the Interface →
    AppSheet mobile app for data entry

  3. Building the Dashboard →
    Metabase analytics for supply chain insights


Lorem ipsum dolor sit amet, consectetur adipiscing elit.
00K00KMIT

Live Demo (AppSheet) · Dashboard (Metabase)