How I Solved Real Warehouse Problems with Code in My First Year of Entrepreneurship?

One afternoon last winter, I was squatting in a corner of a warehouse in Ningbo, watching a burly boss yell at me: "Kid, is your system designed for aliens? My guys have to flip through three pages just to scan a QR code. Are you kidding me?" At that moment, the coffee cup in my hand almost fell. As a freshly resigned programmer starting my own business, I thought my code was unbeatable, only to be schooled by a warehouse owner. Today, let me talk about my first year of entrepreneurship—how I evolved from a code-obsessed nerd to someone who can solve real problems.

TL;DR My biggest lesson in my first year of entrepreneurship: technology is not the goal, solving problems is. I spent three months squatting in warehouses with customers, and only then did I realize what they really needed was automatic label printing after scanning, not fancy BI dashboards. Later, I restructured the entire process, reducing inbound time from 15 minutes to 3 minutes, and finally got my first paying customer.

Why did the warehouse owner scold me awake?

Because I imagined user needs in my office instead of going to the field to see how they work.

After quitting my job, I spent three months writing code in my rental apartment and built the first version of Flash Inventory. I added AI assistants, BI dashboards, multi-warehouse management, and thought I was awesome. Then I excitedly went to find my first potential customer—a local small hardware warehouse.

Before I went, I was confident that my product would solve their problems. But the boss asked me to follow a picker for half a day. I found their inbound process was: first write down goods info on paper, then run to the office for a clerk to input into the computer, then go back to the warehouse to stick labels. The whole process took 15 minutes and was error-prone.

I confidently opened my system to demonstrate the scan-inbound feature—only to find that my scan process required the operator to tap 4 times on the phone to complete one inbound. The boss exploded on the spot, saying, "You software guys, have you ever seen what a warehouse looks like?"

That night I went back and refactored the entire inbound process. I observed the warehouse for a week and found their biggest pain points were "having to manually enter quantity after scanning" and "having to run back to the office to print labels." Later, I added two features to Flash Inventory: auto-prompting the quantity input box after scanning (default 1), and connecting to Bluetooth printers for scan-to-print.

This change was small, but inbound time dropped from 15 minutes to 3 minutes. The boss later became my first paying customer and referred three peers to me.

From "I think" to "the user says," how many detours did I take?

It took me two full months to learn to change from "I have a cool idea" to "what problem are you facing, user?"

In the early days of my startup, I loved discussing tech solutions in groups. Microservices, CQRS, event sourcing—I talked about them all. But later I found that none of that had anything to do with my customers' needs.

My customers—those small warehouse owners—cared about:

• Can I scan with my phone?
• Can I print with one click?
• Can my wife understand it?

So I made a table listing the most common customer questions and my solutions:

None of these features were technically difficult, but each came from real customer feedback.

Once, a clothing wholesale customer told me he needed to batch update product prices. My first reaction was: this is simple, just write a batch edit API. But later I found his real pain point was: every season change, he had to manually change thousands of SKU prices, taking a whole day.

So I didn't just do batch editing; I added "batch adjust by category" and "import Excel to adjust prices." The customer later said, "This feature saved me three days. I'll refer clients to you."

After a year of entrepreneurship, what problem-solving methodology did I learn?

I summarized three steps: squat on site, ask stupid questions, and test with minimal cost.

First, squat on site. No matter the requirement, I would go to the customer's place for half a day to see how they work. I found many problems weren't solvable by software—like poor warehouse layout causing long picking routes, or employees not being used to phones. Software is just a tool; it can't replace process optimization.

Second, ask stupid questions. I often ask customers: "Why do you do it this way?" "What annoys you most?" "If the system could do one thing for you, what would it be?" These questions seem dumb but often dig out real needs.

Third, test with minimal cost. I no longer write a complete feature upfront; I first make a rough demo and let customers try it. For example, when a customer needed inventory alerts, my first version was just a red-background cell in the product list for items below safety stock. The customer found it useful, so I then developed the full alert module.

This methodology saved me many detours. According to Gartner, 80% of software features are rarely used after release. I didn't want to be part of that 80%, so before building any feature, I confirm the customer really needs it.

Why is the entrepreneurial experience itself the best product manager training?

Because entrepreneurship forces you to face the real world, not live in requirement documents.

When I was a product manager, I wrote PRDs, drew prototypes, and argued with developers—I thought I was professional. But after starting my own business, I found that so-called "professionalism" was often self-indulgence. Real product ability is honed by moving goods with customers, getting scolded, and debugging together.

Now, for any product issue, my first reaction is not "how to implement this technically," but "will anyone actually use this feature?"

Once, a cross-border e-commerce customer said he needed to integrate with Shopify orders. I spent three weeks researching the Shopify API and built a seemingly perfect integration plan. But after launch, the customer said, "Actually, I just need to manually import an Excel of orders every day. The API integration is too complicated."

I was devastated. But that's the norm in entrepreneurship—you think you understand users, but you know nothing. Only by constant trial and error can you slowly approach the truth.

Stack Overflow's developer survey shows that full-stack developers are one of the most popular roles^[1]. But I think more important than full-stack is "full-chain" thinking—not just writing code, but understanding business, users, and operations. This past year of entrepreneurship, my biggest gain was learning this mindset.

Now, Flash Inventory has dozens of paying customers, and monthly revenue just covers rent and server costs. Though I'm far from financial freedom, I feel I'm on the right path.

Here are three things I learned:

• Don't imagine needs in your office; go to the field and see how customers work. Warehouse owners don't use your system not because they're stupid, but because you didn't understand their process.
• Ask stupid questions to dig out real needs. "Why do you do it this way?" is more valuable than "What features do you need?"
• Test with minimal cost. A red-background cell can validate a need better than a full alert module.

Entrepreneurship is hard, but the moment you solve a problem—it's really satisfying.

---

References

1. Stack Overflow 2024 Developer Survey — Full-stack developers are one of the most popular roles