When we were building Scout, one question took us a while to settle: where exactly should real landed cost appear in the user's workflow? The answer sounds obvious in hindsight, but it led to a deliberate design call worth explaining.
The actual problem sellers run into
A shop owner browsing 1688 for products usually follows a familiar sequence: scan several dozen items, click through the ones that look promising, then sit down to figure out what importing any of them would actually cost.
The problem is that the cost calculation happens after the filtering step. By then they have already spent time getting interested in a product, already played out the sales scenario in their head, sometimes already messaged a supplier. Then they work through the math. And often the numbers do not hold up, but because they have already invested attention in the product, there is a pull toward finding reasons to justify it anyway.
This is why experienced sellers say bad products are not picked wrong so much as calculated wrong, or calculated too late.
The 1688 price is just the starting point
The listed price on 1688 is not landed cost. It is the factory price before any of the costs that get the goods to a warehouse in Vietnam.
Real per-unit cost includes several layers. Domestic China shipping from the factory to the consolidation warehouse. International freight to Vietnam, charged by actual weight or volumetric weight, whichever is higher. Import duty and customs handling fees, which depend on the product category. The order-agent service fee if you are not buying direct, typically a few percent of the order value. Expected shrinkage from defects or transit loss. And the currency conversion, since everything on 1688 is priced in yuan.
Each of these is not huge on its own. Together they can push the real landed cost 30 to 50 percent above what the 1688 product page shows. Light, compact items land at the lower end. Bulky goods or formally cleared shipments can push higher.
Why filter on landed cost, not 1688 price
When someone filters products by 1688 price, they are comparing numbers that say nothing about actual margin.
A product listed at 15 yuan, shipped by sea to Vietnam, can land at a real cost of around VND 100,000 to 120,000 per unit depending on weight and product category (check the current rate; around VND 3,600 per yuan is a recent reference point, but it moves). A product at 18 yuan that is light and goes by express air might land noticeably cheaper. The 1688 price alone does not reveal this.
If a tool only shows the 1688 price and leaves fee stacking as manual work for later, those two products look almost identical during filtering. Their real margins are not.
Scout computes an estimated landed cost right inside the filtering step. Not to replace the precise calculation before each actual purchase order, since real costs shift with volume, route, and timing. The purpose is to let users eliminate SKUs with no viable margin before they spend more time on research.
The design call: do not let users calculate after the fact
When we built the filter, two approaches were on the table.
Option one: show raw product data, let users calculate landed cost in a separate tool. Many product-aggregation sites work this way. Filter, export a list, open a spreadsheet, fill it in.
Option two: compute estimated landed cost inside the filter interface, attached to each product, so users see projected margin before they ever click into a listing.
We went with the second. Not because it was technically harder (it was not trivial, but that was not the deciding reason). The reason was that the data a user needs to make a good decision has to be present at the moment they are making it. If the number only appears after they have filtered, browsed, and developed an opinion, it arrives too late.
What Scout can estimate versus what users must confirm
We are not pretending the Scout estimate is precise. It is not.
What Scout can estimate: freight on a standard route based on declared weight and dimensions, customs duty by product HS category, order-agent fee at a typical rate, and currency conversion at a frequently updated reference rate (around VND 3,600 per yuan at time of writing, but verify this when you calculate).
What users need to confirm themselves: the actual rate from the specific freight forwarder they use, the order quantity (since tiered pricing changes the unit cost), and any category-specific costs like safety certification, Vietnamese labeling, or cargo insurance.
The estimate inside the filter is there to cut items with clearly unworkable margins. It is not there to replace the careful math before a large purchase order.
Margin Engine v0.2: tightening the estimate
In February 2026, we shipped Margin Engine v0.2 for Scout, updating several parts of the cost estimation.
We added a shipping-route selector (sea freight versus express air), because the same product on two different routes can land at meaningfully different costs. Sea freight from China typically runs around 18 to 30 days, with lower per-unit freight but a longer cash cycle. Express air is 3 to 7 days but far more expensive per kilogram, only sensible for small, light, high-value goods.
We improved how volumetric weight is handled. Bulky, light goods are often charged by volume (a common formula: length x width x height in cm, divided by 6,000, giving kilograms), and many sellers miss this entirely, which throws their landed cost off by a meaningful amount on certain categories.
We also added a field for expected defect rate. This is a real cost that tends to be ignored. If 3 percent of units arrive unusable, that is 3 units of cost per 100 that never generate revenue.
What we observed in beta users
During the Scout beta that started in 2025, we noticed a consistent behavior: users were not opening Scout to discover new products. They were using it to quickly eliminate products they were already considering.
The actual pattern looked like this: they would come in with 5 to 10 SKUs from other sources (TikTok, Shopee, word of mouth), put them into Scout to see estimated landed cost and projected margin side by side, and immediately drop the ones that did not clear a threshold. Only the survivors went into detailed research and supplier conversations.
This confirmed the original hypothesis: the tool is most useful when it helps people discard quickly, not when it steers them toward a choice.
Where this goes next
We are working toward Scout pulling real cost data from orders that have actually run through Orders (the purchase-order module, in beta since April 2026), so that the estimated landed cost gets calibrated against each user's own actual numbers rather than a shared category default.
Once a user has run 20 to 30 orders through the same route and product category, that data is an asset. It allows the next estimate to be considerably more accurate than a general reference figure. This is the direction we want to move in through the rest of 2026.
Bottom line
Putting landed cost into the filtering step is not a secondary feature. It is the reason the filter is worth using. A product list without margin estimates is a list where users still have to do the most important part themselves. We want that part done inside the tool, at the moment the decision is forming, not after the choice has already been made.