DEV Community: Cleber Lucas

Quita: How a Personal Problem Became a Real Product — and What I Learned Along the Way

Cleber Lucas — Mon, 22 Jun 2026 15:58:42 +0000

There's a piece of advice you hear constantly in the developer world: "build projects to learn." The problem is that most portfolio projects are born without a real pain behind them. And without real pain, there's no motivation to go deep, to solve the hard problem, to push through when things break.

Quita was born differently. It was born from a genuine need.

The Problem Nobody Solves Simply

I spent a few years carrying debt accumulated during a rougher phase of life. When I finally had the financial stability to deal with it, I went looking for answers — what exactly was outstanding, with whom, and what the law guaranteed me as a consumer.

What I found was a maze.

The information existed — in the Central Bank of Brazil, on the Consumidor.gov.br platform, in consumer protection legislation. But the path to accessing and using it was confusing enough to make anyone give up. Almost everything I found through searches pointed to law firms or paid consultancies. Services that charge to do something that, in theory, any citizen can do on their own.

I started thinking: if I — someone with access to information and some familiarity with technology — had difficulty navigating this, what happens to those who don't?

Brazil has decades of consumer debt history. Millions of people who can't renegotiate their debts not just because of lack of money, but because of lack of clear guidance on what to do, where to start, and what rights they have.

That's when Quita started making sense.

What Quita Is

Quita is a digital assistant built for the indebted citizen.

It guides users from obtaining their financial reports from the Central Bank of Brazil — the Registrato, a document that consolidates all debts registered in the financial system — all the way to generating structured complaints for Consumidor.gov.br, the platform where financial institutions are legally required to respond.

The core flow is:

The user uploads their Registrato PDF
The system automatically extracts the debts listed in the document
Insights are generated about the debt situation — amounts, institutions, current status
Based on this data, Quita uses AI to produce a well-founded regulatory complaint, ready to be submitted to the responsible institution The goal isn't to solve the debt for the user. It's to give them clear information and a concrete instrument to exercise their rights on their own terms.

The Tech Stack

The project was built with a modern, deliberately lean stack focused on productivity and reliability.

Backend

Java 21
Spring Boot 4
Spring Security with JWT authentication
PostgreSQL
Flyway (database migrations)
Maven Frontend
Next.js
React
TypeScript
Tailwind CSS
Framer Motion Artificial Intelligence
Google Gemini (regulatory complaint generation)
OpenAI (fallback layer and experimentation) Infrastructure
Railway (backend and database hosting)
Vercel (frontend hosting — in deployment) Payments
Mercado Pago Other
PDF extraction and processing

- LGPD compliance: the PDF is processed in memory and deleted after extraction

The Approach That Changed Everything: Specification-Driven Development

If there's one technical lesson I want to highlight from this journey, it's not about any particular technology.

It's about process.

Most of Quita was built through SDDs — Software Design Documents. Before writing any line of code, I wrote the intent. I defined what the system should do, why, what the constraints were, the flows, the expected behaviors at the edges.

This habit transformed the quality of what I built.

When you specify before you implement, the questions that surface are different. You start asking about the user, about risks, about what happens when something goes wrong. You find ambiguities before they become bugs.

AI entered this process not as a code generator, but as an analysis partner. I would present a specification and question it together: is this clear? Is there a case I haven't covered? Does this decision make sense given this context?

In many moments, the work was more about thinking than programming.

What's Working in Production Today

The backend is live on Railway. All core features have been validated end-to-end:

User registration and JWT authentication
Registrato PDF upload and processing
Automatic debt extraction
Insight generation
AI-powered complaint generation via Gemini
Complaint export as PDF The frontend is in its final integration phase, with deployment planned on Vercel.

What's Coming Next

The next delivery is the first functional public version — with a complete web interface, full integration with the production backend, and the complete flow accessible to real users.

After that, the roadmap includes:

Guided onboarding for new users
Expanded support for additional document types
Refinement of the complaint generation model

- Exploring monetization viability

What This Project Taught Me

Fictional projects teach syntax. Real projects teach you to think like an engineer.

The difference is in the pressure a real problem creates. When you know there's someone on the other side who can be helped, every decision carries weight. You don't skip steps. You don't accept a solution that only works on the happy path.

And perhaps the most honest lesson from this journey is that AI doesn't replace software engineering. It amplifies it. When you know what you want to build, when you have clarity about the problem, AI accelerates. When you don't, it just generates confusion faster.

Quita isn't finished yet. But it's closer than ever.

And it was built to solve a real problem, with real technology, for real people.

Quita: como um problema pessoal virou um produto real — e o que aprendi no caminho

Cleber Lucas — Mon, 22 Jun 2026 15:49:55 +0000

Tem uma frase que ouço muito no mundo do desenvolvimento: "construa projetos para aprender". O problema é que a maioria dos projetos de portfólio nasce sem uma dor real por trás. E sem dor real, falta motivação para ir fundo, para resolver o problema difícil, para não desistir quando trava.

O Quita nasceu diferente. Nasceu de uma necessidade verdadeira.

O problema que ninguém resolve de forma simples

Passei alguns anos com dívidas acumuladas de uma fase mais turbulenta da vida. Quando finalmente tive condição financeira de resolver isso, fui atrás de entender o que estava em aberto, com quem, e o que a lei me garantia como consumidor.

O que encontrei foi um labirinto.

As informações existiam — no Banco Central, no Consumidor.gov.br, na legislação. Mas o caminho para acessá-las e usá-las era confuso o suficiente para fazer qualquer pessoa desistir. Quase tudo que encontrava nas buscas levava para escritórios de advocacia ou consultorias pagas. Serviços que cobram para fazer algo que, em tese, o próprio cidadão pode fazer sozinho.

Comecei a pensar: se eu, com acesso a informação e alguma familiaridade com tecnologia, tive dificuldade nisso, o que acontece com quem não tem?

O Brasil tem décadas de histórico de superendividamento. Milhões de pessoas que não conseguem renegociar suas dívidas não apenas por falta de dinheiro, mas por falta de orientação clara sobre o que fazer, por onde começar, quais direitos têm.

Foi aí que o Quita começou a fazer sentido.

O que é o Quita

O Quita é um assistente digital voltado para o cidadão endividado.

Ele guia o usuário desde a obtenção dos relatórios financeiros junto ao Banco Central — o Registrato, documento que consolida todas as dívidas registradas no sistema financeiro — até a geração de manifestações estruturadas para o Consumidor.gov.br, plataforma onde as instituições financeiras são legalmente obrigadas a responder.

O fluxo principal é:

O usuário faz upload do PDF do Registrato
O sistema extrai automaticamente as dívidas presentes no documento
São gerados insights sobre o endividamento — valores, instituições, situação
Com base nesses dados, o Quita produz, via IA, uma reclamação regulatória fundamentada, pronta para ser enviada à instituição responsável O objetivo não é resolver a dívida pelo usuário. É dar a ele informação clara e um instrumento concreto para exercer seus direitos por conta própria.

A stack técnica

O projeto foi construído com uma stack moderna e deliberadamente enxuta, com foco em produtividade e confiabilidade.

Backend

Java 21
Spring Boot 4
Spring Security com autenticação JWT
PostgreSQL
Flyway (migrations)
Maven Frontend
Next.js
TypeScript Inteligência Artificial
Google Gemini (geração de reclamações regulatórias)
OpenAI (camada de fallback e experimentação) Infraestrutura
Railway (hospedagem do backend e banco de dados)
Vercel (hospedagem do frontend — em implantação) Outros
Extração e processamento de PDFs

- Conformidade com LGPD: o PDF é processado em memória e removido após a extração

A abordagem que mudou tudo: desenvolvimento guiado por especificação

Se há um aprendizado técnico que quero destacar dessa jornada, não é sobre nenhuma tecnologia em particular.

É sobre processo.

Grande parte do Quita foi construída através de SDDs — Software Design Documents. Antes de escrever qualquer linha de código, eu escrevia a intenção. Definia o que o sistema deveria fazer, por quê, quais eram as restrições, os fluxos, os comportamentos esperados nas bordas.

Esse hábito transformou a qualidade do que eu construí.

Quando você especifica antes de implementar, as perguntas que surgem são diferentes. Você se pergunta sobre o usuário, sobre os riscos, sobre o que acontece quando algo dá errado. Você descobre ambiguidades antes que elas virem bugs.

A IA entrou nesse processo não como geradora de código, mas como parceira de análise. Eu apresentava uma especificação e questionava junto: isso está claro? Existe algum caso que não cobri? Essa decisão faz sentido dado esse contexto?

Em muitos momentos, o trabalho era mais pensar do que programar.

O que está funcionando hoje

O backend está em produção no Railway. Todas as funcionalidades do core foram validadas:

Cadastro e autenticação JWT
Upload e processamento do Registrato
Extração automática de dívidas
Geração de insights
Geração de reclamação via Gemini
Exportação da reclamação em PDF O frontend está em fase final de integração, com deploy previsto no Vercel.

O que vem pela frente

A próxima entrega é a primeira versão pública funcional — com interface web completa, integração com o backend em produção, e o fluxo completo acessível para usuários reais.

Depois disso, o plano inclui:

Onboarding guiado para novos usuários
Expansão dos tipos de documentos suportados
Refinamento do modelo de geração de reclamações

- Estudar a viabilidade de monetização

O que esse projeto me ensinou

Projetos fictícios ensinam sintaxe. Projetos reais ensinam a pensar como engenheiro.

A diferença está na pressão que um problema real cria. Quando você sabe que existe alguém do outro lado que pode ser ajudado, as decisões ganham peso. Você não pula etapas. Você não aceita uma solução que só funciona no caminho feliz.

E talvez o aprendizado mais honesto dessa jornada seja que IA não substitui engenharia de software. Ela amplifica. Quando você sabe o que quer construir, quando tem clareza sobre o problema, a IA acelera. Quando você não tem, ela só gera confusão mais rápido.

O Quita ainda não está pronto. Mas está mais próximo do que nunca.

E foi construído para resolver um problema real, com tecnologia real, para pessoas reais.

En:Building a RAG Agent for SOPs

Cleber Lucas — Tue, 09 Jun 2026 16:53:55 +0000

How I built a RAG agent to eliminate operational interruptions at work

Open source project using Python, LangChain, ChromaDB, FastAPI and Discord — from a real problem to production deployment.

Every company has a silent cycle that drains time without anyone noticing.

An employee has a question about a procedure. They can't find the answer in the documentation. They interrupt a more experienced colleague. That person stops what they're doing, answers, and goes back to work — focus already broken. Multiply that by 10, 20, 50 times a week.

Watching that pattern is what led me to build POPS AI: a RAG (Retrieval-Augmented Generation) agent capable of answering questions about a company's Standard Operating Procedures, directly through Discord or via a REST API.

The problem that motivated the project

The company had dozens of SOPs documented in PDF format. The problem wasn't a lack of documentation — it was the friction in accessing it. Nobody opens a network folder, hunts for the right file, and reads 15 pages just to answer a quick question.

The question I asked myself was simple: what if the documentation could answer questions on its own?

The architecture in three stages

The system works in three distinct phases, each with a clear responsibility.

1. Extraction

The extrair_texto.py script reads PDFs from the pops_originais/ folder, extracts the full text using PyMuPDF, and saves it as .txt. Page images are also extracted for future use.

import fitz  # PyMuPDF

def extract_text_from_pdf(pdf_path):
    doc = fitz.open(pdf_path)
    full_text = ""
    for page in doc:
        full_text += page.get_text()
    return full_text

Simple, but important: extraction quality determines response quality. Scanned PDFs without OCR are enemy number one here.

2. Embedding generation

With the extracted texts, gerar_embeddings.py splits the content into chunks using LangChain's RecursiveCharacterTextSplitter, generates the vectors, and persists them in ChromaDB.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200
)
chunks = splitter.split_text(text)

The chunk_overlap=200 was a deliberate choice: it ensures context isn't cut off abruptly between chunks, which visibly improved response coherence.

The project supports two embedding models via config.py:

Gemini models/embedding-001 — high quality, requires API key, cost scales with volume
Local SBERT (paraphrase-multilingual-mpnet-base-v2) — runs offline, great for avoiding costs or rate limits

This flexibility was one of the design decisions that added the most value, especially for anyone who wants to experiment with the project at zero cost.

3. Query (RAG)

When a user asks a question, the system:

Converts the question into a vector using the same embedding model
Searches for the most semantically similar chunks in ChromaDB
Builds a prompt with the retrieved excerpts as context
Sends it to Gemini 2.0 Flash to generate the final answer

results = collection.query(
    query_embeddings=[question_embedding],
    n_results=5
)

context = "\n\n".join(results['documents'][0])

prompt = f"""You are an assistant specialized in the company's SOPs.
Use only the information below to answer.

Context:
{context}

Question: {question}
"""

The interfaces: Discord and API

The project exposes the knowledge base in two ways.

Discord bot with slash commands:

/pop <question> — queries the vector database and returns the answer
/addpop <file.txt> — lets admins add new SOPs in real time, without reprocessing the entire base

FastAPI REST API with a POST /ask endpoint, designed for integration with other internal systems:

// Request
{ "question": "How do I configure the scanner on the Samsung printer?" }

// Response
{
  "answer": "To configure the scanner, follow these steps:\n1. Turn on the printer...\n[Source: SOP-ScannerSetup.txt]"
}

The challenge nobody talks about: token costs

Building the RAG was the fun part. The real challenge came after: how do you control costs in production?

A few decisions that made a real difference:

Using SBERT for embeddings instead of the Gemini API brings indexing cost down to zero — the model runs locally. Cost only occurs at response generation, which is where the actual value is.

Limiting n_results=5 in the vector search avoids passing unnecessary context to the model. More context = more tokens = more cost, without necessarily improving the answer.

Gemini 2.0 Flash was chosen intentionally over Pro: for objective questions about procedures, the quality difference is minimal while the cost difference is significant.

Deployment: one container, two processes

One decision that cost me a few hours was running the Discord bot and the FastAPI server in the same Docker container. The solution was Supervisor, which manages both processes in a lightweight, self-recovering way.

# supervisord.conf
[program:api]
command=uvicorn api_bot:app --host 0.0.0.0 --port 8000

[program:discord]
command=python bot_discord.py

autostart=true
autorestart=true

The result is a single, lightweight container that starts both services in parallel and automatically restarts either one if it fails. On an entry-level VPS, this matters a lot.

What I learned that wasn't in the plan

Chunking is an art. Chunk size and overlap affect response quality more than the model itself. I spent more time tuning this than anything else.

Security from day one. The .gitignore had to be configured before the first public commit to ensure no confidential company PDFs ended up in the repository. A mistake here is hard to undo.

The real problem wasn't technical. The most complex part was understanding what kind of questions users would actually ask and how to structure the SOPs so the model could retrieve the right information. Garbage in, garbage out applies twice as hard in RAG.

The project is open source

POPS AI is available on GitHub with a full README, .env.example, configured Docker Compose, and step-by-step setup instructions for both local and container-based deployment.

You can clone it, adapt it to your own knowledge base, and use it with your own documents — whether for SOPs, internal wikis, product manuals, or any PDF-based documentation.

🔗 github.com/obelucca/POPS_AI

Stack

Python 3.10 LangChain ChromaDB FastAPI Discord.py Google Gemini 2.0 Flash SBERT Docker Supervisor PyMuPDF

If you made it this far and are curious about any architectural decision, token cost management in production, or how to adapt this to a different use case — drop a comment. Happy to discuss.

Do PDF ao Discord com RAG: Como construí um agente RAG para eliminar interrupções operacionais na empresa

Cleber Lucas — Tue, 09 Jun 2026 13:51:49 +0000

Como construí um agente RAG para eliminar interrupções operacionais na empresa

Projeto open source com Python, LangChain, ChromaDB, FastAPI e Discord — do problema real ao deploy em produção.

Toda empresa tem aquele ciclo silencioso que drena tempo sem que ninguém perceba.

Um funcionário tem uma dúvida sobre um procedimento. Não encontra a resposta nos documentos. Interrompe alguém mais experiente. Essa pessoa para o que estava fazendo, responde, e volta ao trabalho — já com o raciocínio quebrado. Multiplique isso por 10, 20, 50 vezes por semana.

Foi observando esse padrão que decidi construir o POPS AI: um agente de RAG (Retrieval-Augmented Generation) capaz de responder perguntas sobre os Procedimentos Operacionais Padrão de uma empresa, direto pelo Discord ou via API REST.

O problema que motivou o projeto

A empresa tinha dezenas de POPs documentados em PDF. O problema não era a falta de documentação — era o atrito para acessá-la. Ninguém abre uma pasta de rede, procura o arquivo certo e lê 15 páginas para responder uma dúvida pontual.

A pergunta que me fiz foi simples: e se a documentação pudesse responder sozinha?

A arquitetura em três etapas

O sistema funciona em três fases distintas, cada uma com responsabilidade clara.

1. Extração

O script extrair_texto.py lê os PDFs da pasta pops_originais/, extrai o texto completo com PyMuPDF e salva em .txt. Imagens das páginas também são extraídas para uso futuro.

import fitz  # PyMuPDF

def extrair_texto_pdf(caminho_pdf):
    doc = fitz.open(caminho_pdf)
    texto_completo = ""
    for pagina in doc:
        texto_completo += pagina.get_text()
    return texto_completo

Simples, mas importante: a qualidade da extração determina a qualidade das respostas. PDFs escaneados sem OCR são o inimigo número um aqui.

2. Geração de embeddings

Com os textos extraídos, o gerar_embeddings.py divide o conteúdo em chunks usando o RecursiveCharacterTextSplitter da LangChain, gera os vetores e persiste no ChromaDB.

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200
)
chunks = splitter.split_text(texto)

O chunk_overlap=200 foi uma decisão deliberada: ele garante que o contexto não seja cortado abruptamente entre um chunk e o próximo, o que melhorou visivelmente a coerência das respostas.

O projeto suporta dois modelos de embedding via config.py:

Gemini models/embedding-001 — qualidade alta, requer API key e gera custo por volume
SBERT local (paraphrase-multilingual-mpnet-base-v2) — roda offline, ótimo para evitar custos ou limites de requisição

Essa flexibilidade foi uma das decisões de design que mais agregou valor, especialmente para quem quer experimentar o projeto sem gastar nada.

3. Consulta (RAG)

Quando o usuário faz uma pergunta, o sistema:

Converte a pergunta em vetor usando o mesmo modelo de embedding
Busca os chunks mais semanticamente similares no ChromaDB
Monta um prompt com os trechos recuperados como contexto
Envia para o Gemini 2.0 Flash gerar a resposta final

resultados = collection.query(
    query_embeddings=[embedding_pergunta],
    n_results=5
)

contexto = "\n\n".join(resultados['documents'][0])

prompt = f"""Você é um assistente especializado nos POPs da empresa.
Use apenas as informações abaixo para responder.

Contexto:
{contexto}

Pergunta: {pergunta}
"""

As interfaces: Discord e API

O projeto expõe a base de conhecimento de duas formas.

Bot do Discord com slash commands:

/pop <pergunta> — consulta a base vetorial e retorna a resposta
/addpop <arquivo.txt> — permite que administradores adicionem novos POPs em tempo real, sem precisar reprocessar toda a base

API FastAPI com endpoint POST /ask, pensada para integrar com outros sistemas internos:

// Request
{ "question": "Como configurar o scanner da impressora Samsung?" }

// Response
{
  "answer": "Para configurar o scanner, siga os passos:\n1. Ligue a impressora...\n[Fonte: POP-ConfiguraçãoScanner.txt]"
}

O desafio que ninguém menciona: custo de tokens

Construir o RAG foi a parte divertida. O desafio real veio depois: como controlar o custo em produção?

Algumas decisões que fizeram diferença:

Usar SBERT para embeddings em vez da API do Gemini reduz o custo de indexação para zero — o modelo roda localmente. O custo só existe na geração de resposta, que é onde o valor real está.

Limitar n_results=5 na busca vetorial evita passar contexto desnecessário para o modelo. Mais contexto = mais tokens = mais custo, sem necessariamente melhorar a resposta.

Gemini 2.0 Flash foi escolhido intencionalmente sobre o Pro: para perguntas objetivas sobre procedimentos, a diferença de qualidade é mínima e a diferença de custo é expressiva.

Deploy: um container, dois processos

Uma decisão que me custou algumas horas foi rodar o bot do Discord e a API FastAPI no mesmo container Docker. A solução foi o Supervisor, que gerencia ambos os processos de forma leve e auto-recuperável.

# supervisord.conf
[program:api]
command=uvicorn api_bot:app --host 0.0.0.0 --port 8000

[program:discord]
command=python bot_discord.py

autostart=true
autorestart=true

O resultado é um container único, leve, que sobe os dois serviços em paralelo e reinicia automaticamente qualquer um que falhe. Para uma VPS de entrada, isso faz toda a diferença.

O que aprendi que não estava no plano

Chunking é uma arte. O tamanho e o overlap dos chunks afetam mais a qualidade das respostas do que o modelo em si. Passei mais tempo ajustando isso do que qualquer outra coisa.

Segurança desde o início. O .gitignore precisou ser configurado antes do primeiro commit público para garantir que nenhum PDF com dados confidenciais da empresa fosse parar no repositório. Um erro aqui é difícil de reverter.

O problema real não era técnico. A parte mais complexa foi entender que tipo de pergunta os usuários fariam e como estruturar os POPs para que o modelo conseguisse recuperar as informações certas. Garbage in, garbage out vale dobrado em RAG.

O projeto é open source

O POPS AI está disponível no GitHub com README completo, .env.example, Docker Compose configurado e passo a passo de instalação tanto local quanto via container.

Você pode clonar, adaptar para sua própria base de conhecimento e usar com seus próprios documentos — seja para POPs, wikis internas, manuais de produto ou qualquer documentação em PDF.

🔗 github.com/obelucca/POPS_AI

Stack utilizada

Python 3.10 LangChain ChromaDB FastAPI Discord.py Google Gemini 2.0 Flash SBERT Docker Supervisor PyMuPDF

Se você chegou até aqui e tem curiosidade sobre alguma decisão de arquitetura, custo de tokens em produção ou como adaptar para um caso de uso diferente — deixa nos comentários. Bora trocar ideia.