~18,000+ Lines to Ask One Question

InventStor wasn't just about inventory management. It was about asking: How do we serve people better?

Every line of code was part of that conversation. Every database table, every validation rule, every error message—they were all attempts to answer that question in a language computers could understand but humans could feel.

This is the story of a government inventory management system built during my final internship. But more than that, it's the story of what happens when you stop building features and start building questions.

"~18,000+ lines of code. 98 PHP files. 8-table database. 116 commits. One question: How do we serve people better?"

The Problem Nobody Asked Me to Solve

When I started my internship at the government office, the brief was simple: build an inventory tracking system. Track assets. Monitor stock levels. Generate reports. Standard CRUD operations. Nothing complicated.

But I spent the first week just watching. Watching how staff logged items manually in thick ledgers. Watching how they searched for asset information by flipping through pages. Watching how long it took to prepare a single inventory report for their superiors.

I could have built what they asked for. But I kept thinking: What if we could do better?

The Architecture of Empathy

I designed InventStor around how people actually work, not just how systems theoretically should work.

But the tech stack was just the tool. The real architecture was built around three principles:

1. Anticipate needs before users ask

Instead of just tracking "Item Name" and "Quantity," I built in fields for supplier information, purchase dates, warranty periods, and asset locations. Why? Because I watched staff scramble through physical files trying to answer these questions when their supervisors asked.

The system didn't just store data—it anticipated the questions people would ask three months from now.

2. Fail gracefully and helpfully

Every error message was written in Malay, clear and actionable. Not "Error 404: Resource not found" but "Item tidak dijumpai dalam sistem. Cuba cari dengan nombor aset yang lain." (Item not found in system. Try searching with a different asset number.)

Because errors aren't failures—they're conversations. And conversations should be in a language people actually speak.

3. Respect the person, not just the process

I added a confirmation dialog before any deletion. Not just "Are you sure?" but a message that explained what would happen: "Tindakan ini akan memadamkan rekod inventori secara kekal. Adakah anda pasti?" (This action will permanently delete the inventory record. Are you sure?)

It's a small thing. But it's the difference between treating users like they might make mistakes and treating them like they're collaborators in the system's integrity.

"The best code doesn't just work—it understands."

The Database That Tells a Story

Eight tables. Each one connected, each one purposeful:

Each table was a chapter. Together, they told the story of how things move through a system—and more importantly, how people interact with those things.

What I Learned About Myself

Here's the part nobody tells you about building something real: it changes you.

I started InventStor thinking I was building a system. I finished it realizing I was building a relationship—between technology and the people who depend on it.

I learned that I don't love code for code's sake. I love code because of what it can do for people. I love the moment when someone says, "Oh, this makes my job so much easier."

And that realization—that's what led me to HR. Because I realized my gift isn't just building systems. It's understanding the humans who use them.

The Question Remains

InventStor is complete. 100% done. Ready for deployment. But the question I built it around—How do we serve people better?—that question doesn't end.

It follows me into every project. Every design decision. Every career choice. Including my decision to transition from Computer Science to HR Management.

Because serving people better isn't just about better code. It's about better understanding. Better empathy. Better systems that remember we're human.