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

Last winter, I was squatting in my rented apartment staring at the screen—my project had been live for three days, and the number of users was zero. I had followed the textbook: multi-tenant architecture, RBAC permissions, microservices—I thought it was perfect. Until a friend who runs a warehouse came over, glanced at my demo, and yelled, 'Your thing is worse than my Excel.' That moment I realized I had been writing code but never really solving problems.

TL;DR: In my first year of entrepreneurship, the biggest lesson was: technology is not the goal, solving problems is. From being yelled at by a user to building the first paying feature, I learned to ask 'what do users really want' before writing code. Today I share three real cases, the pits I fell into and the takeaways.

Why did my first version fail?

Because I was building for myself, not solving problems.

I spent three months on the first version of Flash Inventory. The feature list was long: purchase orders, sales orders, inventory count, multi-warehouse, permission management... I even built a fancy 3D warehouse map with Three.js, thinking users would be amazed.

Then my warehouse owner friend, Lao Zhang, said, 'All these features, I can do with Excel. What I need is barcode scanning for receiving—one second to finish. Can you do that?'

I was stunned. Barcode scanning? It sounded so simple, but my system didn't have it. I had been chasing technical 'coolness' while forgetting the real pain points.

Later I did a small survey with 10 warehouse owners. Their biggest headache was receiving goods—manually counting boxes, typing into the system, slow and error-prone. My system didn't even have that basic feature.

How did a simple feature get me my first paying customer?

The answer: replace keyboard with phone camera.

After being yelled at, I spent a week building a barcode scanning feature using uni-app. The principle was simple: use the phone camera to scan a barcode, auto-match the product in the system, default quantity 1, tap 'confirm' to receive. The whole process took less than 3 seconds.

I packed this feature into a demo and gave it to Lao Zhang. After trying it, he directly transferred me 500 RMB: 'This feature is worth it. Install it for me now.'

That was my first income since starting my business. Not because my technology was amazing, but because I solved a specific pain point. According to IDC, the digital penetration rate for SMEs is expected to reach 45% in 2025^[1], but many small businesses don't need big systems—they need tools that solve one or two core pains.

From 'I want to build' to 'users want me to build'—what did I go through?

I learned to replace 'I think' with 'users say'.

With my first paying customer, I changed my development process. Before, I would think of features and then code. Now, I ask users first, then decide what to build.

For example, once Lao Zhang said, 'Your inventory count feature—can it automatically generate a difference report?' I was planning a complex visualization, but Lao Zhang said, 'I don't want charts. I just need a table showing what's missing and how many.'

So I spent three days building a simple comparison table, highlighting differences in red. Lao Zhang said, 'That's enough.'

Later I tracked usage: in the first six months, the features with over 80% user adoption were the 'small' ones—barcode scanning, difference reports, stock alerts. The 'big' features I spent a lot of time on—like the 3D warehouse map and AI sales prediction—had less than 10% usage.

This reminded me of a data point from Stack Overflow's 2024 Developer Survey: full-stack developer is the most popular role^[2], but many developers, like me, fall into tech self-indulgence. The code that creates value is the code that solves real problems.

After a year of entrepreneurship, how do I view 'solving problems'?

Solving problems is not a one-time thing; it's a continuous conversation.

Now, my Flash Inventory has over 50 paying users and is still growing. But I keep a habit: talk to at least three users every week, ask what troubles they've encountered recently.

Once, a cross-border e-commerce user said he needed to manage both domestic and overseas warehouses, but the system didn't support multi-currency settlement. I spent two weekends adding multi-currency support with real-time exchange rates. This feature later became a key differentiator for my product.

Gartner predicts the global SaaS market will exceed $300 billion in 2025, but competition is fierce. As an indie developer, I don't have big company resources, but I have an advantage: I can get closer to users and respond faster.> Let me recap three things I've learned:

• Ask about user pain points before coding; don't build for yourself
• Small features solve big problems; better than big features nobody uses
• Keep talking; products grow, not get designed

If you're an indie developer or entrepreneur, feel free to visit my blog. Email: [email protected]

---

References

1. IDC SME Digital Transformation Report — IDC predicts SME digital penetration to reach 45% by 2025
2. Stack Overflow 2024 Developer Survey — Full-stack developer is one of the most popular roles