Você quer colocar um app no ar. Aí contrata um serviço pro front-end, outro pro back-end, outro pro banco, outro pro login e outro pro cache. Quando termina, tem cinco painéis, cinco contas e zero clientes.
E cada serviço trouxe configuração, integração e mais uma coisa pra quebrar às três da manhã.
Eu começo perguntando o que dá pra retirar. Dependendo do produto, o app pode ser estático. Se precisar guardar dados compartilhados, ainda dá pra rodar sob demanda, sem manter um processo da aplicação ligado o dia inteiro.
Gravei um vídeo sobre essas decisões. Não é uma promessa de que qualquer negócio fica grátis pra sempre: é o caminho que eu tentaria antes de assumir custo e operação desnecessários.
Precisa mesmo de um back-end?
Pensa num portfólio, num blog ou num catálogo cujo conteúdo pode ficar pronto antes da visita. Você faz o build e publica os arquivos. Quando alguém abre, recebe o que já estava pronto. Não precisa renderizar a mesma informação de novo a cada acesso.
E estático pode ter interação. Uma calculadora faz conta no navegador. Algumas ferramentas conseguem converter arquivos na própria máquina da pessoa. Ter um botão e executar JavaScript não exige automaticamente um back-end seu.
A pergunta é o que o produto faz. Se os dados precisam ser compartilhados entre dispositivos ou usuários, ou o processamento precisa acontecer numa máquina que você controla, a decisão muda. Mas eu faria essa pergunta antes de escolher a stack.
Quando dá pra eliminar essa parte, saem também a configuração, a manutenção e os pontos de falha dela. É um caminho bem mais simples pra hospedar sem pagar pela execução de uma aplicação.
O app de leituras precisa de dados
Agora imagina um app pra organizar leituras. Você salva um artigo pelo celular e abre sua lista no computador. Cada pessoa tem uma conta e só pode alterar a própria lista.
Os dados precisam persistir em algum lugar acessível pelos dois dispositivos. E a checagem de permissão precisa acontecer numa parte confiável do sistema, não só num botão escondido no navegador.
Aqui fazem sentido front-end, back-end e banco. Só que essas são funções da aplicação. Não significam três repositórios, três fornecedores ou três máquinas.
| Decisão | Pergunta que eu faria |
|---|---|
| Gerar arquivos | O conteúdo pode ficar pronto antes da visita? |
| Executar no navegador | A funcionalidade consegue trabalhar com os recursos locais do usuário? |
| Ter back-end | Preciso de dados compartilhados, permissões ou processamento no servidor? |
| Manter processo ativo | Existe trabalho que exige continuidade entre requisições? |
Publicar só o front-end como arquivos também não elimina os back-ends que ele chama. Se depende de cinco APIs externas, essas cinco dependências continuam fazendo parte da operação.
Fullstack não decide como o código roda
Num modelo de processos contínuos, a aplicação fica ativa esperando conexões. O banco também tem sua operação, na mesma máquina ou em outro serviço. Uma plataforma pode administrar tudo pra você, mas a capacidade reservada continua existindo mesmo sem visitas.
Isso funciona. Só que eu não começaria pagando por um processo permanentemente ligado quando o produto só precisa responder a acessos ocasionais.
No serverless, você publica código que a plataforma executa sob demanda. Ao salvar uma leitura, ele recebe a requisição, valida, grava e responde. Continua sendo uma aplicação fullstack, com regras de negócio, login e banco.
Ficar disponível vinte e quatro horas é diferente de manter o seu código executando o tempo inteiro. E os dados continuam persistidos depois que a execução termina. Você não está guardando o catálogo numa variável que desaparece no fim da requisição.
Um exemplo com menos fornecedores
A Cloudflare é um exemplo desse caminho. Você pode publicar arquivos estáticos e executar o back-end com Workers. Quando precisa de dados, conecta o D1, o banco SQL serverless da plataforma.
Nas condições do plano gratuito consultadas em outubro de 2026, Workers permite cem mil requisições por dia, e o D1 tem cinco GB de armazenamento total gratuito. O banco também tem limites próprios de leitura e escrita, descritos no pricing do D1. Cinco GB não significam consultas ilimitadas.
A entrega direta de arquivos estáticos é gratuita. Se uma configuração faz o Worker executar antes de servir o arquivo, essa execução segue as regras de uso do Worker. Vale saber o que efetivamente está rodando.
Eu gosto de manter front-end e back-end no mesmo projeto e adicionar recursos porque o produto pede. Se a aplicação resolve suas sessões e login, não preciso contratar outro serviço só porque apareceu num tutorial. Se não existe problema de desempenho, não começo instalando cache.
Concentrar recursos também não faz milagre. Você consegue montar uma aplicação serverless com oito serviços e passar a semana colando tudo. O selo serverless não desfaz uma arquitetura complicada.
Onde o grátis acaba
O plano gratuito tem limites de consumo e de execução. Domínio, e-mail, pagamentos e chamadas de IA podem ter custos separados. A promessa aqui é reduzir a hospedagem dentro dessas condições, não zerar toda a operação do negócio.
E há aplicações que ficam melhores com processos contínuos, processamento pesado ou recursos específicos de um servidor convencional. Aí existe um motivo concreto pra pagar por isso.
Eu não trataria estático, serverless e servidor contínuo como três fases obrigatórias de crescimento. Um produto pode continuar estático. Outro pode precisar de uma aplicação continuamente ativa desde o primeiro dia. O requisito é que decide.
Minha ordem de tentativa é simples: gero arquivos quando resolve; precisou de back-end, tento fullstack serverless; se existe necessidade real de um processo ativo, assumo esse custo. Prefiro gastar meu tempo no que as pessoas vão usar a manter uma integração que veio no template.
Vídeo no YouTube: Como hospedar seu SaaS de graça
Conheça meu trabalho: https://bergholz.com.br/
Obrigado por ler até aqui.
