Minha jornada para criar um SaaS que resolvesse minha dor de criação de conteúdo: Parte 1

Mapeei US$ 300 em assinaturas que posso substituir com agentic coding. O segredo está na estrutura de contexto que você dá para os modelos.

O ponto de partida

Voltei a criar conteúdo e as dúvidas de sempre ressurgiram: posto em uma plataforma fixa? Compartilho em múltiplas redes? Hospedo um blog em VPS própria? Decidi focar no Substack. Ouço muita gente falar da capacidade de distribuição da plataforma e, de fato, tem uma comunidade interessante. Além disso, não preciso me limitar a conteúdo técnico.

No LinkedIn, por exemplo, acabei restringindo os temas ao meu dia a dia de Staff Software Engineer / Solution Architect. A plataforma tem uma aversão conhecida a qualquer politização de conteúdo, como se fosse possível descolar política, filosofia, sociologia e economia do ambiente de trabalho. Na verdade, é o lugar onde esses assuntos mais caberiam. Mas enfim, desisti de dar murro em ponta de faca.

Meu objetivo era claro: criar uma aplicação para gerenciar meus conteúdos, centralizar meus agentes de revisão e automatizar a postagem em múltiplas plataformas. O que não imaginava é que a parte técnica seria o menor dos problemas.

Construir o próprio SaaS: menos é mais

Teve uma fala do Fiasco, um Tech Creator que acompanho, que mudou minha perspectiva. Ele comentou em um dos stories que, com o avanço da IA generativa, virou corrida do ouro: todo mundo tentando construir um SaaS para ficar milionário. Só que ele trouxe um ângulo diferente, que já vi outras pessoas mencionarem, mas sem o recorte técnico (e financeiro) que ele deu.

Pare e analise quantos softwares, SaaS e aplicativos você usa no dia a dia. Quantos deles poderiam ser reconstruídos sob medida para o que você realmente precisa? No meu post anterior¹, citei uma métrica do CHAOS Report: cerca de 45% das funcionalidades de uma aplicação nunca são usadas pelos usuários e 19% raramente são tocadas. Você paga por um software inteiro para usar duas ou três funções. Em muitos casos, o problema se resolveria com uma planilha. A diferença é que agora, com agentic coding, você pode construir uma mini aplicação própria e cortar custos de assinatura.

Mapeei cerca de 300 dólares mensais em assinaturas que pretendo reduzir. Algumas não vou conseguir substituir, claro. Este projeto que vou dissecar aqui é justamente sobre isso: a jornada para construir meu ambiente de contexto, como organizo e documento os projetos, os resultados alcançados e os próximos passos.

O gargalo não é código, é tempo

O maior desafio para construir uma solução como essa não é técnico. O técnico deixou de ser limitação muito tempo atrás na minha carreira e, com a GenAI, virou commodity. Meu complicador real é o tempo e não falo isso por drama.

Tenho quase 17 anos de carreira, apesar dos meus 33. Comecei a programar aos 10 anos (quem faz parte da tropa dos que começaram com blog no WordPress deixa o like, rsss). Com família, destino a maior parte possível do meu tempo para minha esposa e minha filha. Além delas, meus pais, minha irmã e minha avó.

O que sobra dedico a interesses fora da tecnologia: ilustração, leitura e, principalmente, o ócio de pensar em vários nadas. Não me refiro ao ócio criativo do Domenico De Masi, mas ao ócio puro, sem finalidade produtiva.²

Com essa rotina, ficou claro que para levar o objetivo até o fim e sair do outro lado com um projeto funcional precisava ser o mais objetivo possível. Objetivo nas especificações, na arquitetura, no harness engineering³ e, principalmente, no tempo disponível para cada tarefa. Ao longo desta minissérie de artigos, vou destrinchar essa jornada, os desafios que existem e podem ser potencializados pelo uso massivo de GenAI e, por fim, o que interessa: o resultado.

Content/Harness Engineering: a arquitetura do contexto

Antes de começar, precisava decidir como usar a IA generativa de forma eficiente. Tenho um mantra pessoal alinhado ao propósito original da área de tecnologia: eficiência e redução de custos. Com a chegada da GenAI e, agora, do tokenmaxxing⁴, esse princípio meio que se perdeu. Mas estando no Brasil, com o dólar sempre desproporcional aos nossos ganhos, presto muita atenção nesses pontos.

O content engineering (ou harness engineering) foi a base de tudo, desde a criação da documentação até a implementação. Montei a seguinte estrutura:

Agentes

• Arquitetura de soluções — Construção de especificações técnicas e decomposição em atividades
• Backend — Implementação de funcionalidades baseada em SOLID
• Frontend — Desenvolvimento visual com Tailwind para ganhar velocidade
• QA — Testes de backend e frontend
• Dados — Demandas de Data Scientist ou DBA, orientadas por skills
• AI Engineer — Integração com modelos de LLM (na prática, um backend com experiência em APIs de IA)

Skills

• Criação de issue — Padronização de tarefas, usada em conjunto com o agente de arquitetura
• Implementação de tarefas — Instruções para execução de epics
• Padrão de commit — Rastreabilidade do fluxo agentivo
• Descrição de PR — Padronização de pull requests
• Revisão de PR — Verificação de completude, qualidade, testes e segurança
• Padrão SOLID — Garantia de boas práticas de código

Rules

• Arquivos de configuração — Regras para Claude Code (CLAUDE.md), OpenCode (AGENTS.md) e Pi Agent
• Revisão de conteúdo — Padrões de público-alvo e manipulação de conteúdo

Sobre o agente de AI Engineer: não gosto muito dessa nomenclatura porque, na maior parte das vezes, a função é simplesmente um backend que já teve experiência com integrações de LLMs. Poderia ser uma skill do agente de backend tranquilamente.

Estou utilizando git (com github cli), docker e make com skills simples que informam as instruções de uso de cada ferramenta. Isso agiliza a implementação e a depuração das funcionalidades.

Meu intuito foi construir uma estrutura portátil. Trabalho na linha de submodules para reaproveitar em vários projetos diferentes, podendo modificar e distribuir em todos os repositórios. Nos momentos em que precisei de código, usei pseudocódigo. A ideia foi abstrair ao máximo qualquer dependência de linguagem ou framework. E vem funcionando.

O que funcionou e o que ainda precisa melhorar

Depois de estressar várias estruturas diferentes, cheguei a esse conjunto que ficou flexível o suficiente para usar em projetos variados. Não prendi nada a exemplos específicos de código, linguagem ou framework.

Dito isso, essa estrutura é viva. Temos que estar preparados para admitir que algo que julgamos bem planejado ainda tem espaço para melhorar. Se montar uma nova estrutura daqui a seis meses e ela for completamente diferente, azar: o que importa é se está funcionando agora.

Outro ponto que trago como alerta: os modelos avançaram muito, mas me arrisco a dizer que a maior parte dos avanços até o final do ano passado foi incremental. Muita ação especializada, muita capacidade nova, mas nada que causasse ruptura. Por isso, não existe a possibilidade de criar algo usando agentes como auxiliares sem uma estrutura que consiga transbordar seu contexto para os modelos. Sem harness engineering, os agentes patinam.

Por onde começar

Neste primeiro relato, meu objetivo foi desmistificar o harness engineering. Vejo muita gente falando sobre o tema, quase sempre usando fluxogramas genéricos para exemplificar como deveria ser uma estrutura de contexto. Mas, no fim, só você, sua equipe ou sua empresa podem construir esses dados da melhor maneira possível.

Dois conselhos que posso deixar:

• Antes de decidir sobre modelo ou ferramenta, mapeie o que você já tem de contexto reaproveitável e o que seria necessário para direcionar o melhor resultado do modelo.
• Existem vários lugares onde você pode compartilhar e baixar skills e agentes prontos. Para aprendizado, funciona. Mas acreditar que contexto criado por outras pessoas e para cenários específicos vai funcionar no seu caso é arriscado. Sempre prefira criar os seus.

Nas próximas partes, vou detalhar como dividi as atividades em epics e como foi a implementação prática dessa estrutura.

Referências

1. The Standish Group International. CHAOS Report (2002). Dados indicam que 45% das funcionalidades nunca são utilizadas e 19% raramente. https://standishgroup.com

2. O Ócio Criativo — De Masi, D. Sextante, 2000. Publicado originalmente como L'Ozio Creativo em 1995.

3. Harness engineering: conheça o termo que está cada vez mais em alta — Bonas, M. TI Inside Online, 19 mai. 2026.

4. Taurion, C. Tokenmaxxing e o custo oculto de medir produtividade da IA por tokens. Coletivo Tech, 3 jun. 2026. https://coletivo.tech/artigos/cezar-taurion-tokenmaxxing-metrica-produtividade-ia/