Como criar um software quando você não é o programador: o framework de decisão para o fundador não-técnico

Quatro decisões em ordem, cinco perguntas para escolher o caminho, e o que muda quando o software vai para um cliente que paga.

Em uma reunião de quarta-feira passada, um fundador chegou com um caderno aberto, uma planilha cheia de cores, e uma frase: “preciso criar um software”. Vinha da operação. Tinha resolvido uma planilha enorme com automações no Google Sheets. A planilha tinha quebrado três vezes naquele mês. Os clientes começaram a perceber. Ele estava em dia com o problema do negócio. Estava perdido em como construir o software.

A pergunta “como criar um software” tem uma resposta diferente dependendo de quem pergunta. Um desenvolvedor que está aprendendo precisa de um tutorial: escolha uma linguagem, monte o ambiente, escreva código, teste, publique. Para o fundador não-técnico, criar um software não é programar. É tomar quatro decisões em ordem antes de qualquer linha de código existir. Quem confunde as duas coisas começa pelo lado errado, contrata pelo motivo errado, e seis meses depois tem dois mil reais por mês de servidor rodando algo que ninguém usa.

Este artigo é o framework que usamos com fundadores não-técnicos quando eles chegam com a planilha estourada, a contratação assinada com prazo, ou o investidor pedindo o protótipo. Quatro decisões. Cinco perguntas. Um documento de uma página.

As quatro decisões antes de começar

Existe uma sequência. Ela importa. Tomar a quarta decisão antes da primeira é a forma mais comum de queimar três meses e o orçamento da rodada pré-seed.

Decisão 1, escopo real. O que você precisa que funcione no primeiro dia para o primeiro cliente que paga? Não o que seria bom ter. Não o que o investidor mencionou. O conjunto mínimo de telas e ações sem o qual a primeira venda não acontece. A regra prática: se você consegue descrever o software em três frases e cinco telas, está perto. Se você tem 47 user stories no Notion, ainda não pensou o suficiente.

Decisão 2, caminho. Build vs buy vs no-code vs híbrido. Cada um tem um perfil de custo, um teto de funcionalidade, e um tipo de pessoa que precisa estar do seu lado para funcionar. Voltaremos a isso na próxima seção.

Decisão 3, parceiro. Quem vai construir. Freelancer, software house, contratação interna, ou plataforma no-code com um implementador. Esta decisão depende da decisão 2. Não comece por ela.

Decisão 4, contrato e orçamento. Como o trabalho fica acordado. Preço fechado, time and materials, equity, sprint pago. Como o dinheiro sai e o que conta como entregue. Esta decisão depende das três anteriores.

A maior parte dos fundadores não-técnicos que vemos tenta começar pela decisão 3. “Conhece um bom desenvolvedor?” é a pergunta errada antes da decisão 1 estar resolvida. Bom para quê.

Como decidir o caminho: build, buy, no-code, ou híbrido

A decisão 2 é a que mais carrega o resto. Ela define para quem você liga, qual vai ser o orçamento, e que tipo de problema você vai descobrir no caminho.

Buy. Já existe um software pronto que faz 80% do que você precisa. Pipefy para fluxo de tarefas, RD Station para CRM básico, Bling para gestão. Buy é a resposta certa quando seu diferencial competitivo não está no software em si. Você é uma operação imobiliária que precisa de um CRM, não uma proptech construindo o CRM do mercado. Comprar é mais rápido, mais barato no primeiro ano, e libera você para focar no que de fato diferencia o negócio.

No-code. Bubble, Glide, Softr, Retool com módulos. Funciona quando o fluxo de trabalho é claro, o volume é baixo (até alguns milhares de transações por mês), e o software ainda não é o produto que o cliente paga. No-code é a forma mais barata de validar uma ideia. É também o caminho que mais gente sai em flames depois, normalmente entre o primeiro contrato relevante e a Série A. O artigo sobre discovery de produto para fundador não-técnico mostra como usar no-code para validar sem se prender.

Build. Software sob medida, escrito para o problema específico. Faz sentido quando o software é parte do que o cliente paga, quando o volume já passou do que no-code aguenta sem virar caixa-preta, ou quando a regulamentação do seu setor (saúde, financeiro, jurídico) exige um nível de controle que ferramenta genérica não dá. Build é mais caro de começar e mais barato de manter quando bem feito. O artigo sobre quando contratar uma software house cobre como avaliar parceiros sem fingir profundidade técnica.

Híbrido. Quase todo software de empresa real é híbrido na prática. CRM comprado, ferramenta interna sob medida, integração via Zapier ou API. A pergunta híbrida certa é “qual parte é nossa vantagem competitiva e qual parte é commodity”. A vantagem competitiva você constrói. O commodity você compra. Misturar errado é caro: construir CRM do zero quando Pipefy resolveria, ou comprar uma ferramenta de risco quando seu modelo de risco É o produto.

A regra de bolso que aplicamos: se o software vai estar na frente do cliente que paga e parte do produto que ele compra, build. Se é interno, transitório, ou em um domínio comoditizado, buy ou no-code com sigla de saída.

É possível criar um software sem programar?

Sim, em duas formas, e a confusão entre elas é cara.

A primeira é no-code. Você não escreve código, mas escreve regras: “quando o cliente preenche este formulário, salve aqui, mande este e-mail, mostre esta tela”. As regras viram o software. Funciona até um teto previsível: integração que a plataforma não suporta, volume que passa do plano, detalhe de design que o template não permite. O artigo sobre vibe coding vs agentic coding cobre como pensar essas escolhas em estágio.

A segunda forma é contratar quem programa por você. O “sem programar” é literal, mas o fundador continua dono da decisão de escopo, da revisão das entregas, e da resposta a “isso é o que o usuário precisa, isso não é”. Quem terceiriza a decisão de produto para o desenvolvedor termina com um software que satisfaz o desenvolvedor, não o cliente.

A terceira forma, a que não funciona, é achar que ferramentas de IA generativa vão “criar o software” do briefing. Elas escrevem código. Não tomam decisões de produto, não testam contra o cliente real, e não respondem por erro em produção.

Quanto custa criar um software, na prática

A faixa varia em uma ordem de grandeza. Buy entrega algo funcionando em horas, custa entre cem e mil reais por mês de assinatura, e o trabalho do fundador é configurar e treinar o time. No-code entrega o primeiro fluxo em uma a quatro semanas, custa entre quatrocentos e quatro mil reais por mês de plataforma mais um implementador (entre cinco e quinze mil reais para o primeiro setup), e exige que alguém da casa, você ou um operador, mantenha as regras vivas. Build entrega a primeira versão em três a seis meses, custa entre oitenta mil e trezentos e cinquenta mil reais para um MVP de software sob medida bem escopado, e exige um fluxo de revisão semanal entre fundador e parceiro de engenharia. Para a faixa completa por driver, o artigo sobre quanto custa desenvolver um app abre os seis fatores que mais movimentam o número.

A faixa não é o problema. O problema é começar build sem orçamento de build, ou começar no-code achando que vai ficar barato para sempre. O custo total de propriedade do no-code em três anos costuma ultrapassar o custo de um build bem feito quando o volume passa de algumas centenas de transações por dia. O custo total do build mal escopado em seis meses ultrapassa o de qualquer plataforma comprada disponível.

Como criar um software passo a passo, do zero

“Criar um software do zero”, para o fundador não-técnico, não é abrir um editor de código vazio. É começar uma sequência de decisões que termina em um software rodando para um cliente que paga.

Semana 1. Escreva em uma página o que o software faz, para quem, qual a ação que o cliente faz nele, as cinco telas mínimas, e o que NÃO está na primeira versão. Esta página é a sua primeira versão de PRD para fundador não-técnico e vai mudar três vezes nas próximas duas semanas.

Semana 2. Mostre o documento para cinco potenciais clientes. Não venda. Pergunte o que falta, o que sobra, o que é confuso. Cada cliente que diz “isso seria útil” sem se comprometer com pré-pagamento é sinal fraco. Cada cliente que diz “se isso existir hoje eu pago” é o sinal que move o projeto.

Semana 3. Decisão de caminho. Com a página atualizada e cinco conversas no bolso, tome a decisão 2 com critério: qual parte é diferencial competitivo, qual é commodity, qual o orçamento real, qual o prazo até o primeiro cliente.

Semana 4. Decisão de parceiro. Três conversas com candidatos do caminho escolhido. Para build, três software houses ou um a dois desenvolvedores sêniores. Para no-code, dois implementadores especializados na plataforma. Para buy, duas demos com os fornecedores e duas conversas com clientes deles. Compare propostas com o documento de uma página na mão.

Semanas 5 a 12. Primeira versão. O trabalho do fundador é manter a página viva, revisar entregas semanais, e desbloquear decisões. Cortar escopo é seu trabalho. Adicionar escopo é o erro mais caro do estágio.

A sequência funciona para empresa, para startup pré-seed, para uma operação validando uma vertical, e para um time modernizando uma planilha que começou a quebrar. O que muda é a faixa de orçamento e a sofisticação do parceiro.

Cinco perguntas para escolher o caminho

Antes de assinar com qualquer parceiro, responda em uma frase cada uma:

1. Qual problema do cliente este software resolve, e quanto ele paga hoje para evitar este problema? Se a resposta é “ainda não sei”, você está em fase de discovery, não de build. Volte uma casa.
2. Em três anos, este software é parte do produto que o cliente compra, ou é uma ferramenta interna? Se é interno, o caminho começa em buy ou no-code. Se é o produto, build entra na conversa imediatamente.
3. Quanto da operação roda hoje em planilha, papel, ou na cabeça de uma pessoa? Quanto mais alto, maior o risco de tentar codificar um processo que ainda não está estável. Estabilizar primeiro, codificar depois.
4. Qual o orçamento real disponível para os próximos seis meses, contando manutenção pós-lançamento? Build sem reserva para os meses sete a doze é como mudar para uma casa que você só tem dinheiro para alugar metade. Vai dar errado nos detalhes.
5. Quem do time vai responder por este software depois que ele estiver no ar? Software sem dono na empresa quebra silenciosamente. Se a resposta é “o desenvolvedor que vou contratar”, o sistema é frágil por design.

As cinco respostas, escritas em três linhas cada, são o briefing técnico que diferencia uma conversa séria com um parceiro de uma reunião que termina com “vamos pensar e voltamos”.

Software como produto vs software como atalho

Antes da decisão 2, internalize a distinção que mais separa orçamento bem gasto de orçamento queimado.

Software como produto é o que o cliente acessa, contrata, paga assinatura, recomenda. É o produto da fintech, da healthtech, do marketplace vertical, do SaaS de nicho. Qualidade de engenharia aqui é vantagem competitiva. No-code é zona de validação, não destino. Subestimar o build aparece como churn, suporte caro, e impossibilidade de cobrar o preço que um produto bem feito sustenta.

Software como atalho é o que faz seu time ganhar tempo: ferramentas internas, dashboards, automações de back-office. A primeira versão pode ser muito mais simples. No-code costuma ser a resposta certa por mais tempo. O erro mais comum é construir do zero o que já existe pronto.

Confundir os dois custa caro. Construir CRM interno sob medida quando uma assinatura de cento e cinquenta reais por mês resolveria, e perder seis meses de equipe nessa peça. Ou tratar o produto principal da empresa como atalho, montar em no-code, e descobrir aos cento e cinquenta clientes pagantes que migrar é um projeto de oito meses na pior hora possível.

O documento de uma página, antes da primeira reunião

A peça que mais separa um briefing sério de uma conversa que custa caro é um documento simples. Ele cabe em uma página. Tem seis blocos:

Problema. O que dói no cliente, em uma frase.

Usuário. Quem usa o software, qual o cargo, qual o nível técnico.

Cinco telas mínimas. O fluxo essencial, na ordem.

Fora de escopo. O que NÃO está na primeira versão.

Métrica de sucesso. Como você sabe que funcionou. “Cliente A faz X em Y minutos” é mais útil que “aumentar conversão”.

Restrição. Orçamento, prazo, dependência regulatória, integração obrigatória.

Este documento não é um PRD completo, e nem precisa ser. Ele é a peça que permite que três conversas com três parceiros diferentes sejam comparáveis. Sem ele, cada parceiro define o escopo na própria proposta, cada proposta vira incomparável, e o fundador escolhe pelo carisma do vendedor. Com ele, a comparação fica honesta.

Por que a maioria dos primeiros softwares falha

Três motivos cobrem quase todos os fracassos que vemos, em ordem de frequência.

Escopo errado é o primeiro. O fundador construiu o software que ele descreveu, não o que o cliente precisava. Correção: a semana 2 da sequência, cinco conversas reais antes da decisão de caminho.

Parceiro errado é o segundo. Freelancer barato em momento errado, software house grande em momento errado, contratação de CTO em momento errado. Correção: casar a decisão 3 com a 2. Para no-code, um implementador. Para build de produto, uma software house competente ou um desenvolvedor sênior com revisão de código formal. Para buy, um operador interno que vai dominar a ferramenta.

Falta de dono interno é o terceiro. O software entra no ar, ninguém na empresa entende o suficiente para mantê-lo, e o sistema vai degradando até a próxima crise. Correção: decidir, antes de assinar, qual pessoa do time vai ser dona do software depois do lançamento. Se a resposta é “ninguém ainda”, o projeto não está pronto para começar.

Criar um software, para o fundador não-técnico, é menos sobre montar um time de engenharia e mais sobre tomar quatro decisões em ordem com informação suficiente. A primeira versão é menos importante do que a sequência.

Perguntas frequentes

O que é preciso para desenvolver um software?
Quatro decisões em ordem antes de qualquer linha de código: escopo mínimo, caminho (build, buy, no-code, ou híbrido), parceiro, e contrato. A semana 1 produz a página de uma folha. As três semanas seguintes refinam a página e escolhem caminho e parceiro.

É possível criar um software sem saber programar?
Sim, em duas formas: ferramentas no-code que escrevem regras em vez de código, ou contratar quem programa por você. Em ambos os casos, o fundador continua dono da decisão de escopo, da revisão do que foi entregue, e da resposta a “isso é o que o cliente precisa”.

Quanto custa produzir um software?
A faixa varia em uma ordem de grandeza. Buy custa entre cem e mil reais por mês de assinatura. No-code custa entre quatrocentos e quatro mil reais por mês mais o setup. Build custa entre oitenta mil e trezentos e cinquenta mil reais para um MVP bem escopado. Detalhe por driver no artigo sobre quanto custa desenvolver um app.

Como criar um programa de software passo a passo?
Quatro semanas: semana 1, escreva a página com problema e cinco telas; semana 2, mostre para cinco potenciais clientes; semana 3, decida o caminho; semana 4, fale com três candidatos do caminho escolhido. Da semana 5 em diante, mantenha a página viva e revise entregas semanais.

Qual o melhor caminho para criar um software grátis?
Grátis na prática quase nunca existe. No-code tem planos iniciais sem custo com limites estreitos. Código aberto tira a licença mas adiciona hospedagem e manutenção. Para validação sem orçamento, no-code com plano gratuito por trinta a noventa dias é o caminho mais comum, com clareza de que é zona de teste, não destino.