AI Book-Summary Writer

The situation

New authors joining the coaching program hit the same wall at the same moment. Before anything else, they had to write a structured summary of the book they wanted to write. It is the hardest task in the whole program and it comes first.

The existing tool for it was a worksheet. It asked for everything at once, on one page, and most people froze. Coaches ended up walking clients through it line by line on calls, which is expensive and does not scale past the number of hours in a week.

The ask was to turn that worksheet into a product. Something an author could open cold, sit down with once, and leave holding a finished summary they could paste straight into the main platform.

What was broken

• The worksheet presented every question at once, which is exactly the blank-page problem it was meant to solve.
• Coaching time went into walking each new author through the same form by hand, one call at a time.
• Teaching books and memoirs need different questions and a different paragraph structure, and one worksheet served both badly.
• An earlier assistant approach asked the book type as its first conversational question, spending a turn on it and leaving room for misclassification.
• The output had no fixed shape, so what came out was not reliably pasteable into the main platform.
• Nothing produced the structured version the coaching team needed on their side of the same conversation.

Constraints

• The app had to feel native to the client's main product rather than like a separate tool bolted on.
• The provider API key could never reach the browser, and the build had to succeed without it configured.
• A ten-question interview is long enough that a refresh must not destroy it.
• The output had to match the coaching worksheet exactly, because that is the artefact the coaches already knew how to use.
• It shipped as a standalone deployment, so there was no existing backend to lean on.

What I built

The branch moved out of the conversation

The first design decision was the most useful one. The book-type choice became a two-card UI selector, styled after the main product's own book-type chooser, rather than the interviewer's opening question. That let the system prompt open by stating the type is already chosen and must not be asked. It bought back a turn and removed an entire class of misclassification.

Each path then carries its own ten ordered questions. The teaching set walks working title, subject, reader, problem, lessons, five topics with detail, differentiation, motivation, reader action and planned chapter count. The memoir set walks working title, the life season, the shaping struggle, life before, five events with outcomes, the turning point, how it changed them, lessons, why share, and the reader takeaway. A testimony is not a how-to, and the structure had to change with it.

The interviewer, and the discipline it enforces

The prompt carries hard rules: ask exactly one question per message, never present a list or a checklist, never skip or merge questions, acknowledge only what the author actually said, and never invent a fact. The whole product is the discipline of one question at a time, because a list is the worksheet that was already failing people.

One follow-up fires when an answer is vague, short, or misses part of the question. When the author says they do not know, the prompt requires warm acceptance and forbids a second push. The five-item question is where the longest paragraph comes from, so thin answers there produce a thin summary. That question is gathered a few items at a time and never as a numbered checklist.

One server route holding the whole AI surface

There is a single AI endpoint. It validates that the body parses, that messages is a non-empty array of well-formed role and content pairs, and that the path is one of the two allowed values. One route is the entire attack surface, so it validates everything before it spends a token.

The provider key is read only inside that route. When it is absent, the route returns a typed unavailable response instead of failing the build or leaking the condition. A misconfigured deploy becomes a clear, specific failure rather than a broken build.

A self-check the model must pass before it may emit

Before emitting, the model counts its own paragraphs and estimates length. If the draft is not exactly five paragraphs it merges or splits until it is. If it falls under the length floor it expands the thinnest paragraphs, drawing only on what the author already told it. Shortening the summary to make room for anything else is explicitly forbidden.

One stream, two audiences

The same response carries two things: the author's prose summary, and a structured internal production brief for the coaching team. Both are wrapped in paired sentinel markers. The client extracts the latest of each, strips both out of the visible chat, and routes them into two separately copyable cards. The author sees prose and never sees a marker. The team gets the structured version without a second pass.

Persistence, branding and delivery

The session is versioned and saved as the interview runs, then validated on load. Anything invalid clears the key and starts fresh. Brand context, a design brief and a design prompt were written before the build, and light and dark theming plus a shared app shell make it read as part of the main product rather than beside it. It deploys on Vercel with the key held server-side.

Edge cases and failure handling

• A mid-interview refresh restores path, messages and position from the saved session rather than losing ten questions of work.
• A saved session that fails validation on load clears itself and starts clean, instead of restoring a broken state.
• Every storage read and write is wrapped, so private mode, a quota error, a disabled store or server-side rendering is a silent no-op rather than a crash.
• A missing provider key returns a specific unavailable code from the route, so the deploy still builds and the failure is diagnosable.
• A draft that comes back as three or seven paragraphs is merged or split to exactly five before it reaches the author.
• A thin answer gets exactly one follow-up, and an author who says they do not know is never pushed twice.
• The anything-else gate is asked once. A yes regenerates both blocks faithfully with the addition and no invented facts, rather than opening an endless loop.
• Output markers are stripped from the chat thread, so the transport format never leaks into the reading experience.

How I verified it

The coaching worksheet was the specification. Both paragraph structures, both prose formulas and the expansion rules all derive from it, so verification meant checking the emitted artefact against the worksheet the coaches already used rather than against my own taste.

The interview was walked end to end on both paths, teaching and memoir, including the thin-answer follow-up and the do-not-know acceptance. The five-paragraph self-check was exercised against drafts that came back the wrong shape. Session restore was checked against a refresh mid-interview, and against a deliberately corrupted saved session. The missing-key path was verified to build and to return its typed unavailable response rather than a crash.

What changed

An author now goes from a blank page to a finished, paste-ready summary in one guided sitting. The output is five paragraphs, expandable to ten on request, in the exact structure the main platform expects.

Coaches are no longer walking every new client through the worksheet by hand. The same run also hands the coaching team their structured production brief, copied from its own card, which the worksheet never produced at all.

The client owns a real AI product rather than a workflow: a standalone Next.js app, designed, built and shipped, branded to sit inside the product they already sell.