I Got Tired of Manually Running My Ebook Publication, So I Automated It

Publishing an ebook sounds simple.

Write something useful, export a PDF, upload it somewhere, and you're done.

But if you want to run an actual publication, the book itself is only one part of the work.

You need to:

• Research useful topics
• Plan the publication
• Write and edit it
• Generate the PDF and cover
• Publish it
• Maintain a website
• Promote new publications
• Repeat everything for the next one

I started doing this manually.

Eventually I realized I wasn't building books anymore.

I was building a pipeline.

The workflow

The basic publishing process I wanted was:

Research → Generate → Review → Publish → Promote

Each step can remain independent.

That matters because I don't want an AI model blindly generating something and immediately throwing it onto the internet.

Automation should remove repetitive work, not remove judgment.

1. Research

Before generating anything, the system needs topics.

This can come from:

• Questions people repeatedly ask
• Communities in a particular niche
• Search trends
• Existing publications
• Problems that deserve a practical guide

AI can help organize and explore these ideas, but topic selection still benefits heavily from human judgment.

2. Generate the publication

For my implementation, I use Python and LangChain.

The generation pipeline takes a selected idea and builds a structured publication around it.

Instead of asking a model:

Write me a 50-page ebook.

the process is broken into smaller stages.

Topic → Outline → Chapters → Content → Editing → Final publication

This makes the pipeline much easier to control and modify.

AI is useful here, but I don't think it should be treated as the entire author.

A useful publication still needs human knowledge, examples, review, and editing.

3. Give the books their own home

Generating PDFs wasn't enough.

I wanted the publications to live somewhere that I controlled.

So I built a separate publication website where generated books can be displayed and managed.

That means I'm not limited to uploading random PDFs to different platforms.

The publication itself becomes a product.

You can see my implementation here:

https://vasukisquare.cc
https://swarajpuppalwar.gumroad.com/l/akxgjl

4. Automate the boring parts

This was the fun part.

I moved the recurring jobs into GitHub Actions.

The system can run scheduled workflows for things like:

• Researching publication ideas
• Generating publications
• Publishing content
• Preparing promotional content

Instead of remembering to execute everything manually, GitHub becomes the scheduler.

The overall pipeline becomes:

Research
   ↓
Generate
   ↓
Review / Publish
   ↓
Website
   ↓
Promotion

5. Distribution still matters

Automation doesn't magically create readers.

A publication can be reused as material for:

• Technical or educational blog posts
• DEV Community articles
• Instagram Reels
• YouTube Shorts
• Social posts
• Community discussions

One useful publication can therefore produce weeks of smaller educational content.

The important part is that those posts should provide value themselves.

Nobody wants to follow an account where every post says:

BUY MY BOOK.

So I packaged the system

I eventually separated what I built into two projects:

VasukiSquare

The Python + LangChain side responsible for research and publication generation.

VasukiPublication

The website and publishing side responsible for displaying and managing the publications.

Together with the GitHub Actions workflows, they form Vasuki.

It's still an early-stage developer project, not some magical one-click publishing company.

You'll need to understand environment variables, APIs, databases, deployment, and GitHub Actions if you want to customize it.

But that's also the point.

You get a system you can modify rather than another closed platform.

The bigger lesson

The interesting part of this project wasn't generating ebooks with AI.

It was realizing that a repetitive creative workflow could be represented as a pipeline.

Once you can describe your process as:

A → B → C → D

you can start asking a much more useful question:

Which parts actually require me, and which parts can the system handle?

That's what I wanted Vasuki to explore.

If you want to see the publication running:

https://vasukisquare.cc
https://swarajpuppalwar.gumroad.com/l/akxgjl

And if you're interested in the Vasuki source code, comment VASUKI and I'll send you the link.

I'd also love to hear how you would structure a publishing pipeline differently.