When Scout entered private beta in late 2025, we started hearing a regular question: when are you opening this to everyone? The short answer is that we deliberately chose not to rush. Not because the product was not technically ready, but because opening early would have damaged things that matter more than signup counts.
Signups are not the goal in the early stage
There is a quiet pressure when building a product: more users looks like signal. A climbing account number, a growing waitlist, an early traction story. We do not pretend that these things are irrelevant in the long run. But in the early stage they can easily become a dangerous kind of noise.
Opening wide early would have given us more accounts. But users who arrive through a viral post or a broad launch campaign come with wildly different contexts: different product categories, different order volumes, different operating rhythms. Feedback from 500 users in mixed contexts is harder to synthesize, and it pulls a roadmap toward things no one actually needs deeply.
What we needed was specific, grounded feedback from a small group of people who understood the problem, who used the tool in a real workflow, and who would say plainly when something was wrong. That is very hard to get when you let anyone in.
The right users matter more than more users
Scout is built for a specific problem: Vietnamese sellers who import goods from 1688 and sell on TikTok Shop, Shopee, or Lazada, and who need to filter products by real landed-cost margin instead of importing on gut feeling. That person has to feel this pain every week. If they do not, their feedback does not speak the same language as the problem.
A concrete example: in the early months, we discovered that one feature on the Scout interface was being understood in two completely different ways by people who were actively importing versus people who were still researching the market. If we had both feedback streams mixed together with no way to separate them, we would have fixed the wrong thing. A tight group let us know exactly who was saying what.
The right users also actually use the product. They come back the following week, they use it during a real sourcing run, and when something is friction they say so. That is a much higher-quality signal than several hundred signups who never return after the first session.
A small rollout lets you see problems clearly
Margin Engine v0.2 shipped in early 2026, calculating input landed cost from real exchange rates and freight, then comparing it against expected selling price and platform fees. Batch import came in March, letting users pull multiple SKUs in at once rather than one at a time. Orders beta opened in April to manage purchase orders with suppliers.
Each of those features, if it had launched into a large user base unfamiliar with the workflow, would have generated hundreds of support tickets stacking on top of each other. A small team cannot process that volume and still have time to see the real pattern underneath the questions. In a tight group, we could watch users actually using the product, track where they stopped, and fix it before it became a scaled problem.
One issue that we caught specifically because of the small rollout: the order in which users wanted to see information about a product was the opposite of what we had built. Operators who are actively importing asked about margin first, then demand. We had placed it the other way around. Fixing that with 20 users took an afternoon. Fixing it after opening to 2,000 users would have been a different story.
Deliberate rollout is not secrecy
This is worth being clear about. We are not keeping Scout under wraps to manufacture exclusivity, and we are not holding back out of fear of competition. We talk openly about what we are building, why, and including what is not working yet. This post is part of that.
A narrow rollout is an operational decision: we need time for the product to be reliable enough before it meets users with broader context and higher expectations. Opening too early with a product that still has rough edges is like inviting someone to walk through a house where the walls have not been plastered. If they cannot picture what it will become, they leave with the wrong impression and that is hard to undo.
For people doing real 1688 import operations, we want the first time they use Scout to be good enough that they come back. Not frustrating enough that they conclude the tool cannot do anything useful.
What would trigger a wider opening
We did not mark a calendar date and say that is when we open. The criteria we set are behavioral, not time-based.
When users in the tight group return at least three times in a month without anyone prompting them, the product is solving a real problem. When the issues that surface in a usage session shift from "a basic thing is broken" to "I want to add this or that," the foundation is solid enough. When we can onboard a new user without manually walking them through every step, the product is clear enough to stand on its own.
Until all three of those are true, opening wider just means pushing more people into a system that is not ready to receive them well.
What the beta actually taught us
We learned more from twenty users using the product for real across three months than we expected to learn from opening to a few hundred earlier.
Some specifics. Our earliest users did not call what they do "sourcing." They called it "tim hang" (finding goods) or "tim nguon" (finding a source). That difference is not small because it affects the language of the interface, the onboarding copy, the way we write help text. If we had kept the word "sourcing" because it is the familiar industry term, we would have created a gap from the start with the exact people we are building for.
Another thing: the way real users actually use the filter feature was far from how we assumed they would. They do not filter top-down by score. They start from a product category they already know and narrow from there. We adjusted. That is not something you can catch from analytics alone. It needs real observation.
Bottom line
Opening slower than the original plan is not a sign of trouble. For us it is the result of asking the right questions first: who are the users whose feedback actually has value at this stage, and how many iteration cycles does the product need before it is ready to meet a wider audience. That answer led to a deliberately narrow rollout, and we do not regret it.