Do Primeiro Commit ao Produto Ao Vivo em 48 Horas

21 de novembro de 2025, 9:14 AM

Foi quando fizemos o primeiro commit. Um projeto vazio. Uma tela em branco. Até a meia-noite do dia 23 de novembro, tínhamos um produto ao vivo com um domínio personalizado, atendendo usuários reais.

Essa não é uma história sobre cortar caminhos ou lançar software quebrado. É sobre o que acontece quando você sabe exatamente o que está construindo e se recusa a perder tempo com qualquer outra coisa.

O que foi lançado em 48 horas

Aqui está o que estava ao vivo ao final do segundo dia:

Uma interface de chat AI em tempo real. Não uma camada em cima de uma API. Um sistema de chat adequado com gerenciamento de sessões, histórico de mensagens e respostas em streaming. Os usuários podiam ter conversas com agentes de IA que realmente lembravam o contexto.

Um sistema de arquivos virtual. Os usuários podiam criar pastas, fazer upload de arquivos, renomeá-los, organizá-los em espaços de trabalho. A IA podia ler e escrever nesses arquivos durante as conversas. Não uma demonstração de brinquedo — um sistema de arquivos real respaldado pelo MongoDB.

Espaços de trabalho com troca de agentes. Diferentes espaços de trabalho podiam usar diferentes agentes de IA com diferentes capacidades. Um usuário poderia ter um espaço de trabalho de codificação, um espaço de trabalho de escrita e um espaço de trabalho de pesquisa — cada um com seu próprio contexto e arquivos.

Autenticação de usuários e sincronização. Conectado ao nosso sistema de autenticação via RabbitMQ. Os usuários faziam login e seus dados estavam lá. Em todos os dispositivos. Imediatamente.

Geração de imagens. A IA podia gerar imagens durante as conversas. Não apenas respostas em texto — saída visual real.

Modelos. Pontos de partida pré-construídos para que os usuários não enfrentassem uma tela em branco em sua primeira visita.

Pipeline de implantação. Dockerizado, implantado, rodando em um domínio personalizado com configuração de ambiente adequada.

As decisões que tornaram isso possível

Velocidade como essa não vem de trabalhar 48 horas seguidas (embora tenha havido bastante disso). Vem das decisões que você toma antes de escrever a primeira linha de código.

Decisão 1: MongoDB em vez de Mongoose. Começamos com Mongoose por cerca de quatro horas. Depois mudamos para drivers MongoDB brutos. O Mongoose adiciona uma camada de validação de esquema que é útil para grandes equipes, mas um puro ônus para uma equipe pequena que conhece seu modelo de dados. Quatro horas “perdidas” que nos economizaram dezenas de horas nas semanas seguintes.

Decisão 2: Construir o servidor e o cliente em um único repositório. Monorepo. Um docker-compose.yml. Um comando de implantação. Sem coordenação entre repositórios. Sem “a API está implantada, mas o frontend não.” Quando você está se movendo rápido, reduzir o número de coisas que podem ficar fora de sincronia é mais importante do que a pureza organizacional.

Decisão 3: Lançar em produção no dia dois, não no dia vinte. Implantamos antes de estarmos “prontos”. O domínio estava configurado, o SSL estava configurado, as variáveis de ambiente estavam no lugar — tudo isso antes da metade dos recursos ser construída. Por quê? Porque a implantação é a parte que te surpreende. Melhor descobrir essas surpresas no dia dois com três recursos do que no dia vinte com trinta.

O que não construímos

Tão importante quanto o que lançamos é o que deixamos de fora deliberadamente:

• Sem painel de administração. Usamos o MongoDB Compass diretamente.
• Sem sistema de design personalizado. Usamos padrões limpos e iteramos depois.
• Sem análises. Observamos os logs do servidor.
• Sem testes automatizados. (Isso veio no dia três.)
• Sem documentação. O código era a documentação.

Cada um desses teria sido a coisa “responsável” a se construir. Cada um teria nos custado um dia. E nenhum deles teria nos ensinado o que aprendemos ao colocar o produto na frente de usuários reais no dia dois.

A lição

Há uma versão dessa história onde passamos duas semanas em diagramas de arquitetura. Onde debatemos esquemas de banco de dados em um Google Doc. Onde configuramos um pipeline de CI/CD adequado antes de escrever qualquer código de aplicação.

Essa versão da história termina com um plano bonito e nenhum produto.

A versão que realmente aconteceu terminou com um produto funcional e uma longa lista de coisas a melhorar. Vamos aceitar essa troca sempre.

Quarenta e oito horas. Primeiro commit até o produto ao vivo. Não porque somos gênios. Porque tomamos decisões rápidas, lançamos mais rápido e corrigimos coisas em produção como todo mundo realmente faz — mas poucos admitem.

O produto que você vê hoje, 84 dias e 632 commits depois, começou bem ali. Em 48 horas.