Pitch: Como estruturamos um SaaS no Edge para custar quase R$ 0 de infra no lançamento

1. Introdução

Há alguns meses, começamos a construir o Propoza, uma ferramenta que gera propostas comerciais com IA para freelancers e MEIs brasileiros.

O problema era prático: freelancers gastam horas montando propostas no Canva ou Word e entregam documentos genéricos que não protegem o escopo do projeto. A ferramenta precisava ser simples - o usuário descreve o serviço, a IA estrutura uma proposta completa com escopo, cronograma e condições de pagamento.

O desafio técnico: como manter um SaaS freemium para freelancers brasileiros sem estourar o orçamento antes de ter receita?

Um SaaS enxuto ou micro SaaS normal custa entre R$ 30 e R$ 100 por mês antes do primeiro cliente pagante. Só de servidor, banco gerenciado e CDN. Para um produto em fase de validação, isso é dinheiro queimado.

Decidimos tentar uma rota diferente: construir tudo no edge, com infraestrutura serverless, sem servidor para gerenciar. O texto a seguir mostra o que funcionou, os trade-offs e o que aprendemos.

2. O problema com a stack SaaS tradicional

Antes de escolher a stack, levantamos o custo mínimo de um SaaS brasileiro rodando em infraestrutura convencional:

Componente	Provedor típico	Custo mensal estimado
Servidor	DigitalOcean / AWS EC2	R$ 50 a 150
Banco de dados	PostgreSQL gerenciado (RDS, Supabase)	R$ 50 a 200
CDN	Cloudflare (plano pago) ou similar	R$ 30 a 100
Domínio	Registro.br	R$ 40/ano

Não é absurdo para um SaaS consolidado. Mas para um produto em fase de validação, com zero clientes pagantes, significa queimar R$ 300 antes de saber se o modelo funciona.

Tem outro problema específico do Brasil: latência. Servidores concentrados em São Paulo e Rio deixam usuários do Norte e Nordeste com experiências ruins, especialmente em conexões móveis. Uma CDN ajuda, mas adiciona custo.

Precisávamos de algo que:

• Custasse perto de R$ 0 nos primeiros meses
• Oferecesse baixa latência em todo o Brasil
• Escalasse sem intervenção manual

Foi aí que olhamos para o modelo edge serverless.

3. A stack que escolhemos (e por que)

3.1 Cloudflare Workers como edge runtime

A base da aplicação é o Cloudflare Workers, um runtime serverless que executa código em mais de 330 data centers ao redor do mundo, incluindo pontos de presença no Brasil (São Paulo, Rio de Janeiro, Fortaleza).

• O código roda no data center mais próximo do usuário. Para usuários brasileiros, a latência fica abaixo de 50ms.
• Workers mantém um runtime aquecido, diferente de funções Lambda que congelam entre execuções. A primeira requisição é tão rápida quanto as seguintes.
• Se o produto viralizar e 10 mil pessoas acessarem ao mesmo tempo, o Workers distribui automaticamente.

O trade-off: Workers não é Node.js. Não tem acesso ao sistema de arquivos, WebSocket nativo, nem a biblioteca padrão do Node. É um runtime V8 isolado. Quase tudo que você precisa existe como API nativa (fetch, Web Crypto, streams), mas bibliotecas que dependem de fs ou net não funcionam.

3.2 Hono como framework HTTP

Precisávamos de um framework HTTP que rodasse dentro do Workers sem overhead.

A maioria dos frameworks Node.js populares (Express, Fastify, Koa) foi projetada para ambientes com Node.js completo e tem problemas de compatibilidade. Dependem do http module, usam APIs síncronas ou têm middleware pesado demais para o modelo serverless.

O Hono contorna isso. Tem menos de 14KB, roda nativamente em Workers, Deno, Bun e Node.js, e é TypeScript-first com inferência de tipos forte. Suporta middleware, routing params e validação com Zod.

Um exemplo de rota de geração de proposta:

import { Hono } from 'hono'
import { z } from 'zod'
import { zValidator } from '@hono/zod-validator'

const app = new Hono()

const proposalSchema = z.object({
  clientName: z.string().min(1),
  projectDescription: z.string().min(10),
  deliverables: z.array(z.string()).min(1),
  deadline: z.string(),
  paymentMethod: z.string()
})

app.post('/api/proposals/generate', zValidator('json', proposalSchema), async (c) => {
  const data = c.req.valid('json')
  const result = await generateProposal(data)
  return c.json({ proposal: result })
})

export default app

A validação com Zod na borda da requisição, junto com os tipos que o Hono infere, elimina vários bugs de runtime sem custo adicional de processamento.

3.3 Banco de dados no edge

A escolha do banco foi a decisão mais difícil. Para uma aplicação que precisa persistir propostas, usuários e configurações, o modelo relacional ainda é o mais natural.

Examinamos duas opções no ecossistema edge:

• D1 (Cloudflare): SQLite distribuído e gerenciado. Queries vão direto para o storage do Worker, sem pool de conexões.
• Turso: SQLite distribuído com replicação por região.

Optamos pelo D1 pela integração nativa com Workers. Você define o schema localmente, executa as migrações com wrangler d1 migrations apply, e as queries rodam no mesmo data center que o Worker.

CREATE TABLE proposals (
  id TEXT PRIMARY KEY,
  user_id TEXT NOT NULL,
  client_name TEXT NOT NULL,
  content TEXT NOT NULL,
  status TEXT DEFAULT 'draft',
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE users (
  id TEXT PRIMARY KEY,
  email TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  proposals_count INTEGER DEFAULT 0,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

Problemas que apareceram:

• D1 não suporta todas as queries SQLite. ALTER TABLE com constraints complexas, RETURNING e algumas funções de janela não estão disponíveis. Teste com wrangler dev antes de subir.
• A latência de escrita é maior que a de leitura. O plano free prioriza consistência eventual. Para propostas comerciais, isso é irrelevante.
• Migrations funcionam, mas alterações em tabelas com muitos dados exigem planejamento.
• Muitos acessos com muita escrita as vezes é necessário fazer alguma distribuição com filas ou cache com key-value.

3.4 Cloudflare AI Gateway

A parte mais cara de um SaaS de IA não é infraestrutura, é a API de LLM. Cada chamada custa centavos de dólar, e centenas de chamadas por dia acumulam.

O AI Gateway funciona como um proxy entre o Worker e a API do LLM:

• Cache de respostas: se dois usuários geram propostas com o mesmo contexto, a resposta vem do cache.
• Rate limiting por usuário: no free, limitamos a 5 propostas/mês. O gateway aplica isso sem lógica extra.
• Observabilidade: latência, tokens, taxa de erro ficam logados automaticamente.

Fluxo de uma chamada de IA:

Requisição -> Worker -> AI Gateway -> Cache hit? Retorna resposta em cache
                                   -> Cache miss? LLM API -> Cache da resposta -> Retorna

O cache cortou cerca de 40% das chamadas reais ao LLM nas primeiras semanas. Muitos usuários testam com entradas parecidas.

3.5 Frontend: React + Vite + Cloudflare Workers

Frontend com React + Vite, hospedado no Cloudflare Worker. O free tier cobre 500 builds/mês e tráfego ilimitado em sites estáticos.

A comunicação com a API é via fetch tipado, aproveitando que Worker e frontend compartilham os mesmos tipos TypeScript:

// shared types
interface GenerateRequest {
  clientName: string
  projectDescription: string
  deliverables: string[]
  deadline: string
  paymentMethod: string
}

// client-side call
const response = await fetch('/api/proposals/generate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(request)
})

Um detalhe que fez diferença: o PDF é gerado client-side, com bibliotecas como @react-pdf/renderer ou html2canvas + jspdf. O Worker nunca aloca memória ou CPU para renderizar PDFs. O navegador do usuário faz isso.

4. O custo real

Depois de algumas semanas no ar, com dezenas de usuários ativos:

Componente	Serviço	Custo/mês
API / Backend	Cloudflare Workers (Free Tier)	R$ 0
Banco de dados	Cloudflare D1 (Free Tier)	R$ 0
Frontend / Hosting	Cloudflare Pages (Free Tier)	R$ 0
IA (LLM)	API externa (cache via AI Gateway)	~R$ 5 a 20
Domínio	Registro.br	~R$ 3,33/mês
Total		< R$ 25/mês

O único custo variável é o LLM. Ele escala com uso real, não com usuários cadastrados. Se alguém entra, se cadastra e não gera proposta, o custo é zero.

Isso não é para sempre. Quando escalar para milhares de usuários, o Workers free tier vai exigir upgrade (USD $5+/mês após 100k requisições/dia), e o D1 pode precisar do plano pago. Mas para validação de PMF, compra meses de experimentação.

5. O que aprendemos

Cinco coisas que levaríamos para o próximo projeto:

1. Debugging remoto em Workers é mais difícil. Wrangler tail ajuda.

Não existe SSH em um Worker. wrangler tail streama logs em tempo real da produção. Combine com logs estruturados (JSON com requestId, userId, latency).

2. Secrets, vars e bindings têm nuances.

Senhas de API vão em secrets. Configurações públicas em vars. Recursos como D1 ou KV em bindings (referências diretas no runtime). Secrets não são acessíveis via wrangler dev sem .dev.vars.

3. D1 não aceita tudo que SQLite aceita.

Uma migration que funcionava localmente quebrou no D1 porque usava ALTER TABLE ... ADD COLUMN com constraints que o D1 rejeita. Teste cada migration com wrangler d1 migrations apply --local.

4. AI Gateway poupou instrumentação.

Não precisamos implementar logging de tokens, cache ou rate limiting manual. O gateway já entrega tudo via variáveis de ambiente. Economizou dias.

5. Hono + Zod é uma boa combinação para APIs seguras no edge.

Validação na borda da requisição com tipos inferidos automaticamente elimina erros de runtime sem adicionar latência perceptível.

6. Conclusão

Construir no edge com Cloudflare Workers nos permitiu validar o produto sem o custo fixo de um SaaS tradicional. A stack é enxuta, o deployment é wrangler deploy, e a conta de infra não assusta.

Isso serve para todo SaaS? Não. Se você precisa de processamento pesado, filas complexas ou um banco com todas as features do PostgreSQL, a stack edge tem limitações. Mas para validação no Brasil, funcionou.

A ferramenta que construímos chama Propoza. Um gerador de propostas com IA para freelancers. O acesso é gratuito.

Se você já usou essa stack ou tem outra abordagem para SaaS de baixo custo no Brasil, deixa nos comentários. A ideia é trocar experiência, não vender tecnologia.