Monday, September 14, 2026

Consolidated on 2026-09-18 from the per-phase files this day was written in. RULES §3 names plan/YYYY-MM-DD.md; the per-phase names I had invented kept every phase after Sep 13 off the enclosure. Each phase below is verbatim, in the order it was written — only the headings are demoted one level, so the day has a single H1.

Phase 5, rewritten — distribution inside a review window

<!-- was plan/2026-09-14-phase5-rewrite.md -->

2026-09-14. Supersedes plan/2026-09-13-phase5.md, which was written before two facts landed: Pinterest is gone, and the listing is not public yet.

What changed

Yesterday's plan	Why it is wrong now
Pinterest, TikTok, YouTube	Pinterest blocked us and denied the appeal
All links → sizecurve.bananafest-destiny.com	30-day-old domain; weakest possible target
"Start marketing the app"	The listing is not public until review passes. There is nothing to link to

The question I got wrong

I picked TikTok and YouTube because they are algorithmic rather than follower-gated — a new account can be seen without an audience. That is a true and relevant fact, and it answers *"can we get reach from a standing start?"*

It does not answer "is the buyer there?" I conflated the two. Below is the second question, asked properly.

Is the buyer on TikTok?

Evidence for:

• 52% of B2B buyers aged 25–45 use TikTok weekly. Our buyer — someone running a small apparel brand — is squarely in that band.
• Under 1% of B2B SaaS companies post natively on TikTok. Thin competition is exactly when algorithmic reach is cheapest.
• B2B advertisers on TikTok grew 142% year over year.

Evidence against, and it is not small:

• TikTok is an awareness channel, not a conversion one. The consistent finding is that visibility begins on TikTok and conversion happens on search, LinkedIn or email.
• **TikTok-sourced trials convert to paid at 5–12%, against 10–18% for direct or organic search traffic.** The traffic is real and worth less per head.
• Apparel's presence on TikTok is overwhelmingly marketing content — sell more, TikTok Shop, creators, ads. Sizecurve is an operations product. The merchants are there; the mindset mostly is not.

The constraint nobody has written down

I have no face and no voice. Every video is faceless by necessity unless the boss goes on camera, which I am not going to assume. Faceless content on TikTok underperforms person-led content as a rule.

The exception — and it is the one that applies — is screen-and-data content: a real interface, a real number, one counterintuitive claim, text on screen. That format does not need a person because the artefact is the draw.

Which is lucky, because Sizecurve produces an unusually visual artefact: a size curve with the middle hollowed out is legible in half a second.

So: how TikTok actually gets used

The content is the insight, not the product. The product is the payoff line.

Four units, all buildable from assets that already exist:

1. "Your bestselling size is not the one that sells the most." Gross sales bar chart, then the same chart net of returns, and the peak moves. The strongest sentence we own, and it is an argument a merchant will want to settle.
2. "This product says In Stock. It is dead." The broken size run — M and L hollow, and the count of units stranded in sizes nobody buys.
3. "Every return on this dress costs you about $30." Size and fit cause 53–67% of apparel returns. Lands the number a merchant can check against their own P&L.
4. "I read 337 one-star reviews of Shopify apps." Build-in-public. Real work, already done, genuinely interesting, and it needs no live listing.

Unit 4 matters disproportionately: it is the only one that works while we have nothing to sell.

The honest correction about when

TikTok content is perishable — a post is finished in 72 hours. YouTube is search-indexed and evergreen — a video about broken size runs is still being found in six months, which is when the listing will be live and there will be somewhere to send people.

During a review window, evergreen beats ephemeral. Spending our best material on TikTok now burns it on an audience that cannot buy anything.

So the split for the review window:

• YouTube: the real effort. Content posted now accrues, and the 3:08 screencast already exists as a starting asset. Every video is a permanent search-indexed answer waiting for the listing to open.
• TikTok: open the account and age it. Post the low-stakes units, not the best ones. This is the same lesson as the domain — a brand new social account is throttled exactly like a 30-day-old domain, and the only cure is time plus an unremarkable posting history. Aging the account during review is free; discovering it is throttled on launch day is not.
• Indie Hackers: write now, hold, publish on approval. The boss posts. It is the one channel where the post is the destination, so a young domain and an unpublished listing both stop mattering.

What I need

• Buffer with two connections: TikTok and YouTube. Pinterest's slot is dead and I will not spend a connection proving it.
• Confirmation it is fine to post as Bananafest Destiny rather than as the boss personally.

How I will know it failed

Honest thresholds, set before the fact so I cannot move them:

• YouTube: if three months of video produces no listing referrals after publication, the channel is wrong and I stop.
• TikTok: if twenty posts cannot clear 1,000 views on any of them, the account is throttled or the audience is absent, and either way I stop.
• The thing that would change everything: if Indie Hackers alone out-converts both, the answer was never social video and I should have spent the window writing.

Plan — 2026-09-14, phase 6: the storefront scan

<!-- was plan/2026-09-14-phase6-scan.md -->

Written after the boss put two questions to the phase-5 plan that it could not answer: "does shopify even have a foot into tiktok? Who is this for" and "how do you get them?" The first killed a channel. The second exposed that I had a marketing plan with no way to reach a named person in it. This phase is the correction.

---

1. What phase 5 got wrong, and what replaces it

TikTok is demoted from a channel to an account. Phase 5 said TikTok would carry low-stakes units while YouTube carried the thesis; I then sent the thesis to both within four hours of writing that. Worse, the reasoning underneath was wrong: TikTok Shop is real for apparel merchants ($10B+ US GMV, ~475k active US shops, genuine two-way Shopify sync), but merchants sell there — they do not learn inventory operations there. A size-curve app is bought by someone doing reorder maths in a spreadsheet, and that person is not in a TikTok feed in that frame of mind.

So: I withdraw the ask for the boss to do the notification tap-through. It cost their time to attach a trending sound to a channel I no longer believe in. Cross-posting a finished asset stays free, and it ages the account with real work instead of filler, so the cross-posts continue. Nothing launch-critical goes there, and no more effort is spent on it.

YouTube stays on the same terms as before: it is a searchable, permanent place for "your bestselling size is not the one that sells the most," and the kill criterion is unchanged — no listing referrals in three months, stop.

2. The thing this phase actually builds

Shopify's /products.json is public on every storefront by default. No auth, no key, no account. It returns products with their option names and every variant's option1/option2 and available flag. Which means: a broken size run is detectable from outside a store. The exact condition the app exists to catch — core sizes sold out while the tails sit there in stock — is visible to anyone who looks.

That single fact does three jobs at once, and it is the only piece of work available to me right now that does any of them:

1. It validates the thesis for free. I have claimed in a listing, on a marketing page and in a video that apparel brands are sitting on broken size runs. I have never measured it. If the rate comes back near zero, the app is wrong and I would rather find that out from a scan than from three months of silence.
2. It is the best content unit I have. "I scanned N Shopify apparel stores and this many are sitting on a broken size run right now" is a number nobody else has published, and it is the one piece I could post that does not need a link to a listing that is still in review.
3. It sources the outreach list. A store with a measurably broken size run is a named prospect with a specific, checkable problem — not a segment.

What gets built

app/sizecurve/scan/ — a small scanner, in the app folder because it is app work, not a separate tool:

• fetch /products.json?limit=250, paginate, per store;
• classify each product as sized or not (option named Size, or values matching alpha S/M/L/XL runs or numeric runs) — an unsized catalogue is skipped, not counted;
• per sized style, read available per size and mark a broken run where the core of the distribution is unavailable while tail sizes remain available. The core/tail split is defined per run type and written down in the code, not tuned until the number looks good;
• write one JSON record per store, and a summary.

Limits I am imposing on myself, in the code and not just here

Public endpoints only — nothing that needs an account or a token. One honest User-Agent naming the app and a contact address. robots.txt fetched and respected per host. Slow: a hard delay between requests and no concurrency across a single host. No customer data of any kind is available at this endpoint and none is sought. Any store that answers 401/403/404 or disallows is recorded as skipped and never retried.

How the candidate list is built

Honestly, and this is the weak part: I do not have a directory of small apparel Shopify stores. I will assemble candidates from public sources, confirm each is Shopify by the endpoint answering at all, and record the source of every domain in the output so the sample's bias is inspectable. The published number will state its sampling method and will not be dressed up as representative. A convenience sample described as a convenience sample is still worth publishing; one described as a survey is a lie.

3. What I am not deciding — the boss's call

Direct outreach needs a route, and both cost something that is theirs:

• Cold email from a separate domain. Their money (a domain, a sending account, ~4 weeks of warming before volume). Cold email from bananafest-destiny.com is ruled out — that domain is thirty days old and has to deliver the app's weekly alert emails; burning its reputation on cold outreach breaks the product.
• Contact forms and DMs, by hand. Their time, or mine at low volume, with no domain risk at all.

I am not picking for them. The scan runs either way, because the list is worth having before the route is chosen, and the content unit needs no route at all.

4. Order of work

1. Build the scanner, with the limits above in the code.
2. Assemble and record the candidate list.
3. Run the sweep slowly; publish nothing until the numbers are in hand.
4. Report the number to the boss with the method attached, and only then write the content unit.
5. Ask the boss for the outreach route, with the list in front of them.

5. Kill criterion for this phase

If the broken-run rate in a real sample is under ~10%, the "catch broken size runs" half of the pitch is not a real problem and the listing, the feature image and the video all overclaim. I would have to say so and rewrite them around the half that survives — reorder quantities net of returns. I am writing that down now, before I see the number, so I cannot move the line afterwards.

6. Still waiting on the boss, carried forward

• Is posting as Bananafest Destiny rather than personally fine?
• Is Product Hunt possible for them?
• Credential housekeeping: rotate the Shopify client secret, delete the CI automation token, delete the full-access Resend key, rotate the Buffer key. All four passed through chat.
• Shopify's review. If it comes back with anything, it jumps this queue.

Plan — phase 7: turn the scan into customers — 2026-09-14

<!-- was plan/2026-09-14-phase7-outreach.md -->

Phase 6 proved the problem exists and produced, as a by-product, a list of specific stores with specific broken styles. This phase turns that into the first sales conversations. The app has been shippable since 2026-09-13 and is in Shopify's review queue; nothing here touches the submission.

The one thing I cannot do myself

The Resend API key I hold is send-only. Verified: GET /domains answers "This API key is restricted to only send emails". So I can send, but I cannot create or verify a new sending domain.

Cold outreach must not go from bananafest-destiny.com itself. That root domain sends the app's own alerts to paying merchants (alerts@), and a cold campaign that collects spam complaints on the same domain damages delivery of the thing customers actually bought. Outreach goes from outreach.bananafest-destiny.com, with its own DKIM, so its reputation is its own.

Ask of the boss — one action, in the Resend dashboard: add outreach.bananafest-destiny.com as a domain and paste back the DNS records it shows. I will create the records on the zone myself — the cider Cloudflare token can write DNS on bananafest-destiny.com, proved in phase 4 — and they press verify. I am not asking for a full-access API key; that key is on the list I have already asked to have deleted, and asking for it back to save myself one paste would be undoing my own security advice.

Everything else below proceeds regardless.

1. The prospect list

Stratum 2 — the independent labels — is the buyer. Stratum 1 is mostly brands with a merchandising team and a planning system already.

Selection, fixed here before I look for contact details so it cannot be bent to fit whoever is easy to email:

• ≥40 readable size runs. A label with 6 styles does not have a size-curve problem, it has a spreadsheet.
• ≥3 broken styles, so the finding is a pattern rather than one unlucky SKU.
• The example style I name must have ≥2 sizes still stranded. With one size left a merchant can fairly say "that's just sold out". With the core gone and two sizes sitting there, it is the exact thing the app catches.
• Re-checked the morning it is sent. A finding from a scan a week old that has since been restocked makes me look careless in the first sentence, which is the only sentence that matters.

I expect this to cut 44 scanned stores down to something like 10–20. That is fine. A small list I can be specific about beats a large one I cannot.

2. Contact details

From the stores' own public contact pages only. No scraping tools, no enrichment vendors, no guessing firstname@. If a brand publishes a contact address, that is an invitation to contact them; if it does not, it is not on the list. Same politeness rules as the scan: one request at a time, honest user-agent, robots.txt obeyed.

3. The email

Rules, set now rather than in the moment:

• One named style, one specific finding, checked that morning.
• No link in the first email. A cold first contact with a link is a pitch; without one it is a note.
• No invented revenue or margin figures. I do not know their volumes and saying I do is the fastest way to be dismissed by someone who does.
• "Tell me to stop and I will" means it literally — one reply, removed, no follow-up sequence.
• 10–20 a day, no more, ramping from a smaller number on a new subdomain.

4. The content unit

From the scan, published under Bananafest Destiny:

Four in five apparel stores have at least one style on sale right now with its entire core size range gone.

Not the 10% figure, and never without the caveat that ~3 in 4 of those have one size left. The method document is published alongside it, including what I got wrong — the XX Large miss, the one-size miscount, and the 429s I caused. A measurement whose errors are listed is worth more than one that claims none.

5. Finish the cache refill

101 stores still to re-fetch, throttled today. Per-host resumable, 8s floor, spread over the coming days. When it completes, re-run both strata on the improved grammar and republish the table if anything moves.

Order of work

1. Build the prospect list (no contact details yet) — pure analysis of data I already hold.
2. Ask the boss for the Resend domain.
3. Collect contact addresses for the shortlist.
4. Write the email and the content unit.
5. Send, once DKIM verifies. Not before.

What would make me stop

If fewer than 8 stores survive the selection above, the list is too thin to call this a channel, and the honest move is to say so and put the effort into the content unit instead of into 6 emails.

Plan — phase 8: from sent to installed — 2026-09-14

<!-- was plan/2026-09-14-phase8-conversion.md -->

Phase 7 ended with fourteen emails sent and zero customers. Those are not the same distance apart as they look. This phase is about the gap.

The state of things, stated plainly

• The app has been shippable since 2026-09-13 and is in Shopify's review queue.
• The scan measured a real problem across 130 stores and the method is published, errors included.
• Two shorts are cut; one is queued, one is scheduled.
• **Fourteen cold emails are out, and the list that produced them is now empty.** Not paused — exhausted. 130 stores scanned, 31 qualified, 14 published an address.
• Nobody has installed the app. Not one merchant, not one trial.

The last line is the only one that matters, and every piece of work below is ranked by how directly it moves it.

The bottleneck is prospects, not sending

At a 5% reply rate, fourteen emails is expected to produce zero replies and that outcome would tell me nothing. The channel cannot be evaluated at this size, which means the first job is not writing a better email — it is having enough stores to write to that the result is readable.

The funnel from the scan: 130 scanned → 31 qualified → 14 reachable. So roughly one usable prospect per nine stores scanned. To reach 20 sends a day for a week I need on the order of 1,200 stores scanned, which is nine times the sample I have.

This is now cheap in a way it was not last week. The raw catalogue cache means fetching happens once per store and every re-judgement runs off disk for free. The cost is wall-clock politeness — 8 seconds a store, rising on any 429 — not effort and not anybody's patience.

Work item 1: source ~400 more independent apparel stores and scan them. Not from "best Shopify stores" listicles, which is what made stratum 1 full of brands with a merchandising team who will never buy a $29/month app. From sources that select for small and independent. Same politeness rules, same thresholds, and the thresholds do not move to make the number come out.

Being ready for a reply is worth more than the next batch

Fourteen strangers have an email from me that ends "if that is useful I will send the link". If one of them says yes and I answer badly or slowly, that is the single most expensive mistake available to me right now, because it is a merchant who already believes the finding.

Work item 2: write the second email before it is needed. One template, held in the repo, reviewed cold the way the first one was — printed, read whole, not trusted because I wrote it. It sends the install link, says what the app does on day one versus day seven, and names the price without being asked. Nothing else.

Work item 3: the install path, walked by someone who is not me. I have never watched the flow from "clicks link" to "sees first alert" without my own hands on it. I cannot hire a tester, but I can do the next honest thing: walk it on a development store I have not used before, from a cold browser, writing down every step where I had to know something that is not on the screen.

Product Hunt

Available, and a one-shot — it cannot be re-run if it goes out flat. It should not go out before the second email exists and the install path has been walked, because a launch that works is a launch that sends strangers into that flow.

Work item 4: launch after 2 and 3, not before.

Carried from phase 7

• The cache refill, running now: 101 stores. When it finishes, re-run both strata on the fixed grammar and republish the table if anything moves. The figures in the published research page and in the second short are gated on a test, so if a number moves the short stops rendering until the page and the film agree. That is the intended behaviour, not a problem to route around.
• The $30 return and "I read 337 one-star reviews of Shopify apps" — two content units still unwritten.
• Shopify's review jumps this queue entirely if it comes back.

Two questions still with the boss

Neither blocks the work above; both block a specific piece of it.

• Who signs the outreach emails. They go out "— Bananafest Destiny". I will not sign a human name that is not a human.
• Whether the Indie Hackers post discloses that an agent did the work. The draft is written and held. My own view is that it should say so plainly, because that audience will find out and the finding-out is worse than the telling. But it is the boss's name on the studio.

What would make me stop

If the next 60 emails — a readable sample, not fourteen — produce zero replies of any kind, then the email is wrong or the list is wrong, and sending 60 more of the same is not an experiment, it is a habit. At that point the honest move is to change exactly one variable and say which.

If they produce replies but no installs, the problem has moved to the landing page or the price, and that is a different phase with different work.

Consolidated on 2026-09-18 from the per-phase files this day was written in. RULES §3 names actual/YYYY-MM-DD.md; the per-phase names I had invented kept every phase after Sep 13 off the enclosure. Each phase below is verbatim, in the order it was written — only the headings are demoted one level, so the day has a single H1.

Phase 5, actual — the first piece is built and scheduled

<!-- was actual/2026-09-14-phase5-rewrite.md -->

2026-09-14. Against plan/2026-09-14-phase5-rewrite.md.

What was planned, and what happened

Planned	Actual
Unit 1 — the thesis video	Built. 19.00s, 1080x1920, 30fps, 360KB
Post it	Scheduled, not published. YouTube 13:30Z, TikTok 17:00Z
Buffer, two connections	Working over the REST/GraphQL API, no MCP
Units 2–4	Not started
Indie Hackers post	Not started

Both posts came back PostActionSuccess, status: scheduled, error: null, asset probed at 19000ms / 1080x1920 / video/mp4, `isTranscodingRequired: false. Post IDs 6aa79c4eb78fe872efc05b40` (YouTube) and 6aa79c4f5a4fa0b066984a44 (TikTok).

I broke my own rule inside four hours of writing it

The plan says: TikTok gets the low-stakes units, not the best ones, because spending the best material on an audience that cannot buy anything burns it.

I then scheduled unit 1 — explicitly the strongest sentence we own — to TikTok.

Having looked at it properly rather than defending it: the rule was wrong, not the action. It was written as though the material were consumed by being posted. It is not. The asset is a rendered file; cross-posting it costs one API call and burns nothing, and the TikTok account has zero followers, so there is no audience to spend it on in the first place. What is actually scarce is effort, and effort went to YouTube exactly as planned — the title, the category, the description, the search-indexable framing.

The corrected rule, which is what I will hold to:

Do not spend effort on TikTok, and do not put launch-critical timing there. Cross-posting a finished asset is free and ages the account with real work rather than filler.

Filler would have been worse for aging the account than the real thing.

Three things I did not know this morning

1. Buffer fetches the asset live at publish time, from our URL. Not stored at create time. Proved rather than assumed: I rebuilt the video, redeployed it to the same URL, and re-requested Buffer's own thumbnail proxy — it came back a different image, showing the new cut. So the file at media.bananafest-destiny.com is what publishes, and it can still be fixed until 13:30Z. It also means breaking that URL before the post fires breaks the post.
2. The cover frame is frame 0, and it cannot be overridden. Buffer's VideoAssetInput.thumbnailUrl is documented "Do not use". Whatever frame 0 is, that is the tile in a Shorts shelf and a TikTok profile grid. My first cut faded the hook in, so frame 0 read "Your bestselling size" in the top third with an empty centre — and TikTok's grid centre-crops, which would have produced a nearly blank tile. Rebuilt so the entire hook is drawn at t=0 and sits low enough to survive the crop; the only thing that animates is the red landing on "sells the most."
3. createPost returns PostActionPayload, a union of PostActionSuccess and six named error types. I guessed PostCreated, which failed validation. Worth recording that it failed at validation — GraphQL rejected the whole document, so nothing was written and there was no half-posted state to clean up.

What was deliberately not done

• No link in either post. The listing is not public and the domain is 30 days old and Pinterest-blocked. Sending a cold audience at it teaches the platform our links are worth suppressing, at the exact moment we have nothing to gain from the click.
• Sizecurve was not touched. The video is served by a second Worker, bfd-media, for the reason in LEARNED.md: the app is in review and there is no staging copy, so it is not the thing to be redeploying for a marketing asset.
• No trending sound. TikTok does not expose its music library over any API, so an automatically-published post is silent. The video is built to read silently anyway — both platforms autoplay muted — but this is a real ceiling on TikTok performance and I am not going to pretend otherwise.

Next

Unit 4, "I read 337 one-star reviews of Shopify apps" — the only unit that works with nothing to link to — then units 2 and 3. The Indie Hackers post written and held.

Still outstanding from the boss: confirmation that posting as Bananafest Destiny rather than personally is fine; whether Product Hunt is possible; and the credential housekeeping in FACTS.md.

Actual — phase 6: does the problem exist? — 2026-09-14

<!-- was actual/2026-09-14-phase6-scan.md -->

Plan: plan/2026-09-14-phase6-scan.md. That plan pre-registered a kill criterion before any store was touched:

If the broken-run rate in a real sample is under ~10%, the "catch broken size runs" half of the pitch is not a real problem.

It also fixed the definition of "broken" before looking at any data, for the obvious reason: a threshold chosen after seeing the numbers measures the person who chose it.

Verdict: the criterion is met, narrowly in one stratum and clearly in the other. The pitch stands. One part of how I have been describing it does not, and I have written down exactly which part.

---

What I did

Scanned two independent samples of apparel storefronts through the public /products.json endpoint, which every Shopify store answers without authentication. No accounts, no customer data, no private endpoints. robots.txt fetched and obeyed per host, one request at a time, a user-agent naming the app and a contact address, refusals recorded and never retried. Method in app/sizecurve/scan/README.md.

Stratum 1 — 68 brands from public "best Shopify stores" listicles. Named brands. Mostly too big to buy a $29/mo app.

Stratum 2 — 62 brands from an independent-label directory. Small labels. This is the population the app is actually for, and the reason the second stratum exists at all: stratum 1 could validate the thesis and still tell me nothing about my buyer.

A style is broken when every size in the positional core of its run is unavailable while the style is still buyable. Per colourway, never pooled — pool the colours and a sold-out white M hides behind an in-stock black M.

---

Results

	stratum 1 (listicle brands)	stratum 2 (independent labels)
stores in list	68	62
scanned / skipped	57 / 11	51 / 11
products fetched	38,291	10,885
readable size runs	20,282	5,357
sold out entirely	3,359 (16.6%)	342 (6.4%)
still buyable	16,923	5,015
whole run	7,260 (42.9%)	1,800 (35.9%)
partial (some core gone)	5,933 (35.1%)	2,076 (41.4%)
most of core gone	2,045 (12.1%)	568 (11.3%)
BROKEN (all core gone)	1,685 (10.0%)	571 (11.4%)
stores with ≥1 broken run	45 of 53 (84.9%)	36 of 44 (81.8%)

The two populations agree. They were drawn from different sources, by different people, for different reasons, and they are 1.4 points apart on the headline and 3 points apart on store coverage. That agreement is the strongest thing in this report — much stronger than either number on its own.

The number that weakens the headline

Of styles counted broken, 72.7% (stratum 1) and 77.2% (stratum 2) have exactly one size left.

A run with one size standing is technically broken and practically sold through. The framing that survives this is "still on sale, core gone" — which is true, and is what the app alerts on. The framing that does not survive is any suggestion of a warehouse full of stranded units behind each alert. Styles with two or more sizes still stranded are 2.7% and 2.6% of buyable styles. That is the conservative version of the claim and I will not publish the 10% figure without the 72.7% figure beside it.

---

The coverage hole, and what was in it

I told the boss one message into this phase that 34.8% of products with a size option were unreadable and dropped rather than guessed, and that the hole needed characterising before anything was published. It did. Two things were in it, and one of them was my own bug.

Re-reading a fixed-seed 8-store subsample and printing the values my grammar actually refused:

• XX Large — 626 products. My alias table held xx-large and xxlarge but not the spaced form. A plain miss, and the largest single item in the hole. Fixed, and fixed as a rule — <prefix> large/small/medium now resolves generally — rather than by adding one more row to a table that had already failed to have the row I needed.
• ONE SIZE / OS / O/S / Default Title — 426 products. These are not unreadable. They are a hat. Counting them as a failure to parse overstated the hole by roughly a third of itself. They are now reported as their own answer, "one size / no run".
• Shoes — UK 7 / EU 40 / US 9, ~443 each. Deliberately still refused. A shoe size is not this app's axis.
• Jeans — W32 L34, 70CM. Deliberately still refused. Two axes at once is a different measurement, and reading one of them as the size curve is its own bug.

Does the hole change the answer? No.

Running the old grammar and the new grammar over the same bytes for the 29 stores I hold a raw copy of:

	old grammar	new grammar
readable size runs	7,568	8,199 (+8.3%)
one size / no run	0 (miscounted as unreadable)	1,302 (9.5%)
unreadable	34.0%	19.9%
broken (all core gone)	6.5%	6.4%
≥2 sizes left	1.6% of buyable	1.7% of buyable
one size left, of broken	74.9%	73.2%

631 runs came out of the hole and every published figure stayed put. The styles I was failing to read were breaking at the same rate as the ones I could. That is the result I wanted from this check and it is the reason the headline is safe to publish: the hole was not hiding a different answer.

(The 6.4% here is lower than stratum 1's 10.0% because these are 29 different stores, not the whole sample. It is a before/after on one set of bytes, not a restatement of the headline.)

The remaining 19.9% is now almost entirely shoes and jeans, i.e. products this app does not claim to serve. Grammar tests live in app/sizecurve/scan/test_sizes.py, and every case in them is a string a real store actually used.

---

What this cost, and the mistake underneath it

Applying the grammar fix to the full sample meant re-fetching all 130 stores, because the first sweep kept only my analysis of each catalogue and not the catalogue. The second sweep came back 429 Too Many Requests on 48 of 68 stores. The first had 2. Slowing from 2s to 8s between requests did not help — the budget those hosts extend to a stranger is measured over hours, and I had already spent it re-downloading data I had been given once, to fix a mistake that was mine.

So I stopped, rather than keep retrying at other people's expense. What is in place now:

• Raw responses are cached to disk before anything is computed — keeping only the fields the measurement reads, not every store's marketing copy. The next grammar improvement costs me an afternoon and costs them nothing.
• A 429 is never cached as a refusal. It means "come back later". Caching it would turn a temporary throttle into a permanent hole in the sample.
• The sweep is now per-host resumable, so the remaining 101 stores refill over the coming days instead of in one burst.

Written up in LEARNED.md as "I made someone else pay for my bug".

The published numbers above are the first sweep's, which was collected cleanly before any of this. They are not affected by the throttling; the throttling only delayed re-running them with the improved grammar, which the 29-store comparison shows would not move them.

---

The most valuable thing this phase produced was not a number

The scan was built to measure other people's stores. It found two genuine, merchant-facing bugs in my own shipped app, both now fixed, tested and deployed (fe9e4a1):

1. lostShare was summed per variant instead of per size. A style in four colours with M sold out in all four reported lostShare 1.6 — "160% of demand" in the merchant's email — and listed missingSizes as M, M, M, M, producing "Restock M and M and M". Every test had one variant per size, which is exactly why it survived to production.
2. The size-option matcher was anchored /^size$/. Real storefronts use Size (Regular) and Waist. Both were silently dropped, taking the whole product with them — which means the app could have told a real apparel store it had no sized products at all.

Neither was findable from inside my own test fixtures. They were findable only by pointing the code at real stores, which is what this phase did.

---

Against the plan

Planned	Actual
Fix the definition before scanning	Done, and not touched afterwards
Scan a real sample	Two strata, 108 stores scanned of 130 listed
Report the number whatever it is	10.0% / 11.4%, and the 72.7% caveat beside it
Kill criterion ~10%	Met — narrowly in stratum 1, clearly in stratum 2
Be honest about the candidate list	Stratum 1 is largely unsellable; stratum 2 added for that reason, and it is the one that matters
Self-imposed scanning limits	Held, except that I fetched twice — see above

---

Still open

• Refill the raw cache for the 101 stores still throttled, then re-run both strata on the improved grammar and republish the table if anything moves.
• The content unit from these numbers. The strongest honest sentence is: *four in five apparel stores have at least one style on sale right now with its entire core size range gone.* Not the 10%.
• The outreach list. Stratum 2's high-rate stores are the real prospects; stratum 1's mostly cannot buy a $29/mo app. DKIM for outreach.bananafest-destiny.com in Resend, then 10–20/day.
• A judgement for the boss, not a decision I should make alone: given that ~3 in 4 broken styles have one size left, does the listing overclaim? My read is no — the listing says the style "still shows in stock while the stock is dead", which is more true with one size left, and the units-stranded figure the app reports comes from the merchant's real inventory rather than from this scan. But it is the boss's call whether the marketing leans harder on stranded units than the data supports.
• Still waiting on the boss: whether Product Hunt is possible, and the credential housekeeping (rotate the Shopify client secret, delete the CI automation token, delete the full-access Resend key, rotate the Buffer key).
• Shopify's review. If it comes back with anything, it jumps the queue.

Actual — phase 7: turn the scan into customers — 2026-09-14

<!-- was actual/2026-09-14-phase7-outreach.md -->

Fourteen cold emails went out tonight, each naming a style in the recipient's own store that was re-checked live in the seconds before it was written. That is the phase. Everything below is what it cost and what I got wrong on the way.

Against the plan

Planned	Actual
10–20 stores survive selection	31 qualified, 14 had a publishable address
Ask the boss for the Resend domain	Asked; boss added it and did the DNS
Send once DKIM verifies, not before	Verified, probed, screenshot checked, then sent
Stop if fewer than 8 survive	14 — over the line, not by much
Finish the cache refill	Not done. 101 stores still throttled
Publish the content unit	Published, plus a second short that was not in this plan

The list

31 stores cleared the thresholds written into the plan before prospects.py existed — 23 of 51 in stratum 2, plus 8 carried over from stratum 1 that are plausibly the right size to buy a $29/month app. Of those, 14 publish an email address on their own contact page. The rest publish a form, and filling in a stranger's support form to pitch them is worse manners than emailing them, so they are recorded and not contacted.

One store — Big Bud Press — was dropped for a reason worth writing down: the only address they publish is their retail shop floor. Wrong inbox, not a wrong prospect.

The list itself lives at ~/.cider2-outreach/, mode 700, outside this repository. The method is in git; the mailing list is not.

The thing that nearly shipped wrong, three times

The dry run existed to be read, and reading it caught three defects that would otherwise have reached strangers:

1. "the middle of the run is gone and the ends are what is left" — false for Kirrin Finch, where sizes 6 through 24 were gone and only 0, 2 and 4 remained. One end, not two. In an email whose entire worth is that the reader can check it in ten seconds and find it right, a sentence that is wrong about their own stock is the most expensive kind of wrong.
2. "I checked it again this morning" — false at 8pm. Now "just before writing", which is true whenever the script runs, because every finding is re-fetched live at send time.
3. The Love Luna email would have opened **"Teens Side Seamfree Period Bikini Brief"**. Accurate, and the wrong first sentence from a stranger. The store had an adult style with the same problem one row down. prospects.py now ranks styles made for minors last, intimates and swim next, footwear next.

None of these were caught by a test. They were caught by printing fourteen emails and reading all fourteen.

What I got wrong and fixed after the fact

The fourteen carried List-Unsubscribe-Post: List-Unsubscribe=One-Click beside a mailto:-only List-Unsubscribe. RFC 8058 one-click is a POST to an https URI; next to a bare mailto: it advertises a button that unsubscribes nobody. An unsubscribe header that does not work is worse than no header, because a reader who tries it stops looking for the reply line underneath. Removed for every send after these fourteen.

Two things about the sending setup

The key was not what I recorded. I had written that my Resend key was send-only, on the strength of a GET /domains that answered *"This API key is restricted to only send emails"*. The boss said it was full access. Both were true: two keys exist. I minted a new one scoped to the outreach subdomain, overwrote the full-access copy on disk with it, and added the full-access key to the rotation list. A copy of what I now hold cannot send as alerts@, the address paying customers' weekly alerts arrive from.

Resend sits behind Cloudflare. A bare urllib User-Agent gets HTTP 403 error code: 1010 — a bot block that looks nothing like an API error and says nothing about the key. send.py would have failed the same way and was patched before it ran. It now names the app and a contact address, which is what the scan already does to every storefront it touches.

Not in this plan, done anyway

A second short, built from the scan rather than the thesis, and gated on a test that reads the published research page and refuses to render if any of eleven figures has drifted from it. A short is the one place a wrong figure travels furthest and is hardest to correct, because there is no errata line under a TikTok.

Also: the boss edited my queued posts thirteen minutes after I created them. I had spent a while treating the changed publish times as a Buffer bug. The queue is a shared surface, not my outbox, and a time in my code is not evidence of when something published.

Still open

• The cache refill: 101 stores throttled, then re-run both strata and republish the table if anything moves.
• Who signs these emails. They go out "— Bananafest Destiny" because I will not sign a fake human name, and that is a question for the boss, not a decision for me.
• Whether the Indie Hackers draft discloses that an agent did the work. Held, unpublished, until the boss answers.
• Replies. I cannot read /emails/{id} with a scoped key by design, so bounces and complaints are visible to the boss's inbox before they are visible to me.