Working on the centralized inventory system started with a pretty clear goal: replace disconnected spreadsheets and give teams a shared place to work from. On the surface, the requirements were straightforward, and most of them were already documented by the project manager.

What became more interesting was everything that lived outside those requirements.

Rather than looking to consumer products for inspiration, I paid more attention to internal and operational systems, such as warehouse management tools, ERP-style dashboards, and admin platforms built around tables, statuses, and bulk actions. These systems aren’t especially polished, but they’re designed for accuracy, repetition, and accountability. That felt much closer to the reality of this project than borrowing patterns from more consumer-facing products.

I also spent time thinking about tools like Google Sheets and Airtable, not as things to emulate, but as things to understand. They work well early on, which is why teams rely on them for so long. In this case, the project existed at the point where those tools had stopped being helpful and had started creating friction; duplicate data, broken calculations, and a lack of clarity around ownership.

The most valuable input didn’t come from the documentation, though. It came from sitting with the people who used the system every day.

Warehouse staff, supply team members, and quality control all worked with the same information, but they interacted with it very differently. Watching how they tracked items, handled exceptions, and worked around gaps in the spreadsheets revealed issues that never showed up in written requirements. Small things—like losing context during handoffs or not knowing who was responsible for an item at a given stage—had a real impact on day-to-day work.

This project reinforced how important it is to design internal tools around actual behavior, not just intended workflows. Some of the most important decisions, like emphasizing status visibility or supporting bulk actions, came directly from observing how people worked rather than from initial feature lists.

It also highlighted the limits of relying only on high-level inputs. Project managers bring necessary structure and direction, but internal systems live or die based on how well they support the people closest to the work. Talking to those users early and often made the system stronger and more realistic.

Coming out of this project, I’m more deliberate about how I approach internal tools. I spend more time understanding existing habits, pay closer attention to where people compensate for broken systems, and think carefully about how design choices hold up under repeated daily use. Those considerations have stayed with me well beyond this project.