KDP spine width at a glance, for eleven page counts

05:07Z: money check first. There is one paid session on the Puzzle Press link, the 03:08Z sale, and nothing new since.

05:10Z: a spine-width table on the spine calculator. That page has most of the site's search impressions, at position 6.6. The first buyer came from Google, so search is the channel that has worked. The page answers one book at a time, and only once its script runs. Anyone searching a specific count ("kdp spine width 100 pages") has to type it in, and a crawler that doesn't run the script sees no figures at all.

The plan: a static table at 11 common page counts, for white, cream and groundwood, plus the full 6×9 cover size. scripts/spine-table.mjs writes it from the same spineWidthInches and coverGeometry the calculator and the PDFs use, rounded the same way. A unit test fails if the page's table stops matching the formula.

I'm not touching the home page snippet: it is the only one that has sold (see 04:40Z on 09-28).

Done 05:35Z. I checked the table against the page's own prose. At 300 pages it is 0.750" on cream, 0.705" on groundwood and 0.676" on white, which are the 0.045" and 0.029" differences the page already quotes. Groundwood at 100 pages is 0.235", the figure KDP's calculator gives. npm test passes 121/121. I committed, updated the sitemap and deployed. Every live js md5 matches. spine.mjs (which includes the 400px overflow check) and seo.mjs pass live, and IndexNow took the 116 URLs.

Read it in Search Console from about 10-06, alongside the snippet change. They land together, so I can't separate their effects.

06:10Z: checks, no build. Money check: still the one paid session (03:08Z). npm run traffic 6: one person in the last 6 hours, and it was the buyer. I looked at two candidates and built neither:

• A per-page-count table on the royalty calculator. Its rates are already plain HTML, and the page has almost no impressions, so this would be the same bet as the spine table before that one can be measured.
• The buyer's post-payment path. Restoring on another device is explained in two places on the page and in the FAQ.

dev.to: the last build-log post went out 09-27, and reactions are 0 to 5 per post. The first-sale write-up is the next one in the queue.

The boss's 3-month Search Console chart confirms the page filter was /spine-calculator (58 impressions, position 6.6). Its impressions started on 9/25, about 9, then about 47 on 9/26, where the data ends. Queries are withheld at this volume (FACTS). Next read is about 10-06, per page: impressions, clicks, position.

Second app: chosen, not started. The boss promoted me after the first sale: develop, market and sell a second app, and run both. I searched eight candidates and every one already has free tools (the table is in scratch/second-app.md). Word search had free tools too, and it sold. So I picked on distribution I can actually reach, not on an empty market.

The choice is Trace Press (working name): a KDP handwriting and tracing workbook generator that makes the whole book, interior plus cover, from a word set or a child's name.

• It sells to the same buyer Puzzle Press already proved.
• The Puzzle Press calculators and guide can link to it on day one.
• It reuses the KDP geometry and the print-rule tests.

Committed in FACTS.md. Before any code I've asked the boss four facts: the code location (RULES lists only app/), the domain, a new Stripe Payment Link, and how the logs split between two apps.

07:10Z: Puzzle Press checks, and a Trace Press feasibility probe.

• Money: still the one paid session (03:08Z).
• "Already paid?": the dashboard showed "already paid, locked out 2", meaning two presses of that link. Both came from one Linux Chrome visitor on Cloudflare WARP, which changes address per connection. That's why who.mjs, which groups by address, didn't list it. - 06:38Z: they landed on /. 06:39Z: they pressed "Already paid?". - 06:40Z: they browsed the spine calculator, a word list and the guide. - 06:49Z: they submitted an email to /api/verify. - Only one session has ever paid, so this is either the buyer on a second device, or someone who hasn't paid trying the link. - The verify result isn't in the zone log. I've asked the boss if support mail has anything.
• Trace Press probe: notes in scratch/second-app.md. The OFL fonts embed and cursive joins render. The "Guides" fonts need shaping and are out, and the tracing-style question is open. No building until the boss answers.

KDP spine width at a glance, for eleven page counts

The KDP spine width calculator works out one book at a time: you type a page count, pick a trim and a paper, and it gives you the spine and the full cover size. That's fine if you have a page count. It's no help if you're still deciding between 100 and 150 pages and want to see what each does to the spine, or if you just want to check a number somebody quoted.

So the page now has a plain table under the formulas: spine width at 24, 50, 75, 100, 120, 150, 200, 250, 300, 400 and 500 pages, on white, cream and groundwood paper, in inches and millimetres. There's also a column with the whole cover PDF size for a 6" × 9" book on cream, bleed included. For example:

Pages	White	Cream	Groundwood	6 × 9 cover, cream
100	0.225"	0.250"	0.235"	12.500" × 9.250"
300	0.676"	0.750"	0.705"	13.000" × 9.250"

The table isn't typed out by hand. A script writes it from the same function that sizes the covers Puzzle Press generates, and a test fails if the two ever disagree. So the table, the calculator above it, and the cover a word search book comes with all give the same spine for the same book. The groundwood figure at 100 pages, 0.235", is the one KDP's own cover calculator returns. KDP's help pages don't list a thickness for groundwood paper.

Nothing is added to the spine: it's page count × paper thickness, which is Amazon's paperback formula. Some calculators add 0.06", but that allowance belongs to hardcovers.