Japan Goods Decision Chain

When I buy second-hand goods in Japan to resell, the awkward part is neither buying nor selling. It is the thirty seconds in between: a camera is sitting in a shop with a ¥12,000 price tag, and I have to decide there and then whether to buy it.

What that decision requires is very concrete—which prices this model has recently sold for, whether the description says it works properly, whether I have bought one before, and what that previous unit eventually sold for. All of that information existed. It was simply scattered across three places.

The three tools were not built together, or even for the same purpose. Only long after they were finished did I notice that their ends met perfectly to form a complete chain.

Each one worked on its own. Together, they produced three disjointed actions.

If I saw a price on Yahoo!, I had to open a second tool to find out what I could pay for that model. Once I brought the item home, I opened a third to enter the transaction. To answer “have I bought this camera before, and what did the last one sell for?”, I had to move back and forth across all three interfaces. The same object had one incomplete record in each place, and none knew the others existed.

Standing in a shop, that back-and-forth was the part that mattered most.

In August 2026, I brought the three tools into one panel.

The interfaces were combined; the data was not. All three datasets remain where they have always lived, and the panel reads them together. Nothing is copied and nothing is synchronised, so there is no question of which copy to trust when two versions disagree.

Every product sits on one page. A control at the top switches between radar products and self-created products, with a category filter beside it.

Radar products are the models being watched. Each row ends with a price band: the solid segment is the 25th-to-75th-percentile range of completed prices, the centre tick is the median, and the dashed ends are the distribution tails calculated on the spot. The interface explicitly notes that the tails and the solid band use different measures. The whole table shares a logarithmic scale, so it is immediately clear which models are expensive and which have a wide spread.

Maturity has three levels, with the test written directly on the page. “Baseline ready” means a price band within twofold and at least thirty observations. “Limited sample” uses the same twofold band but only fifteen to twenty-nine observations. “High dispersion” means a band wider than twofold or too little data.

Self-created products are items I add myself. They are unrelated to the radar and have no market baseline, so the same column instead shows purchase price, sale price and gross profit. They can be filtered by held / sold and sorted by profit.

Opening a radar product first shows the model record: model number, brand, category, search terms for both Yahoo! and Xianyu, and inspection points. Beneath it, the reference purchase range uses the 25th and 75th percentiles from the current baseline and states the date through which the data runs.

Market data stays behind a button until it is needed. Expanded, it shows four condition-specific baselines—all listings, confirmed working, unspecified, and explicitly faulty—each with its own price band and sample count. A group without enough observations says “insufficient sample” instead of forcing a number. Below that come historical baselines, inspection points, recent completed listings, matching live listings and the low-price alerts that have fired.

A radar product is a model; a self-created product is one specific physical object. Photographs and sales copy in three languages belong to the object, not the model. That is why opening a model I have never bought plainly says that a purchase must be recorded before anything can be uploaded.

The object record can be edited directly: name, code, category and notes. Its reference purchase price is one number I enter myself, used only as a guide for the next purchase. A product with transactions cannot be deleted; it can only be archived.

Physical photographs can be selected from disk or dragged straight in. Chinese, Japanese and English sales materials are written independently and submitted together. The panel explicitly says that it performs no automatic translation. Sales concept images are stored separately from documentary product photographs for use on sales pages.

At the bottom are every transaction attached to this object, followed by “record another”. If the same product is bought and sold several times, each cycle remains a separate transaction under that item.

Each transaction covers the whole journey from opening a record to closing it. Four figures at the top show how many units are still held, how much money they tie up, how many have sold and the total profit.

A held transaction can be closed with “enter sale result”. A sold transaction can be “edited and recalculated”. Changing a closed transaction alters historical statistics, so it follows a separate route and the interface gives an explicit warning.

Only completed transactions are counted. Anything still held and unsold enters neither a number nor a chart. That sentence appears at the very top of the page.

The six figures are cumulative completions, in progress, purchase cost, actual proceeds, profit and overall profit margin. The profit trend follows below.

Category profit uses the category snapshot taken at the moment of sale, not the product’s current category. Moving a product later does not rewrite history; the completed transaction remains under its original category name. Channel share is counted by completed transactions and includes disabled channels, so disabling one does not alter historical analysis.

Categories and channels are managed separately. One distinction is easy to miss: the product categories in Sales Records and the category of a radar SKU are two different systems. They are not edited in the same place and do not affect each other. A category showing zero products means only that no physical item is attached to it yet; it says nothing about how many SKUs exist on the radar side. That explanation is written directly on the page.

A channel can be disabled but not deleted. Historical transactions point to it, and deleting it would break the chain of analysis.

Shops are grouped by route: route one, route two and ad hoc. Each has an address, one field note—which shop carries plenty of cameras and lenses, which often has a cheap junk sale at the entrance, which is expensive for games—and links to Apple Maps and Google Maps. On a shop day, I can open directions straight from my phone.

The panel runs on the Mac mini at home and reaches the outside world through Cloudflare Tunnel. In a shop I open a public domain on my phone, but the request ultimately lands on that machine at home.

All three datasets remain in local SQLite databases, and the panel has copied none of them. The Sales Records database is a purely local personal tool and never had authentication. Every read and write from the panel therefore passes through its backend, and that port never leaves localhost.

I wrote the gate myself: enter a passphrase once and a Cookie lasts for six months. An off-the-shelf enterprise login would be more orthodox, but every expiry means waiting for an email verification code. Standing in a shop with a camera in my hands and a member of staff watching, I cannot spare that half-minute.

The frontend has no framework, CDN or web fonts. All data is delivered once, then filtered locally. On an unreliable shop connection, that choice matters more than any optimisation.