A Guide to Your First Publication

Publishing a book can be an arduous ordeal. There are so many moving parts that it can be difficult to keep track of them all, and most of them only reveal themselves once you're already in the middle of the process. I'm hoping this post can act as an aid on that journey.

It covers the journey to publication itself, not what you publish; that part is left to your discretion. Where the advice leans on structure and argument it assumes non-fiction, so if you're writing fiction, take the planning sections loosely. The road runs roughly like this: choose where to write, lay out the workspace, plan the book, settle on a style, typeset, proof the pages, make the cover, pick your formats and platforms, set up the listings, and launch. There's an optional section at the end on using AI along the way, but nothing before it assumes you will.

#Where to Write

The first decision is where the words live while you write them. The usual options:

• Word or Google Docs. Familiar, and fine for getting words down. Formatting for print is where they start to fight you, and keeping track of revisions usually means a folder of files named final, final-2 and final-actually.
• A plain text editor. Notepad and its cousins keep you focused on the words, with no formatting at all, which is both the appeal and the limit.
• Reedsy Studio. A free browser app that typesets as you write and exports an EPUB and a print-ready PDF. In my opinion it sits between the document options above and the setup I recommend below. Its limitation is customisation: you pick from a handful of templates instead of controlling the layout yourself.
• LaTeX. Superior in print to everything above. You don't have to write in it, though. Tools like Galley and Pandoc can compile Markdown into LaTeX and typeset it for you, which I'll come back to.

My recommendation is an Obsidian vault, a Git repository, or both together, since a vault can sit inside a repo quite happily. Both keep your writing as Markdown, plain text files with light formatting marks, which open anywhere, never lock you into one program, and feed every typesetting tool later in the process. Version control is the real gain. With Git, every change you commit is kept, so you can pull up an older draft and compare it with the current one, without the old habit of saving several revisions to disk and trying to remember which was which.

You can keep one vault or repo per book, or a single one for all your books. If you plan on prequels, sequels or related works, the single one is much cleaner, because related content sits side by side and you can refer across books without hunting.

#Laying Out the Workspace

Inside the vault, a little structure goes a long way:

• One document per chapter. Chapters are easier to move, review and compile when each is its own file.
• A separate location for sources. Collate references, quotes and notes on where claims came from in one place, so you aren't digging through chapters for them later.
• A separate folder for drafting notes and assets. Scraps, outlines, figures and images live here, away from the prose.
• A plan file. One document per book that acts as its single source of truth: the argument, the chapter list, and every decision made along the way, with the reason for it.

Something like this:

#Plan Before You Write

Plan the book before you write it. For non-fiction especially, the plan is what holds the final publication together, so readers can follow the argument from the first chapter to the last without wondering how they got there.

A good plan does more than one job. Its chapter list becomes the files in your workspace and, later, the table of contents, so all three come from a single decision. It's also where you record what you decided and why, so that three months in, when you're tempted to change something, you can see what you'd be undoing. And if the book belongs to a series, decide where each case or example first lives. Later books can refer back to it, but never forward, since a reader may not have the later book, and it may never get written.

#One Coherent Style

Decide on a single, coherent style before the book gets long, because changing it later means touching every chapter. The decisions worth making early:

• Chapter openings. Do chapters open on the right-hand page only, as most printed books do, or on either side? Right-hand-only openings add blank pages, which raises the page count, which changes the print cost and the width of the spine, so this choice reaches all the way to the cover.
• Chapter starts. Does each chapter start on its own page, or does the prose follow straight on from the previous one?
• Notes. Footnotes, endnotes, or a collated appendix?
• Figures. If you have them, settle their styling and design once, so they look like they belong to the same book.
• Trim size, typeface and type size. The physical page, and what's set on it.
• Colour or black and white. A colour interior costs considerably more to print.
• Front and back matter. Title page, copyright page, dedication, preface, and whatever follows the final chapter.

#Figure Placement

A figure doesn't have to follow directly after the paragraph that mentions it. Pushing it a paragraph or two down can help consolidate pages, avoiding half-empty pages and awkward gaps where a figure didn't fit. To make that work, refer to figures by number ("see Figure 3.2") rather than "below" or "the following figure", so the text still reads correctly wherever the figure lands. LaTeX already works this way: figures are floats, and the typesetter moves them to where they fit.

#Equations

If your book contains equations, use inline maths sparingly and display equations wherever possible. This is first a readability concern. Eyes move through prose quickly, and they stall at an equation too complex for the line it sits in. Inline, an average has to be squeezed into something like , while displayed it can take its full form:

The reader takes it in whole and picks the prose back up cleanly. It's also a layout concern. Tall inline maths pushes lines apart, leaves uneven spacing in the paragraph and breaks awkwardly at line ends, while displayed equations sit on their own line and can be numbered and referred back to. One caveat: on a narrow trim, long displays overflow the text block, so split them across lines.

#Table of Contents Depth

The table of contents matters most in digital editions, where readers use it to jump between chapters. I'd recommend a depth of 1 or 2: chapter titles only, or chapters plus their main sections. Anything deeper and the contents start to become a second book.

Be careful with the numbers, because tools count differently. In Pandoc and Word, depth 1 means the top level of heading, so if your chapters are top-level headings, depth 1 is chapter titles only. LaTeX numbers chapters as level 0 and sections as level 1, so a tocdepth of 1 there gives you chapters and sections, and chapters only is 0. Decide what you want readers to see, then set whichever number your tool needs to show it.

#Typesetting

Typesetting is where the manuscript becomes pages. You can write LaTeX directly, or write Markdown and let a tool convert it. Pandoc is the long-standing general-purpose converter. Galley is aimed squarely at this workflow: it compiles Markdown to LaTeX in your browser, ships KDP trim sizes and margins, and sets the gutter from your expected page count. In project mode it's opinionated, following the workflow this guide sets out, and it compiles the whole book with a single click at any moment, so you can preview the final typeset document whenever you like.

That matters more than it sounds. Typesetting doesn't have to wait until the end. If you can see real pages while you write, you can check the style decisions above as you make them, and catch the figure that won't sit, the chapter opening on the wrong side, or the page count creeping past what you budgeted for, long before any of it becomes expensive.

#Proofing the Pages

Proofread the typeset PDF, not just the draft. The draft tells you whether the words are right; the pages tell you whether the book is. A page pass catches what only shows up once text is set: widows and orphans (single lines stranded at the top or bottom of a page), stray blank pages, figures landing in the wrong place, and headings left at the foot of a page with their text overleaf.

#The Cover Comes Last

Make the cover once the interior is locked. A print cover wraps around the spine, and the spine's width depends on the final page count and paper. Every change to the interior that moves the page count moves the spine, so finish the inside first.

#Formats

Paperback, hardcover and ebook are the usual three, and you don't have to offer all of them. Page count decides some of this for you. Print formats have minimum page counts, so a short book may only work as an ebook, and hardcovers generally need more pages than paperbacks. Check each platform's current limits before you decide.

#Where to Publish

KDP is the obvious starting point, but it's one option among several, and they can be combined.

Print quality differs between providers too. In my experience, KDP's print is superior. If you print through more than one, order a proof copy from each and compare the paper, colour and binding before committing.

#Know the Limits Before You Commit

Some choices close doors. The biggest is KDP Select. Enrolling your Kindle ebook gives you Kindle Unlimited and Amazon's promotion tools, and in exchange the ebook becomes exclusive to Amazon, in 90-day terms that renew automatically unless you turn renewal off. While it's enrolled, you can't distribute the ebook anywhere else: not on Apple, Kobo or Google Play, not through an aggregator like Draft2Digital, and not on your own website. Only the ebook is covered; print editions and audiobooks are free to go elsewhere.

ISBNs are the other. KDP, Draft2Digital and IngramSpark will each give you one for free (IngramSpark's free ISBNs are for US accounts), but a free ISBN is tied to the platform that issued it. To sell the same edition through more than one platform, you'll need your own, from your country's ISBN agency (Nielsen in the UK and Ireland, Bowker in the US).

#Setting Up the Listing

Each platform asks for roughly the same details: ISBN, title and subtitle, author name, description, keywords, categories and price. Work out pricing from the print cost, which depends on page count, trim, paper and colour, then add what you want to earn on each copy. KDP also asks whether your book contains AI-generated content; answer it honestly, whichever way it goes. And double-check the author name field before you submit. It's an easy one to get wrong and a tedious one to correct.

#Review, Proofs and Launch

Submission goes through a review before the book goes live. Order a proof copy if you can, and read it in print. Things that looked fine on screen look different on paper, and it's far better that you find them than your readers.

After launch, a few things are worth setting up. On Amazon, A+ Content lets you add images and extended descriptions to the product page, and an author page gathers your books in one place. Your book will usually find its way onto Goodreads too, where you can claim your author profile.

#A Book Is a Fixed Edition

One last thought before the optional part. A printed book is a fixed edition. Unlike a blog post, you can't quietly update it once it's out, and even where a platform lets you upload a revised file, a large enough change counts as a new edition; KDP treats a page-count change of more than 10% that way. So write the book as though it can't be changed, because in the ways that matter it can't. Nothing in it should point to things that may change or may never exist: a sequel you haven't written, a website that may move, a theory you haven't finished testing.

#Using AI Along the Way (Optional)

Everything above works without AI. This section is for those who want its help, and it comes last so the rest of the guide stands on its own.

For solo publishers, AI can be a cheaper option. Not everyone can afford a professional editor or proofreader, and AI can cover part of that work for a fraction of the cost. Which model you use matters. The baseline is a large context window. It helps that a model can hold a whole manuscript, though handing it the whole thing at once is the wrong way to work with it. Give it a single chapter, or a small group of chapters, at a time, alongside your plan. The plan is what tells the model the rough context around the chapters it can't see. My personal recommendation is Claude Opus. I'd personally avoid Google Gemini; in my experience it can be a bit too sycophantic, and it may not correct you where you're wrong, which is exactly what you need it to do when drafting a factual publication. Models change between versions, so whichever you choose, test it: plant a few deliberate factual errors in a chapter and see which ones it catches. A model that agrees with everything isn't doing an editor's job.

#Start From the Plan

The detailed plan from earlier doubles as the AI's guardrail. Give it the plan alongside the chapters in hand whenever it reviews, proofreads or runs an editorial pass, so it checks the writing against your decisions (the argument, chapter order, style choices, terminology) instead of its own idea of what the book should be. I wrote about this effect in Guide Posts: models follow the constraints you set down for them, and the more detailed the plan, the less room there is to drift. It's one more reason to keep the plan up to date as decisions change.

#What It's Good For

• Proofreading: typos, repeated words, and spellings or terms that drift from your style choices.
• Checking against the plan: whether each chapter does what the plan says, the chapters are in order, and terms are defined before they're used.
• Typesetting help: explaining LaTeX errors, or writing the settings for your style decisions.
• Listing drafts: a first pass at the description, keyword ideas and categories, which you then rewrite in your own words.
• Flagging claims that need a source: useful for finding gaps, but check every reference yourself, since AI can invent citations.

#One Task per Session

This is the one I'd underline. Run each task in its own session: a proofreading session, then a separate page-pass session, then a separate review session. Asking an AI to do several at once gives poor results, for two reasons. Its attention is split, so each task gets done less thoroughly. And it fills the context window quickly, crowding it with material one task needs and another doesn't. Once the window is full, auto-compaction summarises earlier material to make room, which can dilute exactly what the current task depends on. I've covered context management in more depth in Late to the Game, Changed by It and Codifying Context. Finish one pass, review its changes, then start the next in a fresh session.

#Ground Rules

• Keep the writing yours. Light editing of your own draft keeps your voice; letting AI generate the prose tends to flatten it.
• Review every change through version control. This is where the Git repo from the start earns its keep: you can see exactly what was altered, and undo it.
• Disclose AI use where the platform asks, as KDP does during setup, and wherever your readers would want to know.

#A Sample CLAUDE.md

If you use Claude, a CLAUDE.md file at the root of your vault or repo gives it standing instructions for every session: what the book is, where things are, how work is done, what it may and may not do, and how to treat your voice. I've put together a sample CLAUDE.md you can use as a base. Fill in the bracketed parts and delete whatever doesn't apply.

The section on the author's voice is the one worth the most time. List your own writing quirks there, the habits that make the prose yours, so the model leaves them in rather than smoothing them away. Other tools read their own equivalent file, and the same contents apply.

---

That's a lot of moving parts. Few of them are hard on their own; the hard part was always keeping track of them all, and that's what the plan, the vault and a single click to see your pages are for.