Desenvolvimento de aplicações web, SaaS e MVP

O que um projeto de aplicação web ou MVP inclui#

Moldamos o trabalho de acordo com o briefing real. A proposta indica quais destas entregas estão incluídas, quem fornece o quê e como cada uma é aprovada.

• Escopo da primeira versão: fluxo principal, perfis de acesso e o que fica para depois
• Telas principais desenhadas com estados vazios, de carregamento e de erro
• Modelo de dados, regras de acesso no servidor e testes que tentam quebrá-las
• Contas, perfis de acesso e convites para a equipe
• Pagamentos ou assinaturas confirmados por callbacks verificados do provedor
• Painel administrativo, eventos de análise de produto e monitoramento de erros
• Publicação, documentação e entrega do repositório e das contas

Aplicação web, site ou design de produto primeiro?#

Escolha esta opção quando clientes ou equipe precisam fazer login e concluir tarefas dentro do produto: comprar, agendar, enviar, aprovar ou gerenciar algo. Se você precisa de um site que explique e venda sua oferta, Desenvolvimento Web é a melhor opção. Se o fluxo ainda não está definido, comece pelo Design de Produto e desenvolva depois de testar as telas principais com usuários.

Como construímos uma primeira versão#

Começamos com uma fase de definição de escopo: os usuários e perfis, o único fluxo que a primeira versão deve concluir, os dados que cada etapa gera e as decisões que mudam o custo, como pagamentos, integrações e permissões. O resultado é um escopo por escrito, telas principais clicáveis e um plano de lançamento que indica o que fica para depois.

Em seguida, desenvolvemos em ciclos curtos em um ambiente de homologação que você pode usar. O primeiro marco é uma fatia enxuta do fluxo principal funcionando de ponta a ponta, com login real e regras de dados reais, antes de preencher as demais telas. O lançamento inclui monitoramento em produção, um caminho de rollback e a entrega do repositório, da hospedagem, do banco de dados e das contas de pagamento e análise em seu nome.

O que deve entrar na primeira versão de um MVP?#

A primeira versão precisa ter tudo o que um usuário real necessita para concluir um fluxo, e nada que só importe em uma escala que você ainda não alcançou. Na prática, são cinco coisas: contas com os perfis que o fluxo exige, o próprio fluxo principal, um painel administrativo para sua equipe ver e corrigir registros sem depender de um desenvolvedor, pagamentos se o modelo de negócio cobra desde o primeiro dia e eventos de análise que mostram onde os usuários desistem.

Deixe para depois o que pode ser feito manualmente ou adquirido mais tarde: um aplicativo mobile nativo, login único (SSO) para clientes corporativos, uma matriz de permissões configurável, uma segunda integração, chat dentro do app e relatórios que ninguém pediu. Cada item adiado ainda ganha uma linha no escopo, para que o modelo de dados deixe espaço para ele.

A maioria dos produtos é montada a partir de módulos conhecidos. Dois merecem destaque: agendamento e um funil de leads para uma pequena empresa que hoje controla os contatos manualmente. Ambos parecem simples e escondem decisões sobre fusos horários, status e responsabilidades que custam menos quando resolvidas no papel.

Qual stack a Dardo usa, e quando escolhe outra?#

Nosso padrão é TypeScript de ponta a ponta: Astro para páginas renderizadas no servidor e ilhas interativas, Cloudflare Workers para hospedagem e APIs, Cloudflare D1 ou Postgres para dados e PostHog para análises e experimentos. O Superame roda em Astro, com seu ranking armazenado no Neon Postgres. Uma só linguagem e um só destino de deploy mantêm um produto pequeno simples de operar e de entregar.

Escolhemos diferente quando o produto pede. Uma interface densa, que fica aberta o dia todo, pode justificar uma aplicação React no cliente, como no protótipo do Shiimain. Tarefas de longa duração, processamento pesado de dados ou uma equipe interna que já trabalha com outro framework também mudam a resposta. Se seus desenvolvedores vão manter o código após o lançamento, a stack deles geralmente prevalece.

O controle de acesso é a primeira coisa que testamos. O OWASP Top 10:2025 mantém o Broken Access Control em primeiro lugar e informa que todas as aplicações testadas tinham alguma forma dele. Aplicamos as permissões no servidor em cada requisição, negamos por padrão, limitamos cada consulta à organização do usuário logado e escrevemos testes automatizados que tentam ler os registros de outro cliente.

Como os pagamentos devem funcionar em um web app?#

Quem confirma um pagamento é o provedor de pagamento, no servidor; o navegador voltando do checkout nunca confirma. O Superame, um ranking público de projetos que faz parte do trabalho publicado da Dardo, mostra esse padrão. Os compradores pagam no checkout hospedado da Dodo Payments, então os dados do cartão nunca chegam ao app. Em seguida, o provedor envia um callback assinado, e o servidor verifica a assinatura e confere os dados do pagamento antes de adicionar o crédito.

Reembolsos e disputas seguem o mesmo caminho. Cada evento do provedor é aplicado uma única vez, então um callback que chega duplicado, atrasado ou fora de ordem não consegue adicionar nem remover crédito duas vezes. O Superame não divulga números de adoção nem de receita; ele serve como evidência de como a lógica de pagamento é construída, não de vendas.

• Um comprador que fecha a aba antes do redirecionamento recebe o crédito mesmo assim quando o callback chega.
• Um callback repetido ou falsificado é rejeitado.
• Um reembolso ou uma disputa reverte exatamente o que o pagamento original concedeu.
• Os limites do plano são verificados no servidor, e não apenas escondidos na interface.
• As chaves de teste e de produção são segredos separados e nunca ficam guardadas no repositório.

Deixe seus clientes usarem os próprios domínios#

Clientes de SaaS B2B muitas vezes querem o produto em um endereço próprio, como portal.theircompany.com. O Cloudflare for SaaS resolve isso com hostnames personalizados: os planos Free, Pro e Business incluem 100, cada hostname adicional custa US$ 0,10 e o máximo é de 50.000. Hostnames personalizados com curinga são exclusivos do Enterprise.

Seu cliente adiciona um registro CNAME apontando para o seu destino. Usar um registro A para apontar para esse destino, o que um domínio raiz exigiria, não é compatível por padrão, e o proxy no apex é um complemento do Enterprise, por isso a maioria dos clientes deve usar um subdomínio. Os certificados são validados por HTTP, TXT ou e-mail, ou com Delegated DCV, um registro único que permite ao Cloudflare renová-los automaticamente. Eles são emitidos pela Let's Encrypt, Google Trust Services ou SSL.com.

O trabalho de produto ao redor é tão importante quanto: só planos pagos podem conectar um domínio, uma tela de onboarding mostra o registro exato a ser adicionado, o status de verificação explica em linguagem simples os estados pendente e com falha, e o monitoramento avisa sua equipe quando um certificado não consegue renovar porque um cliente alterou o DNS. Outras hospedagens definem limites diferentes: a Vercel permite 50 domínios por projeto no Hobby e ilimitados no Pro e no Enterprise, com limites flexíveis de 100.000 e 1.000.000; a Netlify recomenda no máximo 50 aliases de domínio por site.

Dúvidas antes de escolher#

Do blog#

• Domínios personalizados para SaaS: deixe seus clientes usarem o próprio domínio com o Cloudflare for SaaS

  Deixe seus clientes apontarem o próprio domínio para o seu SaaS com o Cloudflare for SaaS: como funciona a validação, quanto custa em outubro de 2026 e onde dá problema.