What 15 Users (and Only 4 Paying) Taught Me About BizTrack-OS In One Month
Most people who try the thing don't stick around. That's not a confession, it's just the honest starting point for everything I actually learned this month.
- Pain Point 1 ("It's hard to find products in a 500+ item catalogue"): One user runs a business with hundreds of stock keeping units (SKUs). Every time they needed to log a sale, they were scrolling through an unsorted list trying to spot one product among hundreds. They called it tiring, and they were right to. This is the kind of problem you only catch by watching someone actually use your product, not by imagining how they'll use it. I hadn't designed for catalogue size at all — I'd designed for the businesses I knew, which were smaller. This user expanded what "BizTrack-OS user" even meant to me.
- Pain Point 2 ("Staff shouldn't be able to delete sales without my permission"): A different kind of problem — not a feature gap, a trust gap. This business owner wasn't worried about using the app incorrectly. They were worried about losing control of their own sales history to staff who had access but not ownership. That's not a UI request; it's a request for the app to understand who's actually in charge. This was the interpretation I gave to the concern. It made me realise I'd been thinking about "users" as a single role, when in reality there's the business owner, and there's everyone the owner trusts with day-to-day operations — and those two groups need different levels of permission.
- Pain Point 3 ("I need supplier names attached to my inventory"): A simpler ask, but a real one. For some businesses, knowing where a product came from matters as much as knowing what it is — especially when something needs to be returned, reordered, or questioned for quality. I'd built inventory tracking around the product. I hadn't built it around the relationship behind the product. And supplier relationships matter a lot for SMEs.
- Pain Point 4 ("I can't see what a debtor actually bought"): This one stuck with me. A business owner extending credit to a customer needs to be able to show, clearly and without argument, exactly what was purchased and what's still owed. Without that breakdown, every conversation about an unpaid balance becomes a he-said-she-said. The feature request wasn't really about data — it was about avoiding awkward, trust-eroding conversations with customers.
- Pain Point 5 ("I need expiry alerts on perishable products"): For businesses selling anything with a shelf life, losing track of expiry dates is losing money, full stop. This user needed the system to remember what they couldn't possibly track manually across hundreds of products. It's a small feature with an outsized impact on actual business loss prevention, compliance and of course, consumer safety.
- Your first users are a research tool, not a vanity metric: 15 signups and 4 conversions look small on paper. But each of those 15 people handed me a blind spot I couldn't have found alone — staff permissions, supplier tracking, debtor breakdowns, expiry alerts, catalogue search. No amount of solo planning gets you there. If you're sitting on an MVP with a handful of users, the number itself matters less than whether you're actually listening to what those few people are bumping into.
- Low conversion isn't always a "you" problem: It's tempting to read 4-out-of-15 as a verdict on the product. Sometimes it's a verdict on trust, timing, or how much friction there is in someone handing their business data to a stranger's app. Before you panic-rebuild the product, ask whether the issue is what you built or how much runway people need before they're ready to commit to it. For me, that meant extending the trial — a pricing and timing change, not a complete product rewrite.
- Pain beats feature requests: Don't just collect what people ask for — understand why they're asking. "Add supplier names" is a feature request. "I need to know where this came from when something goes wrong" is the actual pain underneath it. Build for the second one, and you'll often solve problems the user didn't even think to ask about.
- Ship the fix while the pain is still fresh: Every pain point in this post got addressed close to when it was raised, not batched into some future roadmap I may never touch as the user abandoned the app. That responsiveness is the actual unfair advantage of being small — you can close the loop in days, not quarters. Use it.



