DEV Community: Vinícius Ramos

My build in public journey: creating an Ebook generator

Vinícius Ramos — Fri, 17 Jul 2026 22:46:40 +0000

I once spent three weekends writing a single ebook for my Python course. Last month, my product (Ebookr.ai) generated a better one in about fifteen minutes, while I was making coffee. This is the story of the gap between those two sentences.

The problem that started everything

I run Jornada Python, a Python course for Brazilian devs. Ebooks are great assets for a course business: lead magnets, bonus material, complementary content. Students love them.

The problem: I hated making them.

Writing was slow. Formatting was slower. And I am the kind of person who notices when a heading is 2px off, which turns "quick formatting pass" into a lost evening.

When ChatGPT showed up, I thought I was saved. Narrator voice: he was not. 🙃

The text got faster, sure. But an ebook is not text. It is text plus a cover plus images plus infographics plus layout plus a PDF that does not break in hilarious ways. So my workflow became: generate text in one tab, make a cover in another tool, hunt stock images in a third, assemble everything in a design tool, export, find a table sliced in half between pages, cry, repeat. The result of all that gluing looked like a ransom note with chapters.

That pain felt very automatable. So I built Ebookr.ai.

How it works

The core is a multi-agent pipeline. Instead of one giant prompt praying for a miracle, there are six specialized agents, each with one job:

an Architect that turns an idea into a structured outline
a Writer that produces each section
a Coder for technical ebooks (code samples that actually run)
a QA agent that reviews content and can reject it with feedback
an Infographic agent that turns key points into visuals
a Layout Designer that assigns each page a template archetype

The PDF part is where I lost some hair. My first version used Markdown to Pandoc to WeasyPrint, which works right up until you want magazine-style layouts. The current version renders Jinja2 templates in headless Chromium via Playwright, with a custom pagination engine deciding where pages break. Yes, I wrote a pagination engine in 2026. No, I do not want to talk about it. (I do. Ask me anything.)

The stack

Boring on purpose: Django 5 and Python 3.11, Celery with Redis for all the heavy async work, Postgres with pgvector, LangChain and LangGraph orchestrating the agents, OpenAI models behind it, Playwright for PDF rendering, Stripe for billing, Cloudflare R2 for storage.

The most exotic thing here is the agent orchestration. Everything else is the stack you would pick for a normal SaaS, because 90% of an AI product is a normal SaaS.

Things that broke (a selection)

Chromium ate my server. Concurrent PDF renders of 100-page ebooks with embedded images took down the web workers via the kernel OOM killer. Fix: a dedicated Celery queue with concurrency of exactly 1 and a hard memory limit. Humbling.
Walking tables. Tables that straddled a page break would either vanish or duplicate. The pagination engine now knows how to split tables, lists and quotes across pages like a civilized adult.
The preview that shared too much. My free preview was quietly mounting the entire ebook client-side, including the paid chapters. Found it, fixed it in four layers, wrote a tripwire test so it can never come back. Build in public also means confessing in public.
Editor performance. A 70+ page ebook made the in-browser editor melt. Profiling sessions brought CPU time from 12s to under 5s. The culprit was a decorative noise texture being regenerated per page. Design has a price.

Claude as my AI companion developer

I build almost everything using Claude Code sessions. Not as an autocomplete, more like a colleague with unlimited patience: it reads the codebase, follows the project's rule file, writes the tests, and pushes back when I ask for something that contradicts a business rule we defined earlier. Being corrected by your own tooling is a strange kind of pride.

The workflow that emerged: I describe intent and constraints, Claude proposes and implements, tests gate everything, and I review like a slightly paranoid tech lead. Solo founder, but it rarely feels solo.

Then I gave it a second job: marketing manager

This is my favorite part. I am a developer; ads dashboards scare me more than segfaults. So I set up a dedicated marketing agent: its own instructions file, its own subagents (data analyst, CRO specialist, copywriter), and read-only access to everything that matters: Google Ads, GA4, Search Console, Microsoft Clarity and Stripe through MCP connectors, plus the production database through an SSH tunnel with a read-only role.

Every day it cross-checks ad spend against real signups and real revenue (never trusting the ad platform's own numbers), and ends every report with three prioritized actions, what NOT to do, and what data is missing.

Why an agent instead of an agency? Because I hired an agency first. What the agent found while auditing my accounts deserves its own horror anthology 🕵️:

their campaign report celebrated "132 trial starts". The product has never had a trial. The event fired when someone merely visited the signup page.
the real number for that same campaign, straight from my database: 1 subscription for about 115 dollars spent.
my Meta Business Manager contained assets from a completely different client of theirs, receiving live events.
and my own site was carrying a Meta pixel that belonged to no account I own, quietly shipping my visitors' data somewhere I could not see.

The agent surfaced all of this in one afternoon of cross-checking, then we rebuilt the tracking from scratch. The agency is gone. The agent stays.

Guardrails matter: it can read everything, it can change nothing. Every mutation goes through me. An autonomous agent with write access to your ad account is a horror movie pitch.

First numbers, honestly

Build in public without numbers is just marketing, so here goes:

10 paying subscribers, about 120 dollars in MRR (it's charged in BRL - for now. i18n in development)
retention is the bright spot: 2 cancellations ever, most subscribers renew
organic visitors convert to paid at around 11%; cold paid traffic so far: under 1%, and I am publicly fighting that funnel right now
cost per signup from search ads: about 60 cents

Tiny numbers. But they are mine, they are real, and the unit economics work. The current battle is conversion, not the product, and that battle is being fought with session recordings, funnel instrumentation and a lot of stubbornness.

What's next

The product is Portuguese-only today; the English version is fully built and waiting behind a feature flag while I finish the boring parts (legal review, USD pricing). If you read this far and want to see it anyway: ebookr.ai. The pricing page is in Portuguese, but numbers are numbers. 😄

Como criar Middlewares customizados no Django

Vinícius Ramos — Wed, 08 Mar 2023 21:58:22 +0000

Fala Dev! Na paz?!

Nesse meu primeiro post aqui na Dev.to você vai aprender a criar Middlewares no Django, que são trechos de código para tratamento prévio ou posterior de requisições que chegam e saem do seu sistema Django.

Ficou confuso? Então bora nessa! 😉

O que são Middlewares

Middlewares vivem na Camada View do framework Web Django (que também é composto pela Camada Model e pela Camada Template)

Middlewares são trechos de códigos que podem ser executados antes ou depois do processamento de requisições/respostas pelo Django.

É uma forma que os desenvolvedores, nós, temos para alterar como o Django processa algum dado de entrada ou de saída.

Se você olhar no arquivo settings.py, nós temos a lista MIDDLEWARE com diversos middlewares pré-configurados:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

Por exemplo, o middleware AuthenticationMiddleware é reponsável por adicionar a variável user a todas as requisições.

Dessa forma, você pode, por exemplo, mostrar o usuário logado no seu template:

<li>
    <a href="/alguma/url">Olá, {{ user.email }}</a>
</li>

Vamos ver agora o ciclo de vida de um Middleware dentro do Django.

Ciclo de vida de um Middleware no Django

Um middleware é um método callable (que implementa o método __call__()).

Esse método recebe uma requisição e retorna uma resposta, assim como uma View, podendo ser escrito como função ou como Classe.

Um exemplo de middleware escrito como função é:

def middleware_simples(get_response):
    # Código de inicialização do Middleware
    def middleware(request):
        # Aqui vai o código a ser executado antes 
        # da View e de outros middlewares
        # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

        response = get_response(request)

        # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        # Aqui vai o código a ser executado 
        # para cada resposta após a View 

        return response

    return middleware

E como Classe:

class MiddlewareSimples:
    def __init__(self, get_response):
        self.get_response = get_response
        # Código de inicialização do Middleware

    def __call__(self, request):
        # Aqui vai o código a ser executado antes 
        # da View e de outros middlewares
        # vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

        response = self.get_response(request)

        # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        # Aqui vai o código a ser executado 
        # para cada resposta após a View         

        return response

Como cada Middleware é executado de maneira encadeada, do topo da configuração MIDDLEWARE (do settings.py) para o fim, a saída de um é a entrada do próximo.

O método get_response() pode ser a própria View, caso ela seja a última configurada no MIDDLEWARE do settings.py, ou o próximo middleware da cadeia.

Utilizando a construção do middleware via Classe, nós temos três métodos importantes:

O método `process_view`

👉 Assinatura: process_view(request, func, args, kwargs)

Esse método é chamado logo antes do Django executar a View que vai processar a requisição e possui os seguintes parâmetros:

request é o objeto HttpRequest.
func é a própria view que o Django está para chamar ao final da cadeia de middlewares.
args é a lista de parâmetros posicionais que serão passados à view.
kwargs é o dict contendo os argumentos nomeados (keyword arguments) que serão passados à view.

Esse método deve retornar None ou um objeto HttpResponse:

Caso retorne None, o Django entenderá que deve continuar a cadeia de Middlewares.
Caso retorne HttpResponse, o Django entenderá que a resposta está pronta para ser enviada de volta e não vai se preocupar em chamar o resto da cadeia de Middlewares, nem a view que iria processar a requisição.

O método `process_exception`

👉 Assinatura: process_exception(request, exception)

Esse método é chamada quando uma view lança uma exceção e deve retornar ou None ou HttpResponse. Caso retorne um objeto HttpResponse, o Django irá aplicar o middleware de resposta e o de template, retornando a requisição ao browser.

request é o objeto HttpRequest
exception é a exceção propriamente dita lançada pela view (Exception).

O método `process_template_response`

👉 Assinatura: process_template_response(request, response)

Esse método é chamado logo após a view ter terminado sua execução, caso a resposta tenha uma chamada ao método render() indicando que a reposta possui um template.

Possui os seguintes parâmetros:

request é um objeto HttpRequest.
response é o objeto TemplateResponse retornado pela view ou por outro middleware.

Agora vamos criar um middleware um pouco mais complexo para exemplificar o que foi dito aqui!

Criando um Middleware no Django

Vamos supor que queremos um middleware que filtre requisições e só processe aquelas que venham de uma determinada lista de IP's.

O que precisamos fazer é abrir o cabeçalho de todas as requisições que chegam no nosso servidor e verificar se o IP de origem bate com a nossa lista de IP's.

Para isso, colocamos a lógica no método process_view, da seguinte forma:

class FiltraIPMiddleware:    

  def __init__(self, get_response=None):
    self.get_response = get_response

  def __call__(self, request):
    response = self.get_response(request)

    return response

  def process_view(request, func, args, kwargs):
    # Lista de IPs autorizados
    ips_autorizados = ['127.0.0.1']

    # IP do usuário
    ip = request.META.get('REMOTE_ADDR')

    # Verifica se o IP do cliente está na lista de IPs autorizados
    if ip not in ips_autorizados:
      # Se usuário não autorizado > HTTP 403: Não Autorizado
      return HttpResponseForbidden("IP não autorizado")

    # Se for autorizado, não fazemos nada
    return None

Depois disso, precisamos registrar nosso middleware no arquivo de configurações settings.py (na configuração MIDDLEWARE):

MIDDLEWARE = [
  # Middlewares do próprio Django
  'django.middleware.security.SecurityMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.common.CommonMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  'django.middleware.clickjacking.XFrameOptionsMiddleware',

  # Nosso Middleware
  'helloworld.middlewares.FiltraIPMiddleware',
]

Agora, podemos testar seu funcionamento alterando a lista ips_autorizados:

Coloque ips_autorizados = ['127.0.0.1'] e tente acessar alguma URL da nossa aplicação: devemos conseguir acessar normalmente nossa aplicação, pois como estamos executando o servidor localmente, nosso IP será 127.0.0.1 e, portanto, passaremos no teste.
Coloque ips_autorizados = [] e tente acessar alguma URL da nossa aplicação: deve aparecer a mensagem de "IP não autorizado", pois nosso IP (127.0.0.1) não está autorizado a acessar o servidor.

Conclusão

Nesse primeiro post quis trazer como é simples criar Middlewares no Django.

Você viu como podemos adicionar tratamento prévio ao processamento de requisições e posterior ao processamento de respostas.

Seus casos de uso são bem específicos, contudo é bom saber que temos essa possibilidade!

É isso dev, nos vemos na próxima! 😉