No-code, low-code ou sob medida: qual caminho serve para o seu MVP (e a conta real de cada um)
Gabriela Dionelli · · 7 min de leitura
Você tem uma ideia, pediu uns orçamentos e recebeu respostas que parecem vir de planetas diferentes. De um lado, alguém disse que monta isso no Bubble em duas semanas por R$ 6 mil. Do outro, uma empresa falou em quatro meses e R$ 90 mil. Você olha os dois números e não sabe se o primeiro é bom demais para ser verdade ou se o segundo está te empurrando coisa a mais. Provavelmente nenhum dos dois está mentindo. Eles estão respondendo perguntas diferentes, porque ninguém te explicou que existe mais de um caminho para construir a primeira versão de um produto.
Respira. Vamos por partes.
A pergunta certa não é "no-code ou sob medida"
Quase todo fundador de primeira viagem faz a escolha pelo lado errado: escolhe a ferramenta antes de saber o que o produto precisa fazer bem. A pergunta certa é: qual parte do seu produto é o motivo pelo qual alguém vai voltar amanhã?
Todo produto tem uma parte que é o diferencial e um monte de partes que são encanamento. Cadastro, login, listagem, painel de admin, envio de e-mail, upload de foto: isso é encanamento. Já existe pronto no mundo inteiro e ninguém nunca escolheu um produto por causa disso. O diferencial é a parte que só o seu produto faz, e é a única que justifica pagar caro.
A regra prática é simples: encanamento você resolve com a ferramenta mais barata que funcionar. Diferencial você constrói com controle. A decisão entre no-code, low-code e sob medida cai quase sempre em cima dessa divisão, e não em cima de preferência técnica.
Os três caminhos, sem marketing, com preço e prazo
Antes de comparar, uma definição rápida em português claro.
- No-code: você monta o produto arrastando blocos em uma plataforma (Bubble, FlutterFlow, Softr, Glide, Airtable). Não existe código seu. O produto roda dentro da plataforma.
- Low-code: parte é montada em ferramenta visual, parte é código de verdade. Um caso comum é banco de dados e autenticação em um serviço gerenciado, com uma camada de código próprio para as regras que importam.
- Sob medida: código escrito para o seu caso, rodando na sua infraestrutura, com o repositório na sua conta.
| Caminho | Investimento inicial | Custo mensal | Prazo até a primeira versão |
|---|---|---|---|
| No-code (você mesmo monta) | R$ 0 a R$ 3.000 | R$ 150 a R$ 800 | 2 a 5 semanas |
| No-code (com especialista contratado) | R$ 8.000 a R$ 30.000 | R$ 300 a R$ 1.500 | 3 a 8 semanas |
| Low-code / híbrido | R$ 20.000 a R$ 60.000 | R$ 500 a R$ 2.500 | 6 a 12 semanas |
| Sob medida | R$ 45.000 a R$ 150.000 | R$ 800 a R$ 4.000 | 10 a 18 semanas |
Esses números sobem ou descem por motivos concretos: app nas duas lojas em vez de web, pagamento dentro do produto, integração com sistema de terceiro, dado sensível sob LGPD, e principalmente quantidade de telas. Escopo é o que move o preço, não a tecnologia.
Cinco perguntas que decidem o seu caminho
Responda na ordem. Cada uma custa R$ 0 e elimina uma opção.
- Alguém paga dentro do produto? Se o dinheiro passa por dentro (checkout, assinatura, split entre vendedores), no-code puro começa a doer rápido. Dá para fazer, mas você fica preso ao que a plataforma permite no gateway, no reembolso e na conciliação. Se o pagamento é fora (você cobra por Pix, por boleto, por contrato), no-code resolve tranquilo.
- O software é o produto ou é o apoio? Se você vende consultoria, evento, curso ou serviço e o sistema só organiza a operação, no-code costuma ser suficiente por bastante tempo. Se o software é o que você vende, ele vai precisar de controle mais cedo.
- Existe uma regra de negócio que é o seu diferencial? Um algoritmo de matching, um cálculo proprietário, uma lógica de precificação, tempo real de verdade. Essa parte específica raramente cabe bem em no-code, mesmo que todo o resto caiba.
- Precisa estar na App Store e na Google Play? Existem caminhos no-code que publicam nas lojas, mas a taxa de rejeição e a dor de manutenção sobem. Se o seu público usa o produto pelo celular de forma ocasional, web responsivo resolve na primeira versão e economiza semanas.
- Quantas pessoas vão usar nos primeiros seis meses, de verdade? Não o sonho, o realista. Abaixo de algumas centenas de usuários ativos, quase nada quebra em nenhum dos caminhos. Escolher sob medida por medo de escala que ainda não existe é o jeito mais caro de errar.
Se você respondeu "não" para a 1, a 3 e a 4, comece no-code. Sem culpa. Seu primeiro produto não precisa ser perfeito. Precisa existir.
As armadilhas que queimam dinheiro nessa escolha
1. Construir sob medida por vaidade
É a mais cara de todas. O fundador quer dizer que "tem uma plataforma própria" e gasta R$ 80 mil em um produto que ninguém pediu ainda. O caso real é sempre parecido: seis meses depois, o sistema está pronto, bonito, e tem doze usuários. O dinheiro que resolveria isso deveria ter ido para descobrir se alguém queria.
2. Colocar o diferencial dentro da caixa preta
O oposto também acontece. O fundador monta tudo em no-code, inclusive a parte que é o coração do negócio, e descobre depois que a plataforma não deixa fazer exatamente aquilo do jeito que precisa. Aí não tem ajuste: tem migração. Encanamento em no-code, diferencial sob controle.
3. Ignorar o custo de saída
Pergunte antes de começar: se eu quiser sair daqui em um ano, o que eu levo comigo? Em no-code, a resposta honesta costuma ser "os dados, se a exportação for decente, e nada mais". Isso não é motivo para não usar. É motivo para não deixar o seu banco de dados morar só lá dentro e para não assinar contrato longo achando que é para sempre.
4. Achar que no-code dispensa quem entende de produto
A ferramenta tira o código do caminho, não a modelagem. Se a estrutura de dados nasce torta, o problema aparece igual, só que mais tarde e mais difícil de arrumar. A maior parte dos MVPs no-code que travam não travam por limite da plataforma, travam porque ninguém pensou em como os dados se relacionam antes de sair arrastando bloco.
Quando chegar a hora de construir com controle
A OCA construiu o Revo, uma plataforma própria de descoberta e venda de ingressos para eventos, com mais de 40 mil usuários cadastrados e mais de 300 eventos por mês. O checkout é nosso, e converte a 90%. Esse número não existiria em cima de um checkout de prateleira, porque cada campo removido, cada tela economizada e cada ajuste de tempo de resposta saiu de teste em cima de gente real comprando ingresso. Essa parte precisava ser sob medida.
O restante da operação do Revo tem pedaço rodando em ferramenta pronta até hoje, porque não faz sentido reescrever o que já funciona. É essa a conversa honesta: a maioria dos produtos é uma mistura, e o trabalho bem feito é decidir onde cada real vai. Quando chega a hora de tirar o diferencial da caixa preta, é isso que a gente faz, e dá para ver os produtos que já colocamos em produção antes de decidir qualquer coisa.
O próximo passo, ainda esta semana
Pegue uma folha e escreva as telas do seu produto. Todas. Depois marque com um X só as que precisam existir para a primeira pessoa conseguir usar de ponta a ponta. O que sobrou sem X não entra na primeira versão. Agora olhe a lista com X e pergunte: tem alguma regra aqui que nenhuma ferramenta pronta faz do meu jeito? Se não tem, seu MVP é no-code e você pode começar segunda-feira. Isso você consegue validar essa semana, sem gastar nada.
Se tem, vale conversar sobre como construir só essa parte direito e deixar o resto barato.
