Saturday, September 12, 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.

Plan — 2026-09-12

<!-- was plan/2026-09-12.md -->

App: Screenshelf. Subdomain when it deploys: screenshelf.bananafest-destiny.com.

Positioning (settled before building)

The wedge is privacy, not price. Free competitors exist (AppLaunchpad, AppScreens, AppScreenStudio, open-source ones), so "cheaper" is not an argument. "Your unreleased app's screenshots never leave your machine" is, and a hosted tool cannot copy it without a rewrite. Second wedge: one click produces every store size as a ZIP.

Design consequences, not just slogans:

• No upload, no account, no analytics, no fonts or scripts from a CDN. Zero third-party network requests, so the claim survives someone opening devtools.
• Works offline after first load (service worker). An offline tool is a provable one.
• Device frames drawn as vector in code, not downloaded image assets.

Phases

1. Editor core (this phase) — import screenshots, device frame, background, headline/subhead, layout controls, live preview, export the current screenshot as PNG.
2. Batch export every store size to a ZIP; watermark on free; license-key unlock; service worker for offline.
3. Deploy to the subdomain, test it as a stranger would, landing page + marketing assets.

Phase 1 scope

• app/ static site: index.html, styles.css, app.js. No build step, no dependencies.
• Import one or many PNG/JPEG screenshots by drag-drop or file picker. Kept in memory only.
• Per-screenshot: headline, subhead, background (solid / gradient presets), device frame on/off, frame colour, screenshot scale + vertical offset, text position (above/below).
• Device frame drawn with canvas paths — rounded body, bezel, notch/island — sized to the screenshot's own aspect ratio rather than a fixed model, so any phone or tablet shot frames correctly.
• Preset store sizes as a selector; render happens at full target resolution, preview is a scaled canvas.
• Export current image as PNG.
• Everything client-side. Verify at the end: load the page, open the network panel, expect no requests after the initial document/css/js.

What I am not doing this phase

ZIP, watermark, licence gate, service worker, deploy, copy for the landing page. Phase 2 and 3.

Open asks to the boss (blocking later phases, not this one)

GitHub remote + push credentials; the cider Cloudflare token, account ID, and confirmation I create the DNS record for screenshelf.bananafest-destiny.com; which payment platform exists that can issue license keys (Gumroad / Lemon Squeezy / Polar / Stripe); a price ceiling or floor; whether they can bridge X, Reddit, Product Hunt, or Indie Hackers.

Plan — 2026-09-12 · Phase 2, get it live

<!-- was plan/2026-09-12-phase2.md -->

Credentials arrived mid-session, so I am deploying before building batch export. A live URL is worth more now than another feature in a folder: it proves the CSP survives a real CDN, and it gives the boss something to open.

Intent

• Point the Worker at screenshelf.bananafest-destiny.com as a custom domain, which creates the DNS record through Cloudflare.
• Set workers_dev = false. RULES says that subdomain "and nowhere else", so the workers.dev hostname must not also serve the app.
• Deploy with the cider token.
• Verify against the live site, not localhost: response headers carry the CSP, the page loads, and the app still renders and exports with nothing going out over the network.
• Push everything to walkertbrown/screenshelf.

Risks I expect

• _headers is a Cloudflare Pages convention. If static-asset Workers ignore it, the CSP silently disappears — which would take the product's main claim with it. I check the live response header rather than assume. If it is dropped, I add a tiny Worker script that sets the header on every response.
• Custom domain provisioning includes certificate issuance, which is not instant.

Not this phase

Batch ZIP export, watermark, licence gate, offline service worker, landing copy. Next.

Plan — 2026-09-12 · Phase 3, the thing people pay for

<!-- was plan/2026-09-12-phase3.md -->

The problem I have to solve first

Every normal way to sell this breaks the product.

A licence key gets checked against the vendor's API. That is a network request, which means relaxing connect-src 'none' to allow one endpoint. The moment I do that, the header no longer says "this page cannot talk to anyone" — it says "this page talks to Lemon Squeezy" — and the one thing no competitor can copy is gone. I am not trading the differentiator for a DRM check.

Signing keys locally with an embedded public key avoids the request, but I would have to mint and sign every key myself. RULES says I do not mint keys, and it is right to: it makes me the single point of failure for every purchase.

What I am doing instead

The paid product is a file, not a key. Pro is the same app built as one self-contained HTML file — CSS and JS inlined, no watermark — that the buyer downloads from the store and opens from their own disk. Gumroad or Lemon Squeezy delivers the file on payment. No key, no check, no server, no network, nothing for me to run.

It fits the product rather than fighting it:

• A stranger pays and gets the thing, with no code from me afterwards. That is the bar in SELLING.md.
• A privacy tool that works from file:// with the wifi off is the strongest possible version of the claim. The paid tier is more private than the free one, not less.
• No licence server to maintain, no keys to lose, no refund mechanics tied to revocation.

The obvious objection is that a buyer can pass the file around. True, and true of any watermark. A $19 utility for people who ship apps for a living does not need DRM; it needs to be worth $19 and easy to buy. I would rather lose some copies than lose the pitch.

Scope

1. Batch export — every store size in one ZIP, one click. The free tier's real draw, and the thing the free hosted competitors make tedious. Store-only ZIP writer (~60 lines, PNG is already compressed), no library, no CDN.
2. Watermark on free exports. Small, in the corner, legible but not destructive — it has to look like a trial, not a hostage.
3. Offline — service worker so the app keeps working with the network off. This is a feature and the demo: "turn your wifi off and reload."
4. Prove it in the page — a panel that states what the page is allowed to do and invites the reader to check it in devtools. The claim should be verifiable without trusting me.
5. build.mjs — produces dist/screenshelf-pro.html, one file, inlined, watermark off. This is the artefact the store delivers.
6. Pricing section with the pay URL left empty until I am given one. RULES: a pay URL goes on the app only after I ask and receive it.

Verify

Browser test extended: ZIP downloads and contains one PNG per preset at correct dimensions; free export carries the watermark and the pro build does not; the app still makes zero network requests; the pro file works opened from file://.

Asks outstanding

Payment platform (Gumroad / Lemon Squeezy / Polar) that can deliver a file on purchase — this is now the only thing between a finished product and a sellable one. Price. X account handle. Whether the X account can go in the free Buffer slot.

Plan — 2026-09-12 · Phase 4, make someone want it

<!-- was plan/2026-09-12-phase4.md -->

The app works. Nobody knows it exists, and the page assumes you already decided to use it — it opens as a tool with a sidebar, not as an argument. A developer who lands here has about five seconds to understand what this is and why it is not one of the free ones.

The pitch, in the order a stranger needs it

1. Store screenshots, made in your browser, every size in one ZIP.
2. Your unreleased app never touches a server — and here is the header that enforces it.
3. Free, no signup, works offline. Watermark comes off for $19.

What I am building

1. A real landing above the tool. Headline, one paragraph, sample output, and a "start" that drops you into the editor. It must be honest that the free tier is fully usable — the competitors' free tiers are the thing I am being compared to.

2. A live network log, in the page. The strongest version of the claim is not a sentence, it is a counter. The page can watch its own PerformanceObserver resource entries and show every request it has made since load — which stays at three, forever, while you work. Reading your own performance entries needs no network, so this works with the wifi off too. It turns "trust me" into something the reader watches tick and not move.

3. Sample output, made with the tool. Dogfood it: generate example store screenshots with Screenshelf itself, embed as data URIs so no image request is made — the CSP would block one anyway, and a landing page that cannot load its own screenshots would be embarrassing.

4. Launch copy. An X thread and an Indie Hackers post. Different shapes: X is a demo you can see in a video-less GIF-less single image; Indie Hackers is one post that has to stand alone and say what I built and why the architecture is the point.

Being honest about the competition

AppLaunchpad, AppScreens, AppScreenStudio are free and better known. I am not claiming to be cheaper or to have more templates — I will lose both. The claim is narrow and true: they upload your screenshots to their servers and I cannot, because the browser will not let me. Everything on the page should point at that.

Verify

Landing renders at phone width; the request counter shows 3 and stays at 3 through a full edit-and-export cycle; no new network requests introduced by any of it; the page still works offline.

Not this phase

Anything needing the pay URL. Posting anything — I write it, the boss posts or hands me the X account.

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.

Actual — 2026-09-12 · Phase 1, editor core

<!-- was actual/2026-09-12.md -->

Done. The app runs, renders, and exports.

What shipped

app/public/ — index.html, app.js, styles.css, _headers. No build step, no dependencies, no third-party anything. Plus app/wrangler.toml for a static-asset Worker and app/test/ for the browser test.

Working: drag-drop or pick multiple screenshots, per-shot headline/subhead/caption position/device size/vertical nudge, eight backgrounds, black/white/no device frame, light or dark caption ink, six store-size presets, live full-resolution preview, PNG export.

Changes from the plan

1. Added a CSP, which was not in the plan and is now the product's spine. The boss's note landed before I started building: the pitch is not price, it's that the screenshots never leave the machine. So I made that claim enforceable instead of asserted. app/public/_headers sends default-src 'none'; connect-src 'none'; script-src 'self' — the browser blocks the page from making any outbound request at all. A skeptical developer verifies it from the response header in ten seconds, and no hosted competitor can ship that header, because their product needs the network. That is the demo.

2. Device sizing was wrong and I rebuilt it. I first scaled the device off canvas width. Tablet and landscape shots came out small and stranded in an ocean of background — genuinely bad output. Now "100%" means the device fills the space it has been given, height or width, whichever runs out first, and the slider scales down from there. Default 94%.

3. Frames are aspect-driven, not model-driven. No device picker. The frame is drawn from the screenshot's own aspect ratio: taller than 1.85 gets phone treatment (big corner radius, dynamic island, side buttons), anything squarer gets tablet treatment (tighter radius, no island, no side buttons). One code path covers every phone and tablet without me shipping or maintaining a device list.

Testing

Real browser, not a claim. app/test/browser-test.mjs drives headless Chromium against the page served under the deployed CSP. Result:

• Requests on load: 3 — the document, the CSS, the JS. Requests after load: none. The two blob: entries are local object URLs for thumbnails, not network.
• Preview canvas came out at 1290 × 2796 for the iPhone 6.9" preset; export downloaded as screenshelf-ipad13-02.png after switching presets.
• Zero console errors, zero page errors.

The test caught a real bug. The background swatches sat inside a <label>. A <label> forwards activation to its first labelable descendant, and buttons are labelable — so clicking any swatch also re-clicked swatch one, and the background could never be changed. I only saw it because I diffed the rendered screenshots and the background hadn't moved. Fixed by using a <div>. That bug would have shipped, and it breaks the first thing a user touches.

Two smaller fixes from looking at output: subhead spacing overlapped the headline; tablets had phone side-buttons stuck to their edges.

Not done, deliberately

ZIP batch export, watermark, licence gate, offline service worker, deploy, landing copy. Phases 2 and 3.

Blocked on facts, not on work

Nothing in phase 2 is blocked. Deploy and selling are: no git remote and no push credentials on this machine, no Cloudflare token, no payment platform, no marketing bridge. Asked in the thread; re-asked at the end of this file.

• GitHub repo URL + push credentials — the repo has no remote, so nothing is pushed yet. Commits are local.
• The cider Cloudflare token, account ID, and whether I create the DNS record for screenshelf.bananafest-destiny.com.
• A payment platform that issues licence keys automatically: Gumroad, Lemon Squeezy, Polar, or Stripe. A plain Stripe Payment Link cannot mint a key, so the unlock would need code I'm not allowed to bolt onto a new provider.
• A price ceiling or floor. Default is $19 one-time unless told otherwise.
• Whether X, Reddit, Product Hunt, or Indie Hackers can be bridged. Buffer is connected but only has Pinterest and YouTube, which are not where indie iOS devs are.

Actual — 2026-09-12 · Phase 2, get it live

<!-- was actual/2026-09-12-phase2.md -->

Live: https://screenshelf.bananafest-destiny.com — Version ID 13e9c8d2-af7c-4ec3-8612-52ff673e5fce.

Repo pushed to walkertbrown/screenshelf. Local branch was master, the repo's default is main; renamed and pushed there.

Went as planned

• Custom domain route created the DNS record through Cloudflare. First request after deploy returned 200, so certificate issuance was not the delay I budgeted for.
• workers_dev = false held: screenshelf.walkertbrown.workers.dev returns 404. It ships on the bananafest-destiny.com subdomain and nowhere else, as RULES requires.
• The _headers risk did not materialise. Static-asset Workers honoured the file; the live response carries the full CSP plus Referrer-Policy: no-referrer, X-Content-Type-Options, COOP and Permissions-Policy.
• Browser test re-run against the live URL: renders, edits, switches presets, exports. Zero page errors.

What I did not expect: Cloudflare injects a tracking beacon into my page

The live page is served with <script src="https://static.cloudflareinsights.com/beacon.min.js/…"> appended to the body. It is not in my source and not in what the Worker returns — Cloudflare's Web Analytics adds it at the edge, after the Worker, and only for browser-like requests. curl sees a clean page; a browser gets the beacon. That is exactly the kind of thing that never shows up in a casual check.

On a tool whose entire pitch is "nothing leaves your machine", a third-party analytics script in view-source is fatal to the claim regardless of what it does.

The CSP caught it. The request is created and then killed by the browser before egress:

request  https://static.cloudflareinsights.com/beacon.min.js/v31edd6…
FAILED   https://static.cloudflareinsights.com/beacon.min.js/v31edd6…  csp

failure().errorText is csp. Nothing was sent to Cloudflare. So the privacy claim is true today, and it is true because of the header rather than because the platform behaved — the CSP defended the product against its own host. I would rather that be a designed outcome than a lucky one, which is the argument for having written it in phase 1.

Still not good enough. A developer who views source sees a Cloudflare beacon tag and stops reading. I want it gone, not neutralised.

I cannot remove it with the token I have. Injection is controlled by account-level Web Analytics, and the cider token is refused on every RUM endpoint (/accounts/{id}/rum/site_info/list → Authentication error, zone-level equivalent → Unable to authenticate request). It is not a zone setting, so it is not in the settings API either. Asked below.

Housekeeping

The GitHub token went into /home/walker/.git-credentials (mode 600, outside the repo) through git's credential store, so it is not in .git/config, not in the remote URL, and not in any tracked file. I did not touch ./.git-credentials, which holds the Cloudflare values and is gitignored — appending a git-format line would have broken it as an env file. Neither secret is recorded in FACTS.md; what is recorded is what each credential authenticates as.

Asks

1. Turn off Web Analytics automatic setup for bananafest-destiny.com — Dashboard → Analytics & Logs → Web Analytics → the site → disable automatic setup. Or add Account Analytics: Edit to the cider token and I will do it. Either works; this one has a real effect on whether the product's claim survives inspection.

Note it affects every site on the zone, so it is your call rather than mine.

2. Payment platform that mints licence keys — Gumroad, Lemon Squeezy, Polar, or Stripe? A plain Stripe Payment Link cannot issue a key.

3. Price — $19 one-time unless you name a number.

4. Marketing bridge — X, Reddit (r/iOSProgramming, r/SideProject), Product Hunt, or Indie Hackers? Buffer has only Pinterest and YouTube, which are not where indie iOS developers are.

Next

Phase 3: batch ZIP export of every store size, watermark on free, licence gate, offline service worker, landing copy that leads with the header rather than the adjective.

Actual — 2026-09-12 · Phase 3, the thing people pay for

<!-- was actual/2026-09-12-phase3.md -->

Done and live. https://screenshelf.bananafest-destiny.com — Version e8ac7c37-f256-4b60-a4b0-73f78d8cd7b5.

Shipped

• Batch export. Tick the store sizes you want, one click, one ZIP: a folder per size, every screenshot in each, named iphone-6.9-1290x2796/01.png. Free.
• ZIP writer by hand, ~70 lines, store-only method. PNG is already deflated so compressing again buys nothing, and it means no library and nothing from a CDN — which the CSP would have blocked anyway.
• Watermark on free exports. A small dark pill in the corner reading "Made with Screenshelf".
• Offline. Service worker caches the app shell. Turn the network off, reload, keep working.
• "Check it yourself" panel in the sidebar, quoting the actual header and inviting the reader into devtools.
• build.mjs → dist/screenshelf-pro.html, 31.6 KB, one file, zero external references. This is the artefact a buyer downloads. The build asserts the PRO flag flipped, the service worker was stripped, and no href/src survived inlining — it refuses to produce a file otherwise.

The paid tier is a file, not a key

As planned. A licence check is a network request, and relaxing connect-src 'none' to allow a vendor API would trade the one thing competitors cannot copy for DRM. Pro is the same app as a single HTML file the store delivers on payment. Opened from disk there is no server and no origin — the paid tier is more private than the free one. No key, no check, nothing for me to run.

The pay URL is the only blank. RULES says a pay URL goes on the app only once given. The Pro panel currently says payment opens in a few days and the link lands there. When Lemon Squeezy clears, it is one line and a redeploy.

Two bugs, both caught by testing rather than reading

1. The service worker was silently forbidden in production while passing locally. I scoped the strict CSP to /* and gave /sw.js its own looser one, assuming the more specific rule wins. It does not. Cloudflare applies every matching rule, so sw.js came back with two CSP headers — and a browser enforces multiple CSP headers as their intersection, so connect-src 'none' won and the worker could not fetch anything to cache. Offline would have been dead on the live site.

My own test server had the same wrong assumption baked in ("most specific wins"), so it passed locally and only the live header check exposed it. Fixed both: the strict policy is now attached to the document paths by name, and test/serve.mjs appends every matching rule the way Cloudflare does, so this class of mistake fails locally from now on. Verified live: exactly one CSP per path, connect-src 'none' on the document, connect-src 'self' on sw.js.

2. My first watermark test proved nothing. Free vs Pro differed by 5 in mean colour over a loose band — consistent with a watermark, and equally consistent with no watermark. I was sampling a region where the pill covered about 3% of the pixels. Re-sampled the exact rect the code draws: delta 25 against a control region delta of 0. Then I cropped the corner of a real exported PNG and looked at it, because a number is not a picture.

Verified on the live site, not localhost

target = https://screenshelf.bananafest-destiny.com/
zipEntries = iphone-6.9-1290x2796/01.png 1290x2796 png=true  (+3 more, all correct)
requestsFree = []          ← no third-party request, none even attempted
swState = activated controller=true
offlineReload = ok 200     offlineAppUsable = True
proRequests = []           ← Pro file from disk, zero requests
watermarkDelta = 25        controlDelta = 0

The Cloudflare beacon is gone

Phase 2 found Cloudflare injecting static.cloudflareinsights.com/beacon.min.js at the edge. It is no longer in the served HTML and no longer requested by the browser. Either the boss disabled Web Analytics or the _headers restructure changed what it matched — I did not establish which, and I am not claiming credit for it. What matters: the page is clean at the source now, not merely blocked after the fact.

Where this leaves the product

Everything a user needs works and is free: import, frame, caption, every store size, one ZIP. The only thing held back is the watermark. That was deliberate — payments are days out, and a tool people are already using beats a landing page collecting emails for something they cannot try.

It is not yet sellable. A stranger cannot pay. That is one URL away, and the URL is not mine to make.

Asks

1. Lemon Squeezy — when verification clears, create the product and send me the checkout URL. It needs to deliver a file on purchase; I will hand you app/dist/screenshelf-pro.html. Price $19 one-time unless you say otherwise.
2. X account — handle, and whether it is new or has a following.
3. Can X go in the free Buffer slot? Buffer allows 3 channels, 2 are used. If X is connected there I can schedule my own posts.
4. Indie Hackers — posting under your name? I will write it to match.
5. Product Hunt — still unanswered either way.

Next

Marketing, which RULES calls part of the work rather than a later phase, and which I have done none of. The demo writes itself — wifi off, reload, still works — but a demo nobody sees is not marketing. First real task: a landing section that sells the idea to someone who has not scrolled the sidebar, then the X and Indie Hackers copy.