The book you're reading about was written by the pipeline that produced it. That's not a marketing line — it's the only honest way to describe what happened. The ebook teaches Python automation. The pipeline that created it is Python automation. If the pipeline worked, the book is proof. If the book is wrong, so is the pipeline.
That recursive test is what made this worth building.
What I Built
The core is a state machine. Every chapter moves through four states: PENDING → RUNNING → DONE → NEEDS_REVIEW. Each transition gets logged to a SQLite database before anything else happens. The reason: LLM calls are expensive, slow, and non-deterministic. If the process crashes at chapter 7 out of 10, you do not want to regenerate chapters 1 through 6.
Crash recovery was not a nice-to-have. It was required after the first real run died halfway through on a network timeout and I realized I had no way to resume without reprocessing everything.
Here is what a typical pipeline run looked like in the terminal:
[2025-03-14 09:12:04] pipeline INFO Starting pipeline run — 10 chapters queued
[2025-03-14 09:12:05] ch_01 INFO State: PENDING → RUNNING
[2025-03-14 09:14:31] ch_01 INFO Content generated — 2,187 words
[2025-03-14 09:14:32] ch_01 INFO AST validation: PASS (3 code blocks, 0 errors)
[2025-03-14 09:14:33] ch_01 INFO Subprocess test: PASS (all scripts executed)
[2025-03-14 09:14:33] ch_01 INFO State: RUNNING → DONE
[2025-03-14 09:14:34] ch_02 INFO State: PENDING → RUNNING
...
[2025-03-14 13:47:09] pipeline INFO All chapters DONE — beginning EPUB compilation
[2025-03-14 13:47:44] pipeline INFO English EPUB: build/output_en.epub (1.2 MB)
[2025-03-14 13:52:18] pipeline INFO Spanish EPUB: build/output_es.epub (1.3 MB)
[2025-03-14 13:52:19] pipeline INFO Run complete — 4h 35m elapsed
The pipeline ran. Then it ran again when I changed the chapter structure. Then again when the translation QA caught ratio errors. The state machine meant each re-run only touched what actually needed to change.
The Actual Output
Ten chapters. Approximately 22,000 words total. The subject matter is Python automation for developers — file handling, subprocess management, API wrappers, CLI tools, testing patterns.
Each chapter shipped with at least one complete Python script. Ten scripts in total, all of them validated two ways before they made it into the manuscript:
-
AST validation — Python's
ast.parse()confirmed the code was syntactically valid. This caught the hallucinated syntax errors before they became the reader's problem. - Subprocess testing — every script was actually executed in an isolated environment. Output was checked for exceptions and non-zero exit codes.
The book exists in two languages: English and Spanish. Translation was not a one-pass operation. A semantic QA step compared word ratios, checked that code blocks were preserved exactly, and flagged any chapter where the translation diverged structurally from the source. The first attempt failed that QA check on three chapters. The second pass passed all of them.
Cover image was generated with Imagen 4. One prompt, several iterations, final selection. The cover in the published version is the one that came out of that process.
Total active work time to get from blank project to two published EPUBs: 4 to 6 hours spread across about two weeks. Most of that time was debugging the pipeline itself, not writing content.
The Cost
This is the part people usually obscure. Here is the full accounting:
| Tool | Cost |
|---|---|
| Claude Code Pro | $20/month |
| Gumroad | Free (revenue share on sales) |
| KDP | Free (royalty share on sales) |
| Python, SQLite, Pandoc | Free |
| Everything else | Free |
One paid tool. Twenty dollars a month. That is the entire infrastructure cost.
Break-even is two sales at $19.99. The math is not complicated.
What Was Hard
Three things caused real problems:
LLM hallucinating code that does not compile. This happened more than expected. The model would generate a function that looked plausible in prose context but would throw a SyntaxError or reference a variable that was never defined. The AST validation step was built specifically because of this. Without it, bad code would have shipped inside chapters that looked fine in a document preview.
Crashes mid-pipeline. The first full run died on a network timeout after generating chapter 4. Without state persistence, that meant starting over. After implementing the SQLite state machine, subsequent crashes recovered by reading existing state and picking up from the last RUNNING chapter. This should have been designed in from the start. It was not.
Translation quality drifting from source structure. The first Spanish translation pass was technically fluent but structurally inconsistent. Some chapters had word counts that were disproportionately shorter or longer than the English versions. More importantly, a few code examples had been partially paraphrased in the surrounding explanation — acceptable for natural language, not acceptable for technical instructions where precision matters. The QA layer was added after that first pass failed inspection. The second pass was clean.
None of these problems were surprising in retrospect. They were all predictable failure modes of using an LLM in a production pipeline. The engineering response to each was straightforward. The time cost was real.
Was It Worth It?
The pipeline exists. The book exists. Two EPUBs in two languages, validated code, cover image, published on Gumroad and KDP. That part worked.
Whether it was worth it depends on a question I cannot answer yet: whether developers find the content useful enough to pay for it. The pipeline produced something real. The market will determine if it produced something valuable.
If you want to evaluate it directly: Python Automation for Developers is available on Gumroad for $19.99. There is a 30-day refund policy. If you buy it and the code does not work or the content does not deliver value, you can get your money back.
That is the only honest pitch I can make.
What Is Next
Book 2 is already in planning. Same pipeline. Different subject matter. The system is the asset — the pipeline generalizes to any technical content that can be structured as chapters with embedded, testable code.
The first run proved the pipeline worked. The second run will prove it was repeatable. If the output from book 2 is structurally similar in quality to book 1, that is the more interesting result: not that I built a thing, but that the thing scales.
That is the actual experiment. The book was just the first data point.
📋 Free resource: AI Publishing Checklist — 7 steps to ship a technical ebook with Python (free PDF)
Full pipeline + 10 scripts: germy5.gumroad.com/l/xhxkzz — $12.99 launch price
