Before you pay anyone to migrate your Shopify catalog, make them promise these 17 things — in writing

junlong zhu — Sun, 16 Aug 2026 00:21:22 +0000

I audit catalog migrations for a living. Every disaster I've seen was preventable — not by hiring better, but by agreeing in writing what "done" means before work starts.

Copy this list. Send it to whoever is doing your migration. Ask them to commit to each line — and note the italics: every promise comes with a way you can check it yourself in about two minutes, no tools, no trust required.

Every product made it across — none lost, none duplicated. Compare row counts in both files.
Every variant made it across. Pick any product, count its rows in both files.
No handle silently renamed (-1, -2 suffixes). Search the new file for -1, -2.
SKUs unchanged and unique. Pick 5 SKUs from your export, find them in the new file.
Prices and compare-at prices identical. Pick any product, compare both price fields.
Inventory identical. Same spot-check.
No missing titles, vendors, types, or prices. Sort each column, look for blanks at the top.
Images attached to the right variant, not dumped at product level. Open a product with colors; each color shows its own image.
Every image link loads. Click any 5 image URLs.
Collections intact. Pick a collection, compare its product count.
Custom fields (metafields) survived. Open a product that had them.
Every old URL redirects. Try 5 URLs from your old sitemap.
No garbled characters. Search the file for â€.
No description empty or cut short. Read 5 descriptions in both files.
Description formatting survived (bullets, tables). Same 5 products.
Option names still meaningful ("Size", not "Option1"). Open any product with options.
Option values mean what they meant. Compare the value lists.

Two more things worth writing down:

What happens if a check fails — fix at no charge? partial refund? Agree now, not later.
Anything already broken in your source data — list it upfront so nobody argues about whose fault it was.

If your provider hesitates to commit to a list like this, that hesitation is information.

(I keep a pre-filled version of this as a one-page agreement — if you want it for your project, ask.)

I scanned my own 30 days of Claude Code logs. Here's what I found (and the tool I built to do it)

junlong zhu — Tue, 11 Aug 2026 18:15:31 +0000

I've been living inside Claude Code for the last month — 245 sessions, two agents running most days. And I had this nagging feeling: my setup was slowly getting worse, and I had no real idea what I was spending. The dashboard tells you some things, but not the ones that actually cost you.

So I spent an hour writing a small tool that reads the session logs Claude Code already writes to your disk (~/.claude/projects/*.jsonl) and just tells me the truth. No account, no upload — the whole point is that nothing leaves the machine.

Here's what it found on my own setup. I doubt I'm special.

~$3,600/mo equivalent — and half of it was waste I'm on a subscription, so that's not my bill — it's what the same usage would cost at API list prices. The number itself wasn't the shock. The breakdown was:

~$1,745 in context bloat. Long sessions dragging a huge context every single turn, when a fresh session or a /compact would've done the same work for a fraction of the tokens.
~$217 in tier mismatch — heavy model doing trivial tool-call turns.
~$38 in retry storms — one request hitting gateway errors and retrying itself into a hole.
Context bloat is the sneaky one. There's no line item for it anywhere, so nobody looks at it — and it's probably the single most common way people burn tokens without noticing.

Four things quietly broken in my environment
A 401 auth loop that burns through all its retries. An MCP server whose health check had been silently failing for days. Small stuff that just wastes time and tokens in the background, and that you never go looking for because nothing crashes hard enough to make you.
Two of my own API keys, sitting in plaintext
One in a shell rc file (world-readable), one in a project .env. Rotating them, I found a background service still using the old key — the kind of dependency you only catch when something actively goes looking. Secrets get masked in the output, obviously — first six chars and length only.

Why local-only, and why I'm sharing it
The people who'd use this just lived through a wave of malicious-skill and supply-chain incidents. Trust is the whole game. So the design constraint is hard: the advisory format has no free-text field — there is structurally nothing to exfiltrate. The only thing that ever touches the network is an explicit sync command you run yourself.

It's open source, zero dependencies, MIT. One line:It runs three "mirrors" — cost/waste, environment health, and a security audit of what you've granted your agent — and prints a local report. There's a --html flag if you want a shareable card, and a dashboard command that opens all of it as one local page.

I'm building it into something bigger (a shared failure-signal network, so your agent gets warned before it hits a wall someone else already hit), but the local tool stands on its own and is what I'd genuinely want feedback on.

What's your number? I'd bet most people carrying long sessions are sitting on more context bloat than they'd guess. Run it and tell me I'm wrong.

Repo: github.com/jonasun147852/solounit

DEV Community: junlong zhu

Before you pay anyone to migrate your Shopify catalog, make them promise these 17 things — in writing

I scanned my own 30 days of Claude Code logs. Here's what I found (and the tool I built to do it)