AI Actually Saved Me During the KDP Publishing Process
Last time I ended on a sour note, saying that “editing in Japanese turned out to only make things a little easier.” This time I’ll swing the pendulum back properly. In the practical work of getting the book out on Kindle (KDP), generative AI genuinely saved me.
Same AI, so why did it land so differently? That’s what this post is about.
Actually, this was my second time with KDP
I’ll confess: publishing on KDP wasn’t my first time. I’d done it once before, a long time ago.
But that past experience turned out to be no help at all. I’d long since forgotten the procedures, and more importantly, the specs and standards had completely changed in the meantime. EPUB conventions, paperback submission requirements, tax handling — all of it was a different world from back then. The knowledge I supposedly had as an “experienced” author turned out to be almost entirely useless.
…Thinking about it, this is a bit like my own protagonist, who gets thrown into the past with knowledge of the future but can’t fight with it as-is — I laughed wryly to myself as I wrote that. In the end, there’s no choice but to find the correct answer for this exact moment, over and over again. And that’s exactly where AI showed what it’s really capable of.
AI’s “effectiveness” was reversed between editing and publishing work
What didn’t work in the editing phase last time was judgment that ultimately depends on human sense — “is this Japanese acceptable or not.” The release work for KDP, on the other hand, is a completely different kind of task. The procedures are fixed, there’s a lot of research involved, and there are places you can get stuck — in other words, it’s centered on “the logistics and research needed to arrive at the correct answer.” This was AI’s home turf.
Where it specifically helped
① Building the EPUB conversion pipeline The manuscript was in Markdown. I converted it to EPUB using Pandoc, and having help working out the settings and command structure together was huge.
② Troubleshooting validation The entry point into this phase was a casual question: “Can I check EPUB validity with a smartphone app?” The answer that came back was that phones are fine for viewing but strict for validation, and a PC is safer before publishing. When I followed up with “I’m on a Mac, what should I use?”, the tools got sorted out by purpose.
- Use pagina EPUB-Checker / EPUBCheck (via Homebrew) to squash spec errors
- Use Kindle Previewer 3 to check how it looks on an actual device
- Use Denshi Lab Checker for Japanese-specific checks (characters outside the JIS range, tatechuyoko, etc.)
Being able to boil it down into a three-step flow — “① spec check → ② device preview → ③ KDP submission” — was huge. Every time an error came up, I got help sorting out what it was and how to fix it, and the time I would have spent wandering official documentation alone completely disappeared.
③ Administrative work around KDP – Understanding W-8BEN (a US tax document) – Designing the product description (up to 4,000 characters), keywords, and categories – Sorting out KDP Select (exclusive) vs. non-exclusive → In the end I went with a hybrid: KDP plus partial free release on Narou and Kakuyomu
④ The cover-making workflow I generated a base image with AI image generation (Nano Banana), then layered typography on top with Canva. This included help building prompts and bouncing around directions — AI accompanied me here too. Though with this cover, it wasn’t just a matter of “being helped” by AI. I went through quite a bit of conflict, and thought seriously about copyright. I’ll write about that in depth next time.
What actually helped me most was the paper edition
I’d originally intended to release only an ebook, but greed got the better of me and I made a paperback edition too. And this was the area where, if I’d been on my own, I would have completely broken down.
- Cover submission data: KDP demands, down to the millimeter, a “wraparound cover” where the front, back, and spine are joined into a single sheet. I built this typesetting from scratch in Python (PIL).
- Trim-size wandering: I initially tried a shinsho-size format, which didn’t suit horizontal text and I gave up on it, then B6, and finally settled on A5. I learned that KDP’s print cost is determined by page count and ink, and A5, which lets you fit more characters per page, ended up being the cheapest.
- A battle with a mysterious error: When I typeset the body text with Pandoc + LuaLaTeX, long strings of alphabetic characters from player names and club names caused lines to overflow (overfull). I squashed these one by one, stretching
\emergencystretchand enabling English hyphenation. - Down to designing the spine text and handling line-start punctuation restrictions (making sure punctuation marks don’t fall at the start of a line) in the back-cover description.
It was exactly this kind of work — unglamorous, technical, the kind where getting stuck eats a whole night — where running alongside AI made an overwhelming difference. I knew what I wanted to do, but couldn’t move forward because I didn’t know the conventions, and AI closed that gap in one stroke. This is a completely different kind of effectiveness from “the quality of the Japanese” last time.
The final boss was “page count equals cost”
Once I’d finished stamping out the typesetting problems, the last thing standing in my way was print cost. Roughly speaking, KDP paperback cost goes up as page count increases. If I could shave off another dozen-odd pages, the cost would drop a tier, and so began the final battle over a few dollars.
The line spacing was already at its limit. Tighten it any further and the reading experience would break. That’s when I noticed the “airiness” of web-novel style. The way of writing that breaks into a new paragraph for every line of dialogue or every description turns, on paper, into nearly ten thousand “gaps between paragraphs,” each one adding whitespace that was quietly devouring pages.
What worked here was, instead of having AI calculate on paper, repeatedly doing “actually typeset it and count” over and over. The conclusion I arrived at was a little shocking: without touching the line spacing by even a millimeter, just tightening the space between paragraphs cut the page count by more than 30%. In short, it amounted to shifting toward the typesetting Japanese paperbacks (bunko) have long used — indentation only, no blank lines. Combined with reconsidering the trim size, the paper book, which had originally run to nearly 550 pages, was ultimately compressed down to the 210s, less than half.
One thing that mattered more than it might seem was that I’d kept the typesetting builds for the ebook (EPUB) and the paper edition (PDF) separate from the start. Thanks to that, the typesetting I’d packed tight for the sake of print cost didn’t damage the ebook’s reading experience at all. The optimal typesetting changes depending on the medium. That’s a lesson that got driven into my bones from putting out one book.
So where does AI actually work, and where doesn’t it?
Having written this across posts three and four now, here’s my own conclusion.
- The core of the work (quality of the Japanese, creative judgment) … ultimately human. AI stops at “making it a bit easier.”
- The hassle surrounding that core (logistics, research, conversion, troubleshooting) … here, AI is overwhelmingly fast.
In other words, AI showed what it’s really capable of not in “the story itself” but in “the road to getting the story out into the world.” That’s the feeling that clicked into place for me most, having put out one book.
Next time: the story of how that cover came to be. I’ll write about the conflict unique to an AI-generated cover, and the unavoidable copyright considerations.
Originally published in Japanese at https://clazytech.com/2026/06/1648/. Translated with LLM assistance and reviewed before publication.