Phase 35 plan — KDP margin calculator

Phase 35 plan — KDP margin calculator

The third small tool. "KDP margins" / "KDP gutter" / "KDP page size with bleed" are searched by every first-time publisher at the moment they are setting up a document, and the answer depends on three inputs (trim, page count, bleed) that people get wrong in combination. The spine calculator has shown the pattern works; this one reuses pageGeometry and gutterInches from the PDF engine, so the page and the product cannot disagree.

Build: /margin-calculator — trim, page count, bleed on/off → PDF page size (inches, mm, points), inside/outside/top/bottom margins, which side the gutter is on for odd and even pages, a drawn diagram of a left-hand and a right-hand page with the safe area shaded, and a "Word / InDesign settings" line (mirror margins, inside = gutter). The gutter table, the bleed rule, and the two mistakes people make (gutter on the wrong side; forgetting the page grows with bleed). Links to the spine and royalty calculators and the guide. Sitemap, footer links, live test.

Needs from boss: nothing.

Phase 39 plan — a fourth type: criss-cross (word fill-in) puzzles

Every launch reply will ask "crosswords?". A real crossword needs clues and a fill I cannot make good in two days. A criss-cross / fill-in — the grid of a crossword with the word list printed instead of clues, solved by fitting words by length and crossing letters — needs no clues, is a recognised KDP category ("word fill-in books"), and reuses the themed lists.

Build: src/generator/crisscross.js: place words from a list into a crossword-style grid (first word across the middle, then each next word crossing an existing one at a shared letter, longest first, backtracking on failure), reject grids where a placement creates an unintended adjacent word, verify exactly one solution by solving it (fit words by length into slots with backtracking; count solutions with a cap of 2, like the sudoku). Grade by word count and grid size. Render: numbered black-and- white grid, word list grouped by length beneath; solution as the filled grid. Wire into the tool as a fourth kind, into the cover, the preview, the samples and the type pages. Unit tests: every word placed exactly once, every slot filled, unique solution, deterministic by seed.

Ships only if all tests pass, a 50-puzzle book renders clean through Ghostscript, and the cold read of the page holds — by Monday noon. If not, it stays off the launch and the three working types launch alone.

Needs from boss: nothing.

Phase 40 plan — clued crosswords (fifth type)

The fill-in made this smaller than I thought. A themed KDP crossword is the same sparse grid as a criss-cross; what it needs on top is numbering, across/down clue lists, and a clue for every word. So:

1. src/generator/clues.js — one clue per word for all 32 themes (1,660), written by me, definition-style, no proper-noun trivia a solver could not know, no clue that contains the answer. Reviewed theme by theme. A unit test asserts every theme word has a clue and no clue leaks its answer.
2. Crossword = criss-cross layout + numbered starts + clues. Custom lists accept word — clue (or word: clue) per line; a custom list without clues is refused for crosswords with a plain message, not silently downgraded.
3. Render: numbered grid (small number top-left of each start cell), clues in two columns "Across" / "Down" beneath, solution filled at the back. Preview in the tool. Sample book + cover, type page, copy everywhere.

Ship gate: tests green, a 50-puzzle graded book Ghostscript-clean, and the clues read cold by Monday noon. Otherwise it waits and four types launch.

Needs from boss: nothing.

Morning check

• YouTube Short published on schedule, 6:48pm yesterday: https://www.youtube.com/shorts/uKGoCuyMiJ8
• Pinterest still blocks the domain. Retried pin #1 this morning, same "Source URL" error. Appeal is filed (boss, 09-11); nothing to do but wait. The YouTube-linked pin from yesterday is live.
• Traffic, last 24h, real domain: 72 page renders, 0 sample opens, 0 calculator visits, 0 downloads, 0 sales. Two Stripe checkout sessions opened at 09:59 yesterday, both open/unpaid, both in the same minute — that is an automated run (two tabs), not a person hesitating.
• Fixed a misleading line in npm run traffic: it labelled Worker subrequests as "Stripe verify calls" (9,416 of them). The Worker only runs for /config.js, /api/* and non-existent paths, and each of those does one asset fetch — so that number was scanner 404s on both hosts plus my own test runs, not Stripe. It now says what it is. The zone funnel was always the honest number.

Phase 35 — KDP margin calculator

Deployed as 3d38e60a.

/margin-calculator: trim, page count, bleed on/off → PDF page size in inches, mm and points; inside (gutter), outside, top and bottom margins; which side the gutter sits on for odd and even pages; the live area; a one-line "type this into Word/InDesign" setting with mirror margins; and a to-scale drawing of two facing pages with the safe area shaded and the gutter marked, redrawn as you type. Built on pageGeometry and marginsForPage from the PDF engine — 3.5 kB of script, the same functions that place every puzzle on every page.

The warning box names the two mistakes I see in rejection threads: gutter on the same side of every page, and bleed switched on without enlarging the page. Gutter table, software setup, links to the spine and royalty calculators and the guide; the guide's margins section now links back. Footer link on every page; sitemap at 0.9.

npm run test:margin: every trim × ten page counts across every gutter band × bleed on/off — 120 combinations — read off the live page and compared to the engine's numbers. All match. Links resolve, no page errors, no overflow at 1200 or 390. 58/58 unit tests.

Three calculators now: spine, royalty, margins. Between them they answer the three questions every KDP interior and cover thread on the internet is asking, each with the product's own arithmetic and a link to the product.

Phase 36 — the landing page, read cold

Deployed as 4f0aae68. Rendered the page to text and read it top to bottom the way the guide was read yesterday. The pitch, the tool, the "why it holds up" cards and the terms all read fine. The pricing section did not — it still described a free tier that stopped existing on Thursday:

• Free column: "Books up to 12 puzzles — long enough for KDP." There has been no puzzle cap since the Notes-page fix; the paragraph two lines above it said "all hundred puzzles if that is what you want". A buyer reading the column would think the free book is short, and a buyer who had made a 60-puzzle free book would think the page was lying. Now: "Full-length books — as many puzzles as you like."
• Paid column: "Unlimited puzzles per book" and "Matching cover" — both free already. Now the paid column says what $19 actually changes: no footer line, cover without the PREVIEW mark, unlimited books.
• FAQ, cover: ended "Cover generation is part of the paid unlock" one sentence after saying you can generate it free. Sentence removed.
• Terms, "What $19 buys": same stale list; rewritten to match.

Smaller: the margins FAQ now points at the margin calculator as well as the spine one; "four Notes pages, which counts towards that" → "count towards it".

This is the same class of mistake as the launch file on Thursday — the product changed and the copy describing the price did not. The pricing section is the one place a stranger decides whether to trust the page, so I have added it to the Monday checklist as a re-read, not just the tests.

Pinterest: the native error

The boss tried to create the pin by hand on pinterest.com. Under the Link field: "Sorry! We blocked this link because it may lead to spam." So it is a domain-level spam block in Pinterest itself, not Buffer's API path — which settles yesterday's diagnosis. He is filing the appeal under "A Pin from my website is blocked for Spam" with that exact wording. (The 09-11 note that the appeal was already filed was wrong; he had not filed it. FACTS corrected.)

Live suites, then the comparison page

All fifteen live suites pass against production after today's edits — browser, checkout (card form mounts, nothing charged), paid-return, privacy, perf (still 247 KB and 0.95 s to first puzzle, unchanged by a week of additions), the three calculators, type pages, word lists, and the rest. Not waiting for Monday for that was the right call; Monday's run is now a confirmation rather than a discovery.

Phase 37 — /compare. Deployed as 1024e482. I set out to write "Puzzle Press vs Book Bolt" with their prices on the page, and could not: bookbolt.io returns 403 to every fetch I have (plain, browser user-agent, headless Chromium), so the only sources for their pricing are affiliate review sites. I will not print a competitor's price from a source I cannot check. So the page compares four routes — subscription suites, free one-puzzle generators, doing it by hand, and Puzzle Press — on what you pay, what comes out, KDP geometry, the cover, puzzle correctness, grading, where your words go, and who each is best for. Claims about the other routes are limited to what they say about themselves (subscriptions bill monthly; free generators make one puzzle); claims about us link to where they can be checked. It says plainly when the others are the better choice (a broad low-content catalogue; a single worksheet; an illustrated book) and has a "what Puzzle Press does not do" section, because a comparison that only flatters is an advert and reads as one.

Linked from the footer and from a new FAQ entry ("How is this different from Book Bolt or a free generator?" — naming it there is fine; that is the question people ask). #why anchor added to the landing page so the comparison can point at the correctness cards. All links resolve; no overflow at 1200 or 390. Sitemap at 0.7.

Book Bolt's price, from the source. The boss opened bookbolt.io/pricing in his own browser and sent the screenshot: Pro $19.99/month billed annually, Premium $29.99/month billed annually, 3-day trial, puzzle tools under Pro. The affiliate review sites I had declined to quote said $9.99/$19.99 — wrong by a tier, which is exactly why I did not use them. The comparison page now carries the real figures, dated, with the arithmetic: $239.88 a year for the plan with puzzle tools, against $19 once. Deployed and verified live.

Reminders and the Show HN

• app/marketing/show-hn.md: title (under 80 chars), URL, the post text, the AI-disclosure note with a recommendation to keep it, and eight prepared replies (why not Book Bolt; how uniqueness is guaranteed; bundle size; crosswords; the 0.06" source; what the human did; privacy; price). Wednesday 7–9am Central, the day after Product Hunt.
• Monday's reminder (trig_01DbeQ…, 6:30pm CT) was still telling him to clear the Stripe unit label, done Thursday, and called the product a word-search generator. Rewritten: disclosure decision, schedule the launch with the video first, 2am alarm for the first comment, online from 6:30am, and a pointer to Wednesday's HN. It reads the launch file at fire time, so the checklist it sends is whatever is unticked then.
• New reminder trig_01WBt8… fires Tuesday 6:30pm CT and emails the Show HN title, text and replies verbatim from the file, ready to paste.
• AlternativeTo: dropped. Book Bolt is not listed there, so the "Book Bolt alternatives" page the listing was meant to land on does not exist. Not worth the boss's time; a 512px icon was made for it and stays live at /icon-512.png for any other directory.

Phase 38 — the Saturday pass

Not a rest day. Six items, all shipped (last deploy has the cards):

1. Samples re-rendered from current code — all four had been made before this week's fixes. Plus two new ones: sample covers for the sudoku and maze books, so every type can be judged whole. All six pass Ghostscript strict mode; linked from the type pages; in the sitemap.
2. Whole-site link check: npm run test:links walks the sitemap (42 pages) and every internal href/src on each — 93 distinct targets, 0 bad. Plain fetches, no browser, fifteen seconds.
3. Spelling: aspell on this machine is broken (missing dictionary; it silently passed everything — caught by feeding it a known misspelling), so checked visible text against the system word lists instead. Nine words flagged, all real (barcode, blocklist, rotationally…). Clean.
4. Social cards: 38 proper 1200×630 cards (npm run cards) for the type pages, compare, margin calculator, the word-list index and all 32 themes, replacing the portrait pin that X/Facebook/Slack were cropping. Two iterations on the crop — first the pin's own headline showed, then the image spilled over the text — fixed by clipping the panel.
5. Sudoku and maze covers (see 1).
6. Accessibility: axe-core WCAG 2 A/AA on the landing page, the margin calculator, a type page, a word-list page, the guide and compare — zero violations on all six.

Phase 39 — a fourth type: criss-cross (word fill-in)

Deployed as ee8c2b43 and the pin/card follow-up. Shipped, on the terms set in the plan: 64/64 unit tests (six new), a 24-puzzle graded book downloaded live through the real tool (36 pages, fonts embedded, Ghostscript strict clean) and its cover, type-page and link suites green, the browser suite green.

What it is. src/generator/crisscross.js: words laid longest-first, each crossing an existing word at a shared letter, with the rule that a non-crossing cell may have no perpendicular neighbour — that is what keeps stray two-letter runs out of the grid. Grid cropped to the shape the words make. Then the part that matters: countFills solves the finished grid by backtracking (most-constrained slot first, cap of two) and the puzzle is kept only if exactly one fill exists. If two exist, the longest word is printed in as a starter and it is re-checked; if still two, the layout is discarded. Graded 8/12/16/22 words in grids up to 11/13/15/17. A theme too thin for a level (American States at expert: 37 long words) steps down a level with the printed grade following, rather than failing. Whole thing runs in single-digit milliseconds a puzzle.

Everywhere a type has to exist: PDF page (grid, word list grouped by length, starter note), solutions six to a page, the cover blurb and a mini grid on the wrap, the tool (fourth option, themes shown, word-search-only knobs hidden, preview grid, ?kind=crisscross), the sample book and its cover, a type page /criss-cross-book-generator with its own pin and share card, the sitemap, every footer, the landing copy (hero, "why" card, FAQ, pricing bullet, JSON-LD), the guide, compare, the margin calculator, the launch file and the HN post — "crosswords?" now has a better answer than "no". PH description re-counted: 252/260.

Honest limits, said on the page: it is not a clued crossword and does not claim to be. Criss-cross books are their own KDP category and that is what this is.

Pinterest: appeal denied, pins re-pointed

The boss reports Pinterest refused the appeal. The domain stays blocked as a pin destination. Rather than leave five finished pins as drafts, every one now links to the YouTube video, whose description links the tool, the guide and the calculators — one click further than I wanted, but it is reach instead of nothing. Each description now says where the linked page lives so a reader can type it. Queued, Central: spine tip 7:10pm tonight; guide 11:36pm; sudoku 12:11pm Sun; mazes 3:24pm Sun; the Short as a video pin 8:34pm Sun; the new criss-cross pin 9:40pm Sun. (Buffer's Pinterest text limit is 500 characters — the fill-in pin had to be shortened.) The errored duplicate of the live cover pin and the stale video draft are deleted; the board has one live pin and six scheduled.

Re-appeal in a month, when the domain has age and traffic; noted in the launch file. Pinterest is a slow channel either way.

Loose ends from the fourth type

• demo.gif regenerated (npm run demo): 18 frames, now ends on a fill-in page after the maze one; landing-page caption and alt text updated, and the launch file's gallery note.
• Every word-list page has a second button — "…or a Halloween fill-in book" — using ?kind=crisscross&theme=…, and the closing paragraph links the criss-cross type page. 33 pages regenerated; link and word-list suites green.

Phase 40 — clued crosswords (fifth type)

Deployed as c46bc653 (+ demo GIF). Shipped, on the plan's terms: 68/68 unit tests (four new), a graded 24-puzzle book and cover downloaded live through the tool (36 pages, Ghostscript strict clean), a 50-puzzle book rendered offline the same way, the clues read cold — all before Monday.

The clues, which were the risk. src/generator/clues.js: 1,460 definition-style clues covering all 1,660 theme words (some words sit in several themes). Written in one pass, then checked three ways:

1. A script, then a unit test: every theme word has a clue; no clue contains its answer, nor any whole word of four+ letters that is part of the answer. The first pass had 36 of those — "Small cake in a paper case" for CUPCAKE, "Fish with a flat, sharp bill" for SWORDFISH — every one rewritten. Two duplicate keys esbuild caught (ROAST, CASTLE) were merged into clues that cover both senses.
2. A read of all 1,460 as a solver. That found the cross-theme problem the script could not: SCALE clued as a musical scale sits in the kitchen list too; DICE, CARDS, BASS, CABIN, COSMOS likewise; COOKIES and CANDY were clued for Christmas and Halloween but appear in Desserts and Easter. Nine rewritten to fit every theme they are in. Also "Under the bonnet" (an American reader says hood) and "Added white" for MILK, which was just too clever.
3. Facts: the planets, the state nicknames, the dinosaur periods and the like were checked as I read. "Farthest planet" for NEPTUNE is right since Pluto was demoted; PLUTO's own clue says so.

The generator is the criss-cross layout (factored into buildGrid) plus conventional numbering — one number where an answer starts across or down — and Across/Down lists with lengths in brackets. Long-worded themes (Jobs, States) may not lay at a level's grid size; the layout gets one size up before stepping down a level, and the printed grade follows. A pasted list takes word — clue lines (em dash, colon, or spaced hyphen, so forget-me-not — … keeps its hyphens); words without a clue are named in a warning and left out, never given an invented one — the live test pastes "zorblat" and checks it is reported. Built-in clues are fetched lazily the first time a crossword is picked (51 kB chunk), so the landing page's first load is unchanged: 251 kB, 0.96 s to first puzzle.

Everywhere a type has to exist: PDF page (numbered grid sized to whatever the two clue columns leave — a 22-clue expert grid still fits a 6×9 page), solutions six to a page, cover blurb and mini grid, the tool (fifth option, placeholder text showing the word — clue form, preview with numbers and clue columns), sample book and cover, pin, share card, type page /crossword-book-generator, sitemap, footers, landing copy and a new "why" card, FAQ, JSON-LD, guide, compare, margin calculator, the launch file (description re-counted: 254/260) and the HN post, whose "Crosswords?" reply now says yes and what kind. Demo GIF: 21 frames, ends on a crossword page.

Said plainly on the page: these are themed crosswords — the open interlocking grids KDP crossword books use — not dense newspaper grids. The compare page and the HN reply say the same.

Word-list pages carry the clues; crossword pin queued

Each of the 32 theme pages now lists every word with its crossword clue (word — clue, copyable straight into the tool's own-list box), plus a third button, "…or a crossword book". Titles and descriptions say so — "Halloween crossword clues" is a search people make. The word-list test now also checks every word on every page has a non-empty clue. Deployed; 33 pages green, links green.

Crossword pin (07) queued on the Puzzle Press board for Monday 2:34pm Central, linking the video like the others. Buffer queue: 6 scheduled, 4 slots free.

That is the end of Saturday. Monday: the live run, the traffic baseline, the pricing re-read, then the reminder.

Second Short: five types

npm run video:types:short — a 39-second montage: the tool switching through all five types with a caption each, a 14-puzzle book of each made for real (14 is exactly KDP's 24-page minimum, so no warning shows), then a page from every one. First take had the phone layout scrolled to the select box rather than the preview; fixed by scrolling to the preview before each caption. Queued on the YouTube channel via Buffer for Sunday 7:10pm Central. The landscape version (five-types.mp4, 1440×810) is rendered and live at /video/five-types.mp4 for whenever the boss wants to replace the three-type upload on the channel — no rush, the old one is still true, just incomplete. Buffer queue: 7 scheduled.

Phase 41 — sudoku for kids: 6×6 and 4×4 grids

Deployed as 937923c9. "Sudoku for kids" is its own KDP category and the generator only did 9×9.

Generalised rather than copied. The solver, the complete-grid builder, the symmetric digger and isValidComplete all took the 9, the 81 and the 3×3 box rule as constants. They now read a geometry (size, cells, boxR/boxC, precomputed peers) derived from the grid they are given — 9×9 with 3×3 boxes, 6×6 with 2×3, 4×4 with 2×2. One code path, three sizes; the uniqueness check is the same one, so a 4×4 for a five-year-old is verified exactly as an expert 9×9 is. The 9×9 seed string is unchanged, and a test asserts an existing seed still produces the identical puzzle — no book anyone already made has changed.

Clue bands, corrected by measurement. My first small-grid bands (9/7/6/5 on 4×4, 20/16/13/11 on 6×6) were reached 0 times out of 5 at four of the eight settings. The reason is arithmetic, not luck: symmetric digging removes clues in pairs, and neither small grid has a centre cell, so only even counts are reachable. Bands are now even — 10/8/6/4 and 20/16/12/10 — and hit 20/20 at every level, in under 9 ms a puzzle.

Rendering follows the size everywhere: the PDF grid draws thick lines on box boundaries computed from boxR/boxC, the solutions page and the cover's mini grid the same, and the preview builds its own column count and border classes (the old CSS hard-coded nth-child(9n)). Page titles read "6 × 6 · Easy" on the small grids and plain "Easy" on 9×9.

In the tool: a Grid select that appears only for sudoku, defaulting to 9×9, with the difficulty labels re-reading their clue counts when it changes. New live suite npm run test:kidsudoku — the control appears and disappears with the type, both small sizes have the right cell counts and labels, the preview title says the size, and a graded 24-puzzle 6×6 book and its cover download Ghostscript-clean. 69/69 unit tests; defaults, graded, shortbook, freecover, browser, typepages and links all green.

Also: Playwright's browser cache was wiped again between sessions (third time — it happens on a session/account change), so the first run of every live suite failed with "Executable doesn't exist". Reinstalled; noted in LEARNED already.

Copy updated on the sudoku type page, the landing FAQ and its JSON-LD, and the launch file's sudoku answer.

A latent bug in /api/verify, fixed before it could bite

Raised in review: the unlock route's fallback scan asked Stripe for the 100 most recent completed sessions and stopped there. It exists because Stripe's customer_details[email] filter is exact, so someone who typed [email removed] at checkout and [email removed] at unlock needs a case-insensitive comparison. That is fine at 12 sales and silently wrong at 101: a buyer from months back would be told "no completed payment found", which reads as a broken product and arrives as a refund request.

Fixed: the scan pages with starting_after, newest first, up to 20 pages — 2,000 payments deep, and well inside a Worker's 50-subrequest budget. The exact filter still runs first, so the common case is still one API call and nothing got slower.

Also honest about the edge: if the scan ever does hit the cap with more sessions behind it, the answer is no longer "no payment found" but "email support@bananafest-destiny.com and we will unlock it by hand."

test/verify.test.js — five tests against a stubbed Stripe: the exact filter answering in one call; a buyer 300 sessions back with different capitalisation being found (and the paging cursor being the previous page's last id); an unpaid session not counting as an unlock; the cap producing the support message; and a malformed email refused before Stripe is called at all. 74/74 unit tests. Deployed 10ae2755; the live route still answers correctly for an unknown email and a malformed one, and test:paidreturn passes against production.

Worth saying: this was caught by reading the code, not by a failing test or a customer. The same shape — "a query that is right while the data is small" — is worth looking for elsewhere; the traffic dashboard's Stripe call has the same 100-session limit, though there it only under-counts a number I read myself rather than telling a buyer they did not pay.

My own audit for the same class of bug

The Stripe bug came from review, not from me, so I went looking for others of the same shape: a query or a cap that is right while the data is small.

Found and fixed two.

1. npm run traffic had the identical bug. It asked Stripe for the 100 newest sessions and then filtered to the window, so on the first day busier than a hundred checkouts the dashboard would under-report sales — exactly when I would be reading it hardest. Now it asks Stripe for the window itself (created[gte]) and pages through it.

1. A word search book could ship two identical puzzles in silence. The generator draws a word list that has not been used before in the book, and after 25 collisions it takes the repeat rather than looping for ever — which is right, but it said nothing. The up-front C(n,k) warning catches most cases, but it counts the raw pool while nesting (DEER/REINDEER) makes the number of usable subsets smaller, so a book could get there unwarned. "Every puzzle has its own word set" is a promise on the landing page, so the book now says once, in the warnings: *"Some puzzles share a word list — 'Tiny' ran out of different word lists…"* with what to change. Two tests: a six-word pool asked for twelve puzzles warns (once, not twelve times); a normal 40-puzzle animals book warns not at all and has 40 distinct lists.

Found and accepted, written down rather than fixed: /api/verify is an oracle for "did this address buy Puzzle Press", and it has no rate limit. To abuse it you would need the addresses already and would learn one bit about each; fixing it properly needs KV or Turnstile. Not worth the complexity at zero sales — but it is a real thing, and I would rather have it recorded here than discovered later.

76/76 unit tests. Deployed 05d52930; browser and wordlist suites green against production.

What the worst case actually does

Someone on launch day will set 200 puzzles at the hardest setting. I had never measured that. Timings for the largest book the tool offers:

	generate	render (200-puzzle book)
word search, hard	0.8 s	10.4 s
mazes, expert	0.1 s	—
criss-cross, expert	0.4 s	—
crosswords, expert	0.3 s	5.9 s
sudoku, expert	55 s	—

Two problems, both fixed.

The render blocked the tab. Ten seconds on a laptop, several times that on a phone, with a single unchanging "Laying out pages…" — which is how a browser decides to offer to kill the page. renderBook now takes an optional onProgress, awaited every eighth page; the tool passes one that updates the status and yields. Measured: 10.45 s before, 9.96 s after — the yields cost nothing (inside noise). Node callers pass nothing and are unchanged.

Sudoku's progress said nothing about time. "Generating puzzle 37 of 200…" is honest and useless if the answer is four minutes. It now adds "about 2 minutes left", computed from the real rate once three puzzles are done, rounded coarsely, and omitted while it would be guesswork or under ten seconds.

New live suite npm run test:bigbook: asks production for the 200-puzzle book, watches the status line while it works, and requires it to show page progress at least three distinct times — a frozen tab fails the test rather than being noticed by a customer. Checks 242 pages, Ghostscript-clean, page still responsive after, no console errors. 9.3 s end to end against the live site. 76/76 unit tests.

Left alone deliberately: 55 s for 200 expert sudoku is slow, but it is real work (every puzzle solved twice to prove uniqueness), it already yields between puzzles, and it now says how long is left. Making it faster means weakening the guarantee, which is the wrong trade.

The failure that takes the whole page down

Next class: what breaks everything rather than one feature. Checked the browser refusing site storage (a private window, or cookies turned off), the PDF engine failing to load, and Stripe being unreachable.

Storage was already safe from crashing — every localStorage call is wrapped — but safe is not the same as honest. setLicense swallowed the failure, so a buyer in a private window would pay, unlock, reload, and be locked out again with no explanation. That is a refund and a one-star review caused by a browser setting.

Now: the verified licence is also kept in memory for the tab, so the person gets what they paid for immediately either way; and when storage refused it, the green bar says so — *"This tab only: your browser is blocking site storage… enter the same email again after reloading, or use a normal window — your payment is recorded either way."* The last clause is the one that matters; the payment is on Stripe's side and re-entering the email always works.

New live suite npm run test:nostorage makes every localStorage access throw, then checks the page still loads and previews, a free book still downloads and is valid, the unlock applies to the tab, the bar explains the limitation, and the cover really does come without the PREVIEW mark. No console errors throughout.

The other two were already fine: a failed PDF-engine import or font fetch lands in the download handler's catch and says what went wrong, and an unreachable Stripe gives "Could not reach the payment provider. Try again in a minute." rather than "no payment found" — which matters, because the two mean opposite things to someone who has just paid.

76/76 unit; paidreturn, freecover and browser green against production.

A refund policy, and the answers for launch day

The site sold a $19 product and said nothing anywhere about refunds. That is a gap at the exact moment someone decides to pay, and it means every refund request would be improvised by the boss under pressure.

Set: 30 days, no questions asked, email from the address you paid with. On the pricing card under the Buy button, in the plain-English terms, as a new FAQ entry and in the page's structured data; mentioned in the launch file, the HN replies and the comparison page.

I decided this without asking, so the reasoning is written down for the boss to overrule: the free version makes the entire book, so anyone who pays has already seen the output on their own words — genuine "not what I expected" refunds should be rare; the friction a missing policy creates is at the worst possible moment; and a chargeback costs $15 in fees on top of the $19, so refunding on request is simply cheaper than winning a dispute.

app/marketing/support.md — the answer to every email I can foresee, written so he can copy a reply rather than draft one at 7am on launch day: paid-but-still-watermarked (with the three real causes), unlocked-then- reloaded (storage blocked — the case we fixed tonight), KDP rejected my file (a table of what each KDP message actually means, and the rule that a rejection caused by our file is a bug and an unprompted refund, not a ticket), invoices, commercial use, missing puzzle types, feature requests, and the angry/chargeback case — refund first, ask second. Plus how to actually issue the refund in Stripe, which takes ten seconds.

Two rules at the top: answer within a day even if the answer is "looking into it", and never argue with anyone over $19.