Como operar várias empresas com receita mensal de US$ 10 mil usando uma stack de US$ 20 por mês

• Estratégia bootstrap para operar várias empresas SaaS com MRR acima de US$ 10 mil com custos de infraestrutura abaixo de US$ 20 por mês, usando um único VPS, a linguagem Go, SQLite e GPU local
• Em vez de AWS ou orquestração complexa em nuvem, todos os serviços rodam em um único VPS de US$ 5 a 10, permitindo focar no processamento das requisições, não na gestão da infraestrutura
• Escolha de Go como linguagem de backend para garantir um processo de deploy extremamente simples: compilar em um único binário e enviar ao servidor sem gerenciamento de dependências
• Execução do VLLM em uma GPU local (RTX 3090) para zerar o custo do processamento em lote de IA, usando modelos de ponta via OpenRouter apenas nos recursos voltados ao usuário
• Mesmo sem capital de risco, manter os custos próximos de zero permite garantir uma runway praticamente infinita e tempo suficiente para encontrar product-market fit

---

Estratégia lean de operação de servidores

• A forma mais comum de lançar um web app em 2026 é provisionar um cluster EKS, uma instância RDS e um NAT Gateway na AWS; nesse caso, o gasto já passa de US$ 300 por mês mesmo sem um único usuário
• Como alternativa, aluga-se um VPS de US$ 5 a 10 por mês na Linode ou DigitalOcean e opera-se tudo em um único servidor
• Até mesmo 1 GB de RAM pode ser suficiente se for bem utilizado; se precisar de folga, use um swapfile
• Com apenas um servidor, é possível saber exatamente onde estão os logs, o que causou o crash e como reiniciar
• O motivo para escolher VPS em vez de AWS é manter custos previsíveis e uma arquitetura simples

Por que escolher Go

• Python ou Ruby consomem metade da RAM só com a inicialização do interpretador e o gerenciamento de workers do gunicorn
• Go oferece desempenho muito superior em workloads web, tem um sistema de tipos rigoroso e, em 2026, é uma linguagem extremamente fácil para LLMs fazerem inferência
• A principal vantagem do Go é a simplicidade do deploy: toda a aplicação é compilada em um único binário estaticamente linkado, construído no notebook e enviado ao servidor com scp para ser executado
• Não há necessidade de inferno de dependências com pip install nem de ambientes virtuais, e é possível implementar um servidor web de nível de produção sem frameworks inchados
• Só com a biblioteca padrão do Go já dá para escrever um servidor capaz de processar dezenas de milhares de requisições por segundo

IA local: custo zero para tarefas em lote

• Se você tem uma placa de vídeo em casa, é como já ter créditos ilimitados de IA
• Ao criar o eh-trade.ca, foi necessária uma grande pesquisa qualitativa de ações, analisando os relatórios trimestrais de milhares de empresas; usando a API da OpenAI, isso poderia custar centenas de dólares
• Em vez disso, foi executado o VLLM em uma RTX 3090 (24 GB de VRAM) comprada por US$ 900 no Facebook Marketplace, eliminando a necessidade de pagar provedores de IA
• Caminho de evolução para IA local:
  • Comece com Ollama: configuração com um comando de uma linha (ollama run qwen3:32b), ideal para testar vários modelos rapidamente e iterar prompts
  • Migre para produção com VLLM: o Ollama vira gargalo com requisições simultâneas, enquanto o VLLM é dramaticamente mais rápido com PagedAttention. Ao enviar 8 a 16 requisições assíncronas ao mesmo tempo, ele faz batch na memória da GPU e processa tudo em quase o mesmo tempo de uma única requisição
  • Transformer Lab: quando for necessário pré-treinamento ou fine-tuning de modelo, isso pode ser feito facilmente no hardware local
• Para gerenciar isso, foi desenvolvido o laconic: uma ferramenta de pesquisa com agentes otimizada para janelas de contexto de 8K, que “pagina para fora” partes desnecessárias da conversa, como um gerenciador de memória virtual do sistema operacional, mantendo apenas os fatos centrais no contexto ativo do LLM
• llmhub: ferramenta que abstrai todos os LLMs na combinação provider/endpoint/apikey e lida de forma transparente com IO de texto e imagem, seja local ou na nuvem

Acesso a modelos de ponta via OpenRouter

• Nem tudo pode ser processado localmente, e interações de chat voltadas ao usuário com baixa latência exigem modelos de raciocínio de ponta como Claude 3.5 Sonnet ou GPT-4o
• Em vez de gerenciar contas de billing, chaves de API e rate limits separados para Anthropic, Google e OpenAI, tudo é unificado com o OpenRouter
• Basta escrever uma única integração compatível com OpenAI para obter acesso imediato a todos os principais modelos de fronteira
• Há suporte a roteamento de fallback transparente: se a API da Anthropic cair, a requisição muda automaticamente para um modelo equivalente da OpenAI, sem que o usuário veja uma tela de erro e sem lógica complexa de retry

Programação com IA de forma econômica usando GitHub Copilot

• Enquanto novos modelos caros são lançados toda semana, muitos desenvolvedores gastam centenas de dólares por mês com assinatura do Cursor e chaves de API da Anthropic
• Em contrapartida, mesmo usando Claude Opus 4.6 o dia inteiro, o custo mensal quase nunca passa de US$ 60
• O segredo é aproveitar o modelo de preços da Microsoft: comprar a assinatura do GitHub Copilot em 2023 e conectá-la ao VS Code padrão
• O truque central do Copilot: a Microsoft cobra por requisição, não por token, e uma “requisição” é apenas o que você digita na caixa de chat. Mesmo que o agente analise o codebase inteiro por 30 minutos e altere centenas de arquivos, isso custa cerca de US$ 0,04
• A estratégia ideal é escrever um prompt detalhado com critérios de sucesso rígidos, instruir “continue até que todos os erros sejam corrigidos” e então executar

Usando SQLite como banco de dados para tudo

• Ao iniciar um novo projeto, o banco principal usado é sempre o sqlite3
• Do ponto de vista enterprise, parece necessário ter um servidor de banco de dados em processo separado, mas na prática um arquivo SQLite local, acessado via interface C ou memória, é ordens de magnitude mais rápido do que um servidor Postgres remoto com salto de rede TCP
• Há um mal-entendido sobre concorrência: a ideia de que o SQLite bloqueia o banco inteiro em toda escrita está errada, e isso é resolvido com Write-Ahead Logging (WAL)
  • Com PRAGMA journal_mode=WAL; e PRAGMA synchronous=NORMAL;, leituras e escritas não se bloqueiam mutuamente
  • Um único arquivo .db em um drive NVMe consegue atender milhares de usuários simultâneos
• Para facilitar a implementação de autenticação de usuário, foi desenvolvida a própria biblioteca smhanov/auth: ela se integra diretamente ao banco de dados em uso e oferece cadastro, sessão, redefinição de senha e login com Google/Facebook/X/SAML

Conclusão: construir uma startup sem infraestrutura complexa

• O setor de tecnologia insiste em dizer que, para construir um negócio de verdade, é preciso orquestração complexa, contas mensais enormes na AWS e milhões de dólares em venture capital, mas isso não é verdade
• Ao combinar um único VPS, binários compilados estaticamente, processamento em lote de IA com hardware GPU local e a velocidade bruta do SQLite, é possível bootstrapar uma startup escalável pelo preço de alguns cafés por mês
• Isso dá ao projeto uma runway infinita, permitindo focar em resolver os problemas dos usuários em vez de se preocupar com burn rate

[GN⁺]

Comentários do Hacker News

• Em ambientes corporativos, é forte a percepção de que se deve usar um servidor de DB externo, mas, na prática, um arquivo SQLite local é muito mais rápido que um Postgres remoto quando se comunica via interface C ou memória
  Claro, o SQLite é excelente, mas conectar ao Postgres via Unix domain socket em localhost praticamente elimina o overhead de rede
  Dá para usar sem muito mais dificuldade do que SQLite, aproveitar todos os recursos do Postgres, e fica bem mais fácil executar relatórios, configurar read replica e montar HA
  Rodar Postgres no mesmo servidor do app é uma escolha de outro nível, totalmente diferente de exagerar na preparação montando um cluster Kubernetes

  • Mesmo na mesma máquina, o SQLite é muito mais rápido que o Postgres usando domain socket (exemplo de 100.000 TPS)
    Ao rodar um monolithic app em uma única máquina, o Postgres não oferece tantos recursos a mais em relação ao SQLite
    O SQLite pode ser estendido diretamente na linguagem do app com Application functions, e graças ao Litestream, backup e replicação também melhoraram muito
    Mas a configuração padrão não é boa, então é preciso separar conexões de leitura e escrita e o próprio app deve gerenciar a write queue
  • Se você realmente executar 100.000 queries SELECT 1, a diferença é grande: Postgres leva 2,77 segundos e SQLite (in-memory) 0,07 segundo (link do benchmark)
  • Eu usei SQLite com extensões em um cenário de alto desempenho que processava milhões de documentos por segundo
    Também seria possível com um servidor remoto, mas teria sido muito mais complexo
    Em vez disso, subi o DB no S3 para que cada instância recebesse uma cópia e processasse em paralelo. SQLite é uma alternativa comprovada quando o que se precisa é desempenho, mais do que recursos
  • Dizer “você pode usar todos os recursos do Postgres” não é justamente a abordagem YAGNI (You Ain’t Gonna Need It) que o TFA critica?
  • Quanto mais recursos desnecessários, maior o prejuízo líquido. O DB ideal oferece apenas os recursos necessários

• Muita gente acredita que precisa começar já com uma arquitetura complexa como serverless, Kubernetes, multi-zone HA
  Quando alguém diz “dá para rodar só em uma VPS barata”, a resposta costuma ser “e a escalabilidade?”, “e o backup?”, “e a manutenção?” — na prática, só estão repetindo frases de marketing de cloud
  Essa atitude chega perto de uma impotência aprendida

  • Quando eu trabalhava como consultor, desenhava 25 componentes de cloud para apps com menos de 200 usuários. Tudo resultado do treinamento de que “cloud = precisa ser complexo”
  • Os responsáveis por compras de TI gastam o dinheiro da empresa sem dó para não precisar entender
  • Hoje vejo o mesmo fenômeno em workflows baseados em agentes. Como os dados de treinamento estão cheios de codebases para equipes grandes, até projetos pequenos são empurrados para estruturas enormes
    Por exemplo, colocar Shadcn, Tailwind, React, Zod e Vite em uma SPA simples com alguns formulários. A carga de manutenção é enorme
    Esse tipo de stack pode até ser a “resposta certa”, mas não é a resposta adequada ao contexto
  • A “geração cloud native” nunca teve a chance de aprender do que um app básico realmente precisa, por causa dos planos gratuitos
  • Ainda assim, acho que backup é importante

• Eu uso Linode ou DigitalOcean e pago só de 5 a 10 dólares por mês. 1GB de RAM é suficiente
  Se você reunir vários projetos em um único servidor dedicado, pode reduzir ainda mais o custo
  Por exemplo, uso um de 40 euros por mês no leilão de servidores da Hetzner e instalo Proxmox para rodar várias VMs (link do Proxmox)
  Mesmo criando 15 VMs, sai algo como 2,66 euros por VM, então a eficiência de custo em relação à escala é muito alta
  Como é hardware recondicionado, backup é obrigatório, mas isso de qualquer forma já seria necessário
  Lugares como Hetzner, Contabo e Scaleway ainda são opções baratas

  • Os preços da Hetzner subiram, mas a OVH oferece hardware mais novo por preços parecidos
  • Fico curioso por que usar VM e não contêineres
  • Também fico curioso sobre como lidam com IPv4. E tenho dúvidas se alugar uma VM grande para usar como hipervisor é permitido comercialmente
  • Parece que simplesmente rodar em contêineres Docker seria mais eficiente

• Acho que o modo WAL do SQLite é o maior fator de economia
  Python ou Node também servem tão bem quanto Go. A VPS da Hetzner com 4GB de RAM e 10TB de tráfego custa algo como 5 dólares por mês
  Só que, se você usar servidor dedicado, precisa fazer backup do DB com frequência e cuidar você mesmo da segurança
  Eu configuro tudo com Terraform, limitando o acesso SSH apenas ao meu IP, depois ajusto o Tailscale e fecho a porta pública de SSH

  • Para backup, é mais seguro usar armazenamento de outra empresa, diferente da provedora da VM. Você precisa conseguir restaurar mesmo que sua conta seja suspensa
    Eu uso Backblaze B2, mas com Restic dá para fazer backup facilmente em outros serviços também
  • Para proteger SSH, não é obrigatório usar uma configuração complexa. Uma senha forte por si só já basta
  • Uma vez deixei o Postgres aberto com a senha padrão e, em um dia, ele foi invadido e virou um servidor de bots
    Mesmo recentemente, os logs de tentativa de SSH encheram em uma hora. Agora desativei login por senha e só acesso via Tailscale
    Servidor exposto na internet é realmente perigoso
  • É difícil acreditar que SSH seja comprometido em uma hora. A menos que fosse uma senha fraca ou VNC aberto, parece impossível
  • Eu também abandonei o Postgres e migrei para SQLite WAL ao mover um site Django para Docker Compose. Ficou muito mais simples de administrar e fazer backup

• Acho desnecessário impor o limite de 1GB de RAM. Com 20 dólares por mês você consegue 8GB de RAM, que pode usar para cache ou DB
  A diferença de 15 dólares não muda muito a operação de um negócio. Tentar encaixar tudo em uma VPS de 5 dólares não ajuda o crescimento do negócio

  • Mas 15 dólares também não é dinheiro desprezível. Se 1GB basta, não há motivo para gastar mais
    Antigamente já se rodava bem uma stack LAMP com 128MB, e os sites de hoje também não são tão complexos
  • Como a latência de leitura do NVMe fica na faixa de 100µs, mesmo com SQLite dá para atender centenas de requisições por segundo
    17 milhões de requisições por dia sem cache são viáveis, então quadruplicar a infraestrutura antes disso é desperdício
  • O verdadeiro motivo do limite de 1GB é treinar a evitar overengineering e manter o foco no valor para o cliente
  • Sistemas modernos têm eficiência de RAM muito maior graças a compressão de páginas e swap em NVMe.
    O modelo Macbook Neo 8GB é um bom exemplo disso
  • Eu também acho que a diferença de 15 dólares não é tão grande, mas o ponto central é minimizar o custo de hospedagem

• WebSequenceDiagram parece um produto legal
  Mas mais difícil do que a implementação técnica é encontrar um problema valioso e chegar aos usuários. É aí que está o valor real

  • Eu penso a mesma coisa. Entre trabalho e família, o dia não rende. Mas quando você conhece um problema de um domínio específico, a solução parece óbvia demais
  • Já existem muitos concorrentes. Por exemplo, coisas como Excalidraw

• Assinei o GitHub Copilot em 2023, conectei ao VS Code e sigo usando desde então
  O ponto principal é que a Microsoft faz cobrança por requisição. Mesmo que uma única requisição altere o código inteiro por dezenas de minutos, eu pago só uns 0,04 dólar
  Então escrevo prompts muito específicos, mando “continue até resolver todos os erros” e vou tomar um café. É como se Satya Nadella estivesse subsidiando meu custo de computação

  • Mas já houve casos de contas suspensas por esse tipo de abuso por requisição (caso no Reddit)
  • O autor chama GPT‑4o e Sonnet 3.5 de SOTA, então talvez seja melhor ler as dicas de AI com certa desconfiança
  • (Comentário removido) Disse não entender por que recebeu downvotes

• Não aprendi nada novo com o texto. Em grande parte, pareceu um conjunto de conselhos básicos embalados por AI
  Pelo título, achei que seria sobre descoberta de ideias e lançamentos bem-sucedidos

  • Com um título tipo “por menos de US$ 5 por mês”, é natural que venham conselhos básicos. Mas, surpreendentemente, muita gente ainda não sabe disso
  • Nesse caso, eu recomendaria começar um blog. O que você considera básico pode ser novidade para outra pessoa
  • Eu também toparia gastar 5 mil dólares por mês para faturar 10 mil dólares. O problema é descobrir como gerar receita
  • A frase “é preciso o raciocínio de ponta de Claude 3.5 Sonnet ou GPT‑4o” tem cara de texto escrito por AI
  • Mas a inflação de recursos mencionada pelo autor realmente existe. Vejo com frequência gente resolvendo com AWS e Spark algo que um script Python simples bastaria

• Para quem estava curioso como eu, MRR significa “Monthly Recurring Revenue” (receita recorrente mensal)

  • Surpreende alguém ter se cadastrado há 16 anos e ainda não saber o que é MRR
  • Também existe ARR (Annual Recurring Revenue), que em geral é só o MRR multiplicado por 12 para inflar o número.
    Já vi gente anunciando ARR depois de operar por apenas dois meses

• Em muitos casos, a mentalidade centrada em cloud aumenta desnecessariamente a complexidade e o custo
  Na maioria dos projetos, uma VPS de porte médio já é suficiente
  Nossa empresa conseguia rodar páginas para 600 mil usuários em uma VPS de 30 euros, mas migrou para AWS e passou a pagar 800 euros por mês. Sem ganho nenhum
  Se não houver motivo, é melhor manter a abordagem simples de servidor que funciona bem há décadas
  Aliás, ouvi dizer que o StackOverflow também roda em apenas alguns servidores root potentes