Quanto custa criar um produto SaaS

“Quanto custa criar um SaaS?” parece uma pergunta de orçamento. Na prática, ela mistura três perguntas diferentes: quanto custa descobrir se alguém quer o produto, quanto custa construir a primeira versão que já pode ser vendida e quanto custa manter essa versão funcionando depois. Essas três contas podem ter ordens de grandeza completamente diferentes.

Hoje é possível validar uma ideia gastando quase nada em infraestrutura. Também é possível colocar um pequeno SaaS em produção com uma conta mensal relativamente baixa de cloud. Nada disso responde quanto custa construir o produto. Porque banco de dados e hosting ficaram baratos. Complexidade continua cara.

A primeira versão pode custar muito pouco para existir

Essa foi uma das mudanças mais relevantes dos últimos anos. Você não precisa necessariamente começar um SaaS contratando servidor, configurando infraestrutura e construindo autenticação do zero. Serviços como Supabase já entregam banco de dados, autenticação, storage, API, funções e recursos de realtime. O plano gratuito atual inclui 500 MB de banco, 50 mil usuários ativos mensais, 1 GB de armazenamento e até dois projetos ativos. O Pro começa em US$25 por mês, com 8 GB de banco por projeto, 100 mil MAU e 250 GB de egress incluídos.

Do lado de deploy, a Vercel possui Hobby gratuito e Pro a partir de US$20 por mês. Existe uma ressalva importante: o Hobby é destinado a projetos pessoais e uso não comercial. Para um SaaS operando como negócio, o Pro é a referência mais apropriada, e os US$20 são o início da conta, com crédito de uso e cobrança adicional conforme os recursos consumidos.

Ferramentas de construção com IA também derrubaram bastante o custo para chegar à primeira versão. A Lovable, por exemplo, mantém um plano gratuito com 5 créditos de construção por dia, limitado a 30 no mês, além de créditos gratuitos específicos para Cloud. Isso significa que hoje dá para colocar algo funcional na mão de usuários sem começar com uma grande conta de infraestrutura. É uma mudança enorme.

Só não confunda:

consigo colocar no ar por pouco dinheiro

com:

consigo construir qualquer SaaS por pouco dinheiro.

São coisas diferentes.

Infraestrutura barata não significa SaaS barato

Imagine dois produtos.

Produto A

Um sistema em que a pessoa cria conta, cadastra clientes, gera propostas e exporta PDF.

Produto B

Uma plataforma em que uma organização possui várias unidades, cada usuário pode participar de várias organizações, existem papéis e permissões diferentes, pagamentos possuem múltiplos estados, há integrações externas, ações precisam de audit log, dados precisam ser isolados por empresa, existe cobrança recorrente e operações podem ser aprovadas por pessoas diferentes.

Os dois podem usar Supabase, Vercel, React e a mesma biblioteca de componentes. A fatura da infraestrutura inicial pode até ser parecida. O custo de desenvolvimento não será. A stack explica apenas uma parte pequena da diferença. O que encarece software é a quantidade de regras e estados que precisam continuar verdadeiros ao mesmo tempo.

Uma tela pode esconder semanas de diferença

“Precisamos de uma tela de usuários.” Quanto custa? Impossível responder ainda. Talvez seja:

listar usuários e convidar por e-mail.

Ou:

listar usuários, convidar, remover, suspender, alterar papel, restringir por unidade, controlar permissões individuais, exigir aprovação para determinados acessos e registrar todas as alterações em auditoria.

Visualmente, continua sendo “tela de usuários”. Tecnicamente e operacionalmente, são produtos diferentes. É por isso que quantidade de telas é uma unidade ruim para estimar SaaS. Tela é a manifestação visível. Grande parte do custo está nas regras por trás dela.

Estados são uma das maiores fontes invisíveis de escopo

Outro exemplo é assinatura. No desenho inicial:

paga
não paga

Parece suficiente. O objeto Subscription da Stripe possui atualmente oito estados possíveis: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid e paused. E cada um pode exigir comportamento diferente do produto.

O que o usuário pode fazer em past_due? O acesso é bloqueado imediatamente? Existe período de tolerância? O que aparece no produto durante trialing? O que acontece depois de incomplete_expired? Cancelar cobrança e cancelar acesso são a mesma coisa?

A Stripe conhece o estado do pagamento. Seu produto ainda precisa decidir o que aquele estado significa para o cliente. Isso é escopo. Não aparece quando alguém pede:

precisamos colocar assinatura.

Papéis e permissões também multiplicam decisões

Outro exemplo:

teremos administrador e usuário comum.

Parece uma pequena definição. Agora praticamente toda ação importante precisa responder: quem pode fazer, quem pode ver, quem pode editar, quem pode excluir, quem pode aprovar, quem recebe a notificação — e o backend também impede a operação ou apenas escondemos o botão?

Isso não significa que dois tipos de usuário dobram automaticamente todas as telas. Mas papéis adicionais aumentam o número de combinações que precisam ser consideradas. Em produtos B2B, essa diferença pode ser enorme, principalmente quando começam a aparecer unidades, departamentos, workspaces, papéis customizados, delegação, aprovação dupla e acesso temporário. “Permissões” deixa de ser uma página de configurações e vira uma propriedade do produto inteiro.

Multi-tenant também não é uma decisão para “resolver depois”

Num SaaS B2B, uma das perguntas mais importantes é: como os dados de uma organização são separados dos dados de outra? Esse problema precisa existir no modelo de dados, nas queries, na autorização, nas APIs, nas funções, na interface e nos testes.

Não existe uma regra dizendo que fazer isso cedo “custa uma tarde”. Dependendo do produto, pode ser uma parte relevante da arquitetura. O ponto é outro: descobrir tarde que o modelo inteiro assumia uma relação errada tende a ser muito mais caro que discutir essa relação antes. É exatamente o tipo de custo invisível tratado no artigo sobre como o design de produto reduz custo de desenvolvimento.

Integração também não tem preço pelo número de endpoints

“Tem integração com o ERP.” Isso pode significar:

fazemos um POST com cinco campos.

Ou autenticação OAuth, refresh token, webhooks, retries, rate limits, idempotência, sincronização bidirecional, eventos assíncronos, conciliação, tratamento de registros duplicados e monitoramento de falhas. Duas integrações podem consumir esforços completamente diferentes. Por isso:

quantas integrações tem?

é menos importante que:

o que precisa continuar consistente entre os dois sistemas?

Essa é a pergunta que revela o trabalho.

Então quanto custa construir?

Aqui está a parte frustrante da resposta: não existe uma faixa universal que eu considere responsável publicar. Você encontrará artigos dizendo:

MVP simples: R$ X a R$ Y.

SaaS intermediário: R$ Y a R$ Z.

O problema é definir “simples”. Um produto visualmente pequeno pode carregar pagamento, KYC, permissão, multi-tenancy, integração e auditoria. Outro pode ter trinta telas e ser basicamente um CRUD administrativo.

Também existe enorme variação entre fundador construindo, freelancer, estúdio, software house, squad interno, equipe no Brasil e equipe internacional. Dar uma faixa sem conhecer o escopo produz um número fácil de citar e difícil de defender. A pergunta que dá para responder é menor: quanto custa construir esta primeira versão específica?

A melhor unidade de orçamento é a primeira versão que já pode cobrar

Em vez de perguntar:

quanto custa construir meu SaaS?

eu fecharia primeiro:

qual é a menor versão pela qual alguém já teria motivo para pagar?

Isso muda completamente o exercício. Imagine uma plataforma de gestão de contratos. A visão de longo prazo tem IA, assinatura eletrônica, dashboard executivo, integrações, permissões avançadas, versionamento, alertas, workflow e app mobile. A primeira versão talvez precise apenas de cadastrar contrato, centralizar documentos, registrar vencimento, avisar responsável e mostrar o que precisa de atenção.

Agora existe algo que pode ser desenhado, estimado, construído, testado e vendido. O restante continua importante. Só não precisa ser financiado antes de sabermos se a primeira parte gera valor.

“O concorrente tem” é uma forma cara de definir MVP

Esse é um padrão comum. Alguém abre o concorrente mais estabelecido da categoria e faz uma lista: precisamos disso, disso também, e disso. O produto de cinco anos do concorrente vira requisito da versão 1.

Só que aquela empresa provavelmente construiu essas funcionalidades ao longo do tempo, para segmentos diferentes, respondendo a clientes reais, sobre uma infraestrutura que também evoluiu. Você está olhando o resultado acumulado. Não a sequência que produziu o resultado. Copiar tudo é financiar anos de aprendizado de outra empresa antes de descobrir se seus próprios clientes precisam das mesmas coisas.

Uma pergunta corta bastante escopo

Para cada funcionalidade da primeira versão: se isso não existir, o cliente ainda tem motivo suficiente para pagar? Se sim, talvez possa sair do primeiro release.

Não é uma regra perfeita. Alguma feature pode ser obrigatória por segurança, regulação, integração ou contrato, mesmo sem ser a razão principal de compra. Mas a pergunta força uma distinção saudável entre o que entrega valor agora e o que imaginamos que o produto precisará mais tarde. Essa separação costuma valer mais que negociar alguns pontos percentuais no orçamento do fornecedor.

E depois de construir, quanto custa operar?

Aqui aparece uma conta diferente. Ela possui pelo menos dois tipos de custo.

Custos relativamente fixos

Hosting, banco, domínio, ferramentas, observabilidade, e-mail, suporte, equipe.

Custos que crescem com uso ou receita

Compute, storage, transferência, APIs, IA, mensagens, processamento de pagamento, billing, suporte operacional.

É por isso que dizer:

meu SaaS custa US$45 por mês

quase nunca descreve a operação inteira. Pode descrever a soma inicial de duas assinaturas específicas. Só isso.

Pagamento merece uma conta separada porque cresce junto com a receita

Pegue a tabela padrão atual da Stripe no Brasil. Cartão nacional: 3,99% + R$0,39 por transação bem-sucedida. Stripe Billing, para gestão de assinaturas: 0,7% do volume processado pelo Billing.

Usando essas tarifas públicas apenas como exemplo, uma assinatura de R$99 paga por cartão nacional teria aproximadamente:

• 3,99% de R$99 = R$3,95

• taxa fixa = R$0,39

• Billing, 0,7% = R$0,69

• total aproximado = R$5,03

Isso corresponde a cerca de 5,1% do valor da assinatura. Não é um benchmark universal. Empresas podem ter preços personalizados, usar outro processador, outro meio de pagamento, outro sistema de billing. A utilidade da conta é mostrar que custo transacional cresce de forma completamente diferente da infraestrutura fixa inicial.

Ticket baixo sente mais a parcela fixa

Com a mesma simulação: em R$19/mês, o custo aproximado é R$1,28, cerca de 6,7% da cobrança. Em R$99/mês, R$5,03, cerca de 5,1%. Em R$499/mês, R$23,79, cerca de 4,8%.

A parcela fixa de R$0,39 pesa proporcionalmente mais conforme o ticket cai. Isso é uma das razões pelas quais modelo de monetização deveria entrar cedo na discussão de produto. Um SaaS de R$19 por mês não possui a mesma economia de um SaaS de R$499. Não é apenas o número na pricing page que mudou.

Meio de pagamento também altera a unidade econômica

Na tabela pública atual da Stripe no Brasil, Pix aparece a 1,19% por pagamento realizado. A disponibilidade e as condições precisam ser verificadas para cada operação e conta. Num pagamento de R$99, 1,19% corresponde a aproximadamente R$1,18. Isso é bem diferente dos aproximadamente R$4,34 da tarifa padrão de cartão antes de acrescentar Billing.

Não significa:

então todo SaaS deveria trocar cartão por Pix.

Recorrência, autorização, recuperação de falha, preferência do cliente e experiência de cobrança também entram na decisão. Mas significa que trilho de pagamento faz parte da economia do produto. Não deveria ser escolhido apenas porque foi o primeiro exemplo da documentação.

O custo de pessoas ainda tende a dominar a fase de construção

Cloud ficou barata. Escrever código também ficou mais rápido em vários contextos com IA. Só que uma parte significativa do trabalho continua sendo entender problema, definir regra, desenhar fluxo, modelar estado, tomar decisão, construir, testar, corrigir, operar e manter.

É aqui que duas equipes usando a mesma stack chegam a orçamentos muito diferentes. Uma recebeu:

quero um SaaS para gestão financeira.

A outra recebeu:

primeira versão para empresas de até 20 funcionários, com um administrador, uma conta por organização, importação bancária via integração X, categorização manual e fechamento mensal. Sem múltiplas unidades, sem aprovação e sem app mobile no primeiro release.

A segunda consegue estimar muito melhor. Não porque sabe mais de tecnologia. Porque existe menos coisa indefinida.

O orçamento melhora quando algumas decisões já foram tomadas

Antes de pedir preço, eu tentaria responder pelo menos:

Quem é o primeiro usuário?

Não “empresas”. Quem entra? Financeiro? Fundador? Operador? Administrador?

Qual tarefa justifica o pagamento?

O que precisa acontecer para a pessoa dizer:

isso me economiza dinheiro ou trabalho suficiente para valer a assinatura?

Quantos papéis existem na primeira versão?

Se houver vários, qual é a diferença real entre eles?

Como funciona organização e acesso?

Uma pessoa pertence a uma empresa? Pode pertencer a várias? Existem unidades?

Como o produto cobra?

Assinatura? Uso? Usuário? Volume? Pagamento único?

Quais integrações são realmente necessárias no lançamento?

Necessárias. Não desejáveis.

Quais estados críticos já conhecemos?

Erro, pagamento, permissão, cancelamento, processamento.

O que explicitamente fica de fora?

Essa última pergunta é indispensável. Um orçamento fica muito mais confiável quando existe fronteira.

Você também precisa de uma hipótese de preço

Eu não exigiria que o preço final estivesse decidido antes da primeira linha de código. Preço também pode ser testado. Mas deixá-lo completamente para o fim cria outro problema. Imagine um SaaS de R$19 que exige onboarding manual de uma hora, integração feita por pessoa, suporte frequente, processamento caro e várias ferramentas externas. Talvez a conta simplesmente não feche.

Por isso você deveria ter cedo pelo menos uma hipótese de ticket, modelo de cobrança, margem e tipo de cliente. O preço não precisa estar gravado em pedra. A economia precisa ser plausível.

O custo real aparece quando produto e modelo de negócio não combinam

Um produto barato por usuário pode funcionar muito bem quando aquisição é escalável, onboarding é self-service, suporte é baixo, infraestrutura cresce bem e uso é previsível. O mesmo preço pode ser péssimo se cada conta exige call de implantação, configuração customizada, integração, acompanhamento manual e suporte especializado.

Às vezes a feature não é cara. O modelo operacional em torno dela é. Essa é uma conta que nenhum framework frontend resolve.

Onde no-code e IA entram

Ferramentas de construção rápida são especialmente interessantes no primeiro estágio:

será que alguém quer isso?

Elas conseguem reduzir drasticamente o custo de transformar hipótese em algo utilizável. Só que o trade-off muda conforme surgem regras, volume, segurança, integrações, auditoria e operações críticas. É exatamente a discussão do artigo O que é no-code e quando ele para de servir. Uma ferramenta pode ser excelente para a primeira fase e inadequada para uma parte específica depois. Isso não torna a decisão inicial errada.

Então, afinal, quanto custa criar um SaaS?

A resposta útil é esta: o custo de infraestrutura para começar pode ser muito baixo. O custo de desenvolvimento depende principalmente da quantidade de comportamento, regra, estado e integração que a primeira versão precisa sustentar. E o custo de operar cresce de acordo com a arquitetura e o modelo de negócio.

É por isso que eu desconfiaria tanto de:

SaaS completo por R$ X.

quanto de:

qualquer SaaS precisa de R$ Y para começar.

Sem escopo, os dois números dizem pouco. Se você precisa pedir orçamento agora, troque:

Quanto custa criar meu SaaS?

por:

Quanto custa colocar esta primeira versão nas mãos deste tipo de cliente, com estas regras, para que eu já consiga cobrar?

Essa pergunta consegue produzir escopo. Escopo consegue produzir estimativa. E uma estimativa com fronteira vale muito mais que uma faixa de mercado inventada.

Depois vem a segunda conta:

quanto custa operar isso quando houver 10, 100 e 1.000 clientes?

Aí entram infraestrutura, pagamentos, atendimento, ferramentas e tudo que cresce com uso. São duas perguntas diferentes. Misturá-las é o que torna “quanto custa um SaaS?” praticamente impossível de responder. Separá-las transforma uma pergunta genérica numa decisão de produto.

E antes de fechar a primeira versão, vale testar também se a forma de cobrar combina com o produto que está sendo construído. Aqui tratamos do que testar numa página de preços de SaaS.

Fontes

Supabase. Pricing & Fees e documentação de billing. Em agosto de 2026, o plano Free inclui 500 MB de banco por projeto, 50 mil MAU, 1 GB de storage e até dois projetos ativos. O Pro começa em US$25 por mês e inclui, entre outros limites, 8 GB de banco por projeto, 100 mil MAU e 250 GB de egress.

Vercel. Pricing e documentação dos planos. Em agosto de 2026, o Hobby é gratuito e destinado a uso pessoal e não comercial. O Pro começa em US$20 por mês, inclui crédito de uso e permite consumo adicional conforme utilização.

Stripe Brasil. Preços e tarifas. Em agosto de 2026, a tabela padrão pública lista 3,99% + R$0,39 por transação bem-sucedida com cartão nacional e 1,19% por pagamento via Pix. Preços personalizados podem existir conforme volume e modelo de negócio.

Stripe Billing. Pricing. O modelo pay-as-you-go atual lista 0,7% do volume processado pelo Billing, incluindo transações recorrentes processadas dentro ou fora da Stripe e excluindo faturas avulsas.

Stripe API Reference. The Subscription object. O campo status possui atualmente oito valores possíveis: incomplete, incomplete_expired, trialing, active, past_due, canceled, unpaid e paused.

Lovable. Pricing. Em agosto de 2026, o plano Free oferece 5 créditos de construção por dia, até 30 por mês, além de concessões gratuitas específicas para Cloud e recursos de IA.