A 58-Book Publishing Factory, Built and Run by One Person

Most "AI wrote my book" content is one long chat transcript. That is not a pipeline; that is a demo. What I run in ~/ebook-factory/ is closer to a small manufacturing plant: 58 books, each with a manuscript, a retail listing, a landing page, an EPUB, a print-ready paperback PDF, and a brand-consistent cover — all produced by agents working from written specifications, all reviewable in the repo.

I will not tell you what it earns, because I cannot verify a revenue number for you and I do not publish numbers I cannot verify. What I can show you is the architecture, because the architecture is sitting on my disk and every claim here maps to a file.

Why a factory, not a project

One book is a project. Fifty-eight books is an operations problem, and operations problems reward different tools: shared specifications instead of fresh prompts, batch scripts instead of hand work, and inventory files instead of memory.

This is the same doctrine I described in how one person runs five brands with agent fleets: the operator's job is to build the system that does the work, then supervise it. The publishing factory is the cleanest single example I have, because the whole thing lives in one directory and you can audit it top to bottom.

The factory splits the portfolio across three author brands — MentorMe (solopreneur, finance, career, AI topics), my own name (wellness, health, lifestyle), and Acromatico (branding, photography, SEO) — so books in the same niche cluster can cross-promote each other on the retailer's recommendation engine instead of competing head-on.

The pipeline stages

Every book passes through the same stages. Here is the honest split of what each stage is, what runs it, and where the output lands.

Two things make this work at 58-book scale, and neither of them is a clever prompt.

The shared build brief

Every manuscript agent reads the same file before writing a word: _BUILD-BRIEF.md. It pins length (11,000–16,000 words), structure (introduction with a hook, 8–12 chapters with real subsections, concrete steps and checklists, conclusion), voice ("a trusted friend who knows the science — direct, no corporate jargon, no fluff, no hype or fake income claims"), and — critically — a style reference: read book-09-side-hustle/manuscript.md first and match its tone and formatting.

That last instruction does more work than any adjective. Telling an agent "write well" produces average output; telling it "match this specific existing artifact" produces consistency. I wrote about this pattern in how CLAUDE.md and skills stop agent drift — a written specification that every agent loads is the difference between a fleet and a mob.

The brief also carries hard rules: dev/local only, no deploying, do not touch other books' folders, return a one-line summary of what you wrote. Scoped agents with explicit boundaries are how you run dozens of parallel builds without them stepping on each other.

The batch scripts

The repo's underscore-prefixed files are the factory floor: _gen_covers.py, _gen_cover_batches.py, _gen_unique_covers.py, _gen_photo_covers.py, _gen_paperback_pdfs.py, _gen_inventory.py, _rebrand.py, _rebuild_meta.py, plus shell wrappers like _render_all.sh and _render_batches.sh. Naming convention matters at this scale — one glance at ls tells you what the plant can do.

How the covers are batch-generated

Covers are where most solo publishers stall, because design tools do not batch. My answer: covers are web pages.

_gen_covers.py does not open a design app. It loops over the book directories, scrapes each book's real title and subtitle out of its already-built landing page with regex, decides the brand from the page markup, and then writes an HTML file per cover — background color, accent bar, logo path, and typography all set from a per-brand palette dictionary in the script (MentorMe gets the dark #0B1A24 with coral #FF6B57; the wellness line gets cream #F5F0E8 with forest green and terracotta). A headless browser then renders each HTML file at exactly 1600×2560 and screenshots it. The shell wrappers batch the rendering; _gen_cover_batches.py and _gen_unique_covers.py handle variant runs, and _gen_print_cover_59.py extends the same approach to full print wraps.

Why HTML instead of an image-generation model? Three reasons that only show up in production:

• Determinism. The same script produces the same cover every run. When I rebrand a line, _rebrand.py plus a re-render updates every cover in minutes with zero drift.
• Text fidelity. Image models still mangle typography. HTML sets type perfectly, every time, at any length of subtitle.
• Single source of truth. The cover pulls its title from the same file the listing uses. A title fix propagates everywhere; nothing is manually kept in sync.

The lesson generalizes past publishing: when you automate anything visual with AI, reach for deterministic rendering first and generative models only where determinism cannot go. It is the same evidence-over-instinct posture I apply in the verification gap in production agents — outputs you can regenerate and diff are outputs you can trust.

What stayed human

A factory metaphor invites the wrong conclusion — that nothing human remains. Here is what I never delegated:

• Taste. Which 58 topics, out of hundreds of candidates. Which title survives. Whether a cover palette reads premium or cheap. Agents generate options; the accept/reject gate is mine.
• Brand architecture. The three-author split and which niche belongs to which brand is a positioning decision, made once, encoded into the brief and the palette dictionaries so agents inherit it instead of re-deciding it.
• Claims discipline. The brief bans hype and fake income claims at the specification level, and _publish/CLAIMS-AUDIT-PORTFOLIO.md exists because I audit the portfolio for claims rather than assuming agents complied. Trust, then verify — in that order, every time.
• The honest-numbers rule. This post says "58 books" and describes the pipeline because both are verifiable in the repo. It says nothing about revenue because that is not yet a number I can stand behind. Writing that sentence is a human job too.

The honest blockers

Here is the part most automation content omits: the pipeline is complete, and the books are not live yet. The blocker is precisely the category of step that cannot and should not be automated — retailer account verification. The publishing account needs a tax interview tied to my SSN, a bank account for royalty deposits, and two-step verification. These require my personal credentials and the platform's identity checks. It is a one-time manual session, it is documented in the repo's publish plan with an upload guide and a launch queue waiting behind it, and the moment it is done, all 58 books ship in priority order.

I flag this deliberately, for two reasons. First, credibility: a case study that claims 100% automation is either lying or describing a toy. Second, design: knowing in advance which steps are human-only lets you architect around them — everything upstream of the blocker got built in parallel while the blocker waits, so the manual session gates nothing except the final click. That is the operator mindset I laid out in what an AI systems builder actually does: the job is not eliminating humans from loops; it is putting the human at exactly the loops where a human is load-bearing.

What this teaches about content-product pipelines

Strip away the books and the pattern is reusable for any content product — courses, template packs, printables, documentation sets:

1. Write the spec once, run it N times. The build brief is the product design; agents are the assembly line.
2. Reference artifacts beat adjectives. "Match book-09" outperforms any paragraph of style guidance.
3. Deterministic rendering for anything visual. HTML-to-image batching gives you rebrands and fixes for free.
4. Inventory as code. _inventory.json and generated metadata mean the portfolio's state is queryable, not remembered.
5. Name your human gates. Identity, banking, taste, and claims stay with the operator — plan the build so they gate as little as possible.

FAQ

Can AI really write a whole book worth publishing?

An agent can draft an 11,000–16,000-word practical nonfiction manuscript to a tight specification, and the draft quality depends almost entirely on that specification — structure, voice rules, and a concrete style-reference file to match. What AI cannot do is decide which book deserves to exist, or take responsibility for the claims inside it. Those stay with the operator.

How do you automate book publishing with AI without the books all sounding the same?

Deliberately shared bones, deliberately distinct skin. Every book uses the same structural spec, but topics are split across three author brands with different niches, voices calibrate to different style-reference manuscripts, and the brief requires concrete steps, examples, and checklists specific to each topic. Sameness comes from lazy prompts, not from shared pipelines.

Why generate covers with Python and HTML instead of an AI image model?

Determinism, typography, and a single source of truth. HTML covers render identically every run, set real type without the garbled text image models still produce, and pull their titles from the same files the listings use — so one edit propagates everywhere and a full-portfolio rebrand is a script run, not a design week.

What parts of publishing can a solo operator not automate?

Platform account steps that verify identity: the tax interview, banking details for royalty deposits, and two-step verification. These require the operator's own credentials and are one-time manual sessions. The right response is not to fight them but to build everything else in parallel so they are the only thing left.

— Italo Campilii. If you're building something that needs this kind of operator, get in touch.