What Building My First App Taught Me About Good Software
Building an inventory app to solve a workplace problem showed the value of software that solves practical challenges.
Building an inventory app to solve a workplace problem showed the value of software that solves practical challenges.
I had a job as a produce buyer at a grocery store. I spent my days solving problems, planning purchases around weather patterns and seasonal events, and presenting my decisions in weekly meetings. The analytical side challenged me, the cross-department collaboration kept things interesting, and I genuinely enjoyed the customer interactions on the floor.
But I wanted to support my family more fully. Technology had always interested me—from my first experiences getting online to experimenting with Linux (I also ran it as my primary desktop for several years). I'd tried learning to program several times before, but without a compelling project or immediate need, I'd always bounced off it. The motivation was there, but the driving force wasn't.
Management introduced a new purchasing process that changed everything.
The new purchasing process eliminated the intuitive approach we'd been using for years. Instead of relying on experience and historical context, we now needed to count inventory daily for everything in our department, cross-reference last week's sales data for the corresponding day, factor in current product availability, and calculate precise purchase amounts.
The entire process ran on clipboards and Excel spreadsheets. Every morning meant manually counting hundreds of items, writing numbers on paper, looking up sales figures, and transferring everything into calculations. What should have been strategic buying decisions became hours of data entry and arithmetic.
This wasn't solving problems anymore—this was administrative overhead.
I decided to build a web app using React and Express.js to manage our product catalog and purchasing workflow, paired with a React Native iOS app that could handle inventory counting directly on the floor. The mobile app consumed the API from the web application, allowing me to count inventory digitally and export the data as CSV files.
I created an Excel workbook that imported this data and automated the purchase calculations, including mapping out the sales floor based on incoming products and determining optimal shelf quantities for any given day.
The results were immediate: the time required to count inventory and calculate purchases dropped by 50%. More importantly, I could focus on the strategic aspects of buying instead of manual data processing.
Before starting this project, I'd informed my manager that I was working on a solution to streamline our new process. While he had confidence in me, he was surprised by the scope of what I accomplished. Both he and the store manager were not only impressed but immediately supportive, allowing me to use my phone on the sales floor for inventory counting.
When the regional manager visited and saw the system in action, he was equally impressed and encouraged me to apply for positions at the distribution center. A nearby store learned about my process and asked if I could help streamline their operations as well.
This recognition from store leadership, regional management, and team members across multiple locations was fulfilling, but more importantly, it confirmed something I'd been feeling: I needed to become a software engineer.
I left that job in 2018 and transitioned into software engineering. Nearly seven years later, the excitement I felt building that first inventory solution is still there—I love exploring new technologies, writing software that solves real problems, and I'm genuinely excited about the potential of AI to enhance how we work.
My approach remains the same: I connect technical quality with user needs, using modern development workflows to create maintainable solutions alongside product, design, and business teams. Whether it's a React component library serving enterprise customers or an accessibility improvement that makes software usable for everyone, I'm still solving problems that matter.
The difference is that now, instead of counting produce with a clipboard, I'm building software that improves people's quality of life. And that transformation started with recognizing that if something is tedious and repetitive, there's probably a better way to do it.
I had a real problem that affected my daily work, clear constraints that defined the solution, and immediate feedback on whether my approach was working. Those conditions—necessity, constraints, and rapid iteration—remain my favorite way to learn new technologies.
If you're considering a career transition into software engineering, my advice is simple: find a problem that genuinely bothers you and build something to solve it. The technical skills matter, but the mindset of seeing inefficiency as an opportunity? That's what makes the difference.
Law Horne is a senior software engineer focused on building accessible software that improves quality of life.
Enjoyed this article? I share thoughts on component architecture, and AI-enhanced workflows, regularly.