BookFlow AI

Situation

A commercial AI SaaS for KDP creators

BookFlow AI compresses the fragmented multi-tool workflow most KDP creators use—ChatGPT for prompts, Midjourney for images, Canva for layout, manual KDP formatting for export—into a single guided system. Live at bookflowai.site.

01 // The User Was Me

I wasn't looking to build a product. I was trying to make a book.

I wanted to publish a low-content book on KDP as a side project. The workflow I ended up in: ChatGPT, Midjourney, Canva, Kindle Create, plus KDP's rules docs. Four tools, four subscriptions, fifteen hours per book.

Somewhere mid-Saturday, moving PNGs between Canva and Kindle Create, I stopped. If I was struggling as someone who uses these tools for a living, anyone less technical was having a worse time.

02 // The Alternatives

The stack creators already use — and why it stops short

Every creator ends up as their own integration layer. Each tool below is built for a different job — none for the full workflow.

● fully supported  ·  ◐ partial  ·  — not supported

I used each of them myself. Each one broke in a specific way:

Same failure mode everywhere: full input, full output, no control in between. Not a feature gap — a trust gap. Why pay for a black box you can't verify or edit?

03 // Who Feels This Most

My own pain was evidence of a personal problem. It wasn't proof of a market.

One Saturday of frustration isn't a business. Before asking anyone to join or pay for this, I needed proof the pain was concentrated in other people — and concentrated in the same shape.

No budget for a 10,000-person study. So I stacked four cheap, imperfect sources and made them converge. No single one is proof. All four pointing the same way is.

1. Community listening + quote coding

Reddit, r/KDP, X, Facebook KDP groups, YouTube comments. Verbatim quotes copied into a doc, then coded for recurring language. "Too many tools." "Inconsistent output." "$22 a month is a lot when I make $80."

r/KDP (15k members). One of four community sources.

2. Scholarly surveys for the macro shape

Two recurring indie-author surveys anchored the macro picture (ALLi Big Indie Author Survey, Written Word Media's State of Self-Publishing). Roughly half of self-published authors earn under $1,000/year from books, and only about 10–15% clear a full-time income threshold. Not a market of full-time publishers — a market of side-hustlers.

Those surveys don't segment the low-content KDP niche directly, so I built the demographic picture myself by cross-reading three things: the Prolific screener results, the 12 interviews, and several hundred quote-coded community posts. The same two archetypes surfaced in every source. The larger one — the clear majority of active low-content sellers I saw — is side-hustle parents, overwhelmingly moms making books in categories they already live inside every day. The second, smaller but distinct, is retired hobbyists — 55 to 70, often former teachers or nurses, treating this as a creative outlet rather than a business. Those two archetypes became the personas below.

3. Paid survey through Prolific — a population I didn't pick

~200 responses through Prolific, screened on self-published authors who sell on Amazon KDP. I negotiated student-researcher pricing with Prolific in exchange for committing to them as my primary panel across future studies and promoting them inside my program at Michigan — roughly half off, bringing all 200 completes to ~$560 total. This was the first primary-research step I ran. The purpose was specific: four categories of product-shaping answers I needed before freezing scope —

• Who the users actually are — current tools, publishing frequency, where they get stuck.
  68% were stitching Canva + ChatGPT + Midjourney by hand. 45% publish fewer than one book per quarter. Most-cited stuck point: "keeping image style consistent across 40 pages" (41%).
• Willingness to pay — price point at which side-hustlers actually convert.
  62% would pay for an end-to-end AI tool. Median acceptable monthly price: ~$13. And 34% said they'd never subscribe but would pay per book — a named audience for the per-book tier (§07).
• Feature priority rank — of the five workflow steps, which is most painful to do by hand.
  "Generate 40 consistent pages" ranked #1 most painful (42%). "KDP-correct export" second (28%). "Concept" ranked last (4%) — creators come in with the idea, not looking for one.
• Speed vs. control preference — where each persona falls on the tension.
  Side-hustle parents: 68% would accept a one-shot AI book if it saved 10+ hours. Retired hobbyists: only 22%. But 82% of both groups said they wouldn't trust one-shot AI on KDP compliance. HITL is load-bearing, not optional.

Not statistically significant. The question I was asking the survey was different: do the same themes come back when I remove myself from the selection? They did.

4. Twelve interviews I ran myself

Once the survey patterns were in, I ran twelve one-on-one interviews (plus 8 follow-ups through Respondent.io) designed around the survey's surprises and gaps, not to repeat it. I didn't ask people to describe their workflow. I asked them to show me. Four things only watching could answer:

• Why the per-book preference? (Survey: 34% refuse subscriptions.)
  9 of 12 said "I don't publish enough to justify a monthly fee." None cited price. The per-book tier isn't about being cheaper — it's about commitment aversion.
• What does "40-page consistency pain" actually look like? (Survey: ranked #1 most painful.)
  Observed creators averaged ~18 image-regeneration attempts per book before giving up on consistency. 4 of 12 had built their own "character reference" folders by hand — literally what our orchestrator automates (§06).
• Speed vs. control, observed in real time. (Survey: 68% / 22% split between personas.)
  Side-hustle parents said "yes" to a one-click book — then immediately asked "can I change the cover?" They don't want true one-shot. They want speed + last-mile editability. Retired hobbyists wanted control from step one.
• The smallest trust signal? (Survey: 82% don't trust one-shot on compliance.)
  Unanimous: "show me a preview of the KDP-compliant PDF before I pay." 10 of 12 said they'd pay more for a tool that visibly checks KDP rules during generation, not after. That shaped the review + export preview in §06.

Four methods, one consistent picture. Two personas, same underlying need, opposite directions:

Opposite constraints, same need: balance speed with creator ownership. Fast enough to be worth it, editable enough to feel like yours. That tension is what the rest of the product has to solve.

04 // The Decision

The hardest decision was not what to build. It was who to build it for.

BookFlow started as an internal tool. The three of us wanted a script to make our own KDP side business less painful. A tool for three users.

The research changed my view. The same pain kept showing up in communities, in the literature, in interviews. This wasn't just our problem. Building for three solves three people's pain. Building for the market solves a structural gap.

The reframe — internal tool → market product — was the hardest call I made. Not because the upside was unclear. Because the discipline is completely different. Internal tools can be ugly and assume the user knows the system. A market product has to earn trust in five minutes from a stranger.

My co-founders weren't convinced. They signed up for a side business, not a SaaS. So I put the research into a short internal pitch — the income data, the community signals, the failure modes from §02, the personas from §03. Not "it would be cool to launch this." But "we already have the domain knowledge and the hardest piece of the build. Every week we don't productize this is a week the gap stays open for someone else."

We started with coloring books — not because they're easy, but because they were the fastest place to get signal. It's the format where I'd felt the pain, where iFlowy's gaps were the most visible, and where I could tell within ten minutes whether BookFlow was better. Once that loop worked, the other ten low-content formats followed. They all share the same property: formula-driven.

05 // Product Thesis

Workflow layer, not generator

Every AI KDP tool sells itself as a generator—"AI-powered book creation." That framing loses the moment a better model ships. BookFlow is a workflow: creators wake up wanting a finished, KDP-compliant book on their Amazon shelf, not a faster generator. The generator is a means. The workflow is the product.

06 // What We Built

Eleven book types. One workflow. Human in the middle.

I designed the product architecture — the eleven book types, the five-step workflow, the human-in-the-loop review step, and the KDP compliance layer. Our engineer built what I specified.

The five-step workflow

• Input: creator enters topic, theme, page count, art style, book type. Takes about a minute.
• Plan: Gemini 3.1 Pro generates a structured book blueprint—page-by-page titles and prompts. Creator can edit the blueprint before generating images.
• Generate: Gemini 3.1 Flash Image generates all pages in parallel. For illustrated books, character sheets keep visual consistency across pages.
• Review: creator reviews each page, approves or rejects, and can regenerate individual pages without restarting. This is the human-in-the-loop moment that makes the output trustworthy.
• Export: system generates a KDP-compliant PDF with correct trim size, bleed, margins, and spine width based on page count. ZIP bundle includes interior PDF and optional PNG files.

[ images/bookflow/bookflow-review-step.png ] — Screenshot from the signed-in app showing the Review step (approve/reject per page).

Why human-in-the-loop matters

Every competitor I studied shipped a one-shot pipeline—describe the book, get the book, hope it's good. That works for demos. It fails for commercial use because a single bad page makes the whole book unpublishable, and regenerating from scratch is both expensive and frustrating. The review step is what turns "probably usable" into "ready to publish." It is also what separates BookFlow's workflow framing from the generator framing: the creator is in control of the output, not trapped inside whatever the model produced.

07 // Pricing & Business Model

Pricing is a product decision, not an afterthought

I own pricing. Two cohorts, two shapes: high-volume publishers who want predictable monthly cost, and casual creators who publish once a year and will never subscribe to anything. Most tools ignore the second group.

The per-book option is the distinctive move. Every competitor is structurally resistant to it because it disrupts subscription revenue. It's also what gets the casual creator past the commitment barrier—and the hypothesis is that every $3.99 purchase becomes a qualified lead for Creator tier upgrade.

Unit economics

At current Gemini pricing, a full 40-page book costs roughly $2 in API spend (blueprint + image generation + average HITL regeneration). Creator and Pro tiers target a 30–50% gross margin at realistic usage (3–5 and 8–12 books/month respectively, well below cap). The per-book tier is the cleanest line — $2 cost, $3.99 price, ~50% margin with no cap-blowout risk. Early-stage infrastructure and API usage is covered by Google for Startups and Vercel credits, giving us a three-month runway to re-calibrate caps against real usage data before we start paying cash for compute.

08 // My Contribution

A three-person founding team

BookFlow is the product of a three-person team. I lead product and strategy. My co-founder leads engineering. Our compliance partner owns Amazon KDP legal and policy risk.

09 // Validation & Results

Four signals, one honest story

Two halves: what we proved to ourselves by dogfooding, and what external users have shown since.

The honest caveat: we haven't run paid marketing, and we haven't pushed hard for conversions. What we have is a set of convergent signals that say the same thing — the core loop works for real users outside the founding team. That's product validation, not market validation. Each signal measures something the others can't: dogfooding proves the workflow ships real books; organic downloads prove external pull; community mentions prove word-of-mouth; the KDP review queue proves compliance works on real Amazon policy, not our own tests. The next step is intentional distribution — and instrumenting a dedicated exports table so the generation-to-download funnel has its own source of truth instead of being inferred from session logs.

10 // What Comes Next

The marketplace is the real business

The tool is the beginning. The business is a marketplace. KDP creators split into two groups that should be the same person but rarely are—and today, they don't meet.

A marketplace inside BookFlow would let them trade. I'm not building it yet—the core workflow needs to be solid first, and marketplaces are demand-side-hard. But every product decision today either enables it or makes it harder to build later. The generations table already records enough metadata to expose creator stats publicly; the per-book flow is one UI away from being a listing flow.

11 // Reflection

What I learned being the PM

The hardest part was judgment under ambiguity

On WeFire, I had a PM who set the KPI, approved the PRD, and made the final call on scope. On BookFlow, nobody was going to tell me whether the pivot was right. I had to make the call, watch the consequences, and adjust. The first two weeks I was scared of this—every strategic choice felt like it could be wrong, and nobody was going to stop me from shipping the wrong thing. Product work without a PM above you is deciding what the frame is. I changed my mind about the category, the pricing, and the marketplace within the first six weeks. The case study makes it look linear. It wasn't.

What I'd do differently

• Instrument exports from day one. The generations table was there from v0.2 because we needed it for plan limits. The exports table wasn't, because I didn't think it mattered. It mattered. Any metric claim about downloads should have its own source of truth, not an inference.
• Talk to operators before building the tool. The marketplace hypothesis would have been easier to validate if I'd spent two weeks interviewing Amazon KDP operators about whether they'd buy ready-made books. I assumed the answer was yes based on creator-side conversations, but the supply side is the riskier hypothesis.
• Bring the team into the strategic pitch earlier. The internal-tool-to-market decision in §04 took longer than it needed to because I built most of the evidence case by myself before surfacing it. If I ran the same call again, I'd share the early research signals with my co-founders as they came in, not stack them into a single pitch at the end. Not because the decision would change — because the convincing is faster when the team is reasoning alongside you, not being presented to.