Desenvolvimento à medida ou no-code para SaaS: que caminho se adequa mesmo à sua ideia?

De poucas em poucas semanas alguém se senta à minha frente com uma ideia de SaaS e a mesma pergunta ansiosa: devo construir isto com uma ferramenta no-code para avançar depressa, ou pagar a programadores para o fazerem como deve ser? Quase sempre é apresentada como uma escolha moral: o caminho do fundador desenrascado contra o da empresa séria. Não é. É uma questão de timing, e acertar no momento vale muito mais do que escolher o lado 'correto'.

Vi fundadores desperdiçarem um ano a programar à mão uma ideia que ninguém queria, e vi outros baterem numa parede aos trezentos clientes porque a plataforma no-code em que apostaram não conseguia fazer a única coisa de que o negócio realmente dependia. Ambos os erros são caros. Ambos eram evitáveis. A diferença não foi o talento nem o orçamento, mas perceber em que cada caminho é genuinamente bom e ser honesto sobre a fase em que o produto estava na verdade.

Portanto, esta é a versão dessa conversa que eu teria consigo se me trouxesse a sua ideia hoje. Sem tribalismos, sem o esnobismo do género 'no-code é um brinquedo', sem disparates do tipo 'os verdadeiros fundadores escrevem código'. Apenas uma forma clara de decidir que caminho se adequa à sua ideia, agora mesmo, e como perceber quando é altura de mudar de faixa.

Provavelmente está a fazer a pergunta errada

O instinto é perguntar «o que é melhor, no-code ou código à medida?» — e essa pergunta não tem resposta, porque são ferramentas para trabalhos diferentes em momentos diferentes. É como perguntar se é melhor uma carrinha alugada ou um camião comprado. Depende inteiramente de estar a mudar de casa uma vez ou a gerir uma empresa de entregas.

A pergunta que tem mesmo resposta é: o que está a tentar aprender ou provar nos próximos três meses, e qual é a forma mais barata de o fazer? Para a maioria das ideias de SaaS no início, o que precisa de provar é que as pessoas vão pagar pela coisa, sequer. Quase nunca precisa de uma arquitetura bonita para aprender isso. Precisa de algo suficientemente real para pôr à frente de desconhecidos e observar o que fazem.

Assim que reformula desta maneira, a decisão fica muito mais serena. Não está a escolher a religião tecnológica permanente da sua empresa. Está a escolher o veículo certo para a distância concreta que precisa de percorrer este trimestre. Às vezes é um protótipo no-code que deitará fora de bom grado. Às vezes é uma verdadeira base de código desde o primeiro dia. Na maioria das vezes é uma sequência — e a sequência importa mais do que o ponto de partida.

Em que o no-code é genuinamente bom

Sejamos específicos, porque «no-code» tornou-se um slogan e os slogans escondem o pormenor útil. Quando digo no-code refiro-me a ferramentas que lhe permitem montar uma aplicação funcional — formulários, dados, lógica, pagamentos, uma interface usável — configurando em vez de programar. As modernas são muito mais capazes do que a reputação sugere. Há quem tenha negócios reais e rentáveis assentes nelas.

Onde brilham é na rapidez até um produto real e usável. Um fluxo que a um programador levaria quatro semanas pode levá-lo a si quatro dias. Pode mudar de ideias na terça e ter a nova versão no ar na quarta. Para uma ideia que ainda procura a sua forma, essa velocidade de iteração é a coisa mais valiosa que pode ter — muito mais valiosa do que código limpo, porque o que está a otimizar é a aprendizagem, não a engenharia.

• Validar se alguém vai pagar, antes de gastar dinheiro a sério a construir.
• Ferramentas internas — painéis, formulários de entrada, fluxos simples — onde o acabamento importa menos do que «funciona hoje».
• Uma primeira versão de um SaaS direto: registar-se, fazer um trabalho claro, cobrar por ele.
• Portais de cliente e fluxos do tipo marcação construídos sobre padrões que a plataforma já compreende.
• Tudo aquilo que pode mesmo vir a deitar fora dentro de seis meses, e em que não deve deitar dinheiro.

Há aqui também um ponto financeiro discreto. Um MVP no-code costuma custar uma fração de um à medida e está no ar numa fração do tempo. Se a ideia não pega, perdeu semanas e uma pequena fatura de subscrição, não um ano e um orçamento de seis dígitos. A economia é a estratégia. Permite-lhe errar de forma comportável — a competência mais subvalorizada na construção de seja o que for.

Onde o no-code bate, em silêncio, numa parede

Agora a outra metade, honesta. As plataformas no-code são notáveis até deixarem de o ser, e o ponto em que param costuma ser invisível até embater nele. O modo de falha não é «não consegue fazer nada» — é que faz noventa por cento de forma magnífica e depois recusa-se a fazer aqueles dez por cento concretos de que o seu negócio acaba por depender.

As paredes tendem a surgir em sítios previsíveis. Desempenho à escala — bem com cem utilizadores, lento com dez mil. Lógica invulgar — assim que a sua funcionalidade central é algo genuinamente inédito e não um padrão conhecido, está a lutar contra a ferramenta em vez de a usar. Integrações profundas — ligar à API peculiar de um parceiro, ou mover volumes reais de dados, é onde muitas plataformas chegam ao fim da estrada. E curvas de custo que se invertem: baratas em pequena escala e depois surpreendentemente caras quando tem sucesso, porque paga por registo ou por ação segundo as condições de outrem.

Nada disto é razão para evitar o no-code. É razão para entrar de olhos abertos sobre o que está mesmo a comprar: uma enorme velocidade inicial, em troca de um teto em que talvez um dia bata. Para um número enorme de produtos, nunca chega perto desse teto — e fingir que vai chegar, sobre-engenhando logo no primeiro dia, é o seu próprio erro caro.

O que o desenvolvimento à medida lhe compra na verdade

O código à medida tem a forma oposta. É mais lento e mais caro de iniciar, e exige mais de si à partida — requisitos mais claros, decisões a sério, dinheiro antes da prova. Em troca, dá-lhe algo que o no-code estruturalmente não consegue: nenhum teto e propriedade total. Seja o que for que o seu produto tenha de se tornar, o código consegue tornar-se. A restrição é o seu orçamento e a sua imaginação, não o roteiro de uma plataforma.

A outra coisa que compra é o controlo sobre o que se torna sério à medida que cresce: como os seus dados são armazenados e protegidos, como o sistema se comporta sob carga, como se integra com tudo o resto, como cumpre as regras que o seu setor lhe impõe. São exatamente as preocupações que parecem abstratas com dez clientes e se tornam existenciais com dez mil. Construir à medida significa que são suas para desenhar, não suas para descobrir os limites.

Mas — e isto importa — o à medida só vale a pena quando tem algo digno de lá despejar. Escrever uma base de código cuidada e escalável para uma ideia que não validou é a clássica tragédia do fundador: uma bela máquina, perfeitamente engenhada, que ninguém pediu. O desenvolvimento à medida premeia a convicção. Se ainda não tem prova de que as pessoas querem a coisa, está a comprar uma precisão que não mereceu.

Um modelo para decidir agora mesmo

Eis como o guiaria a sério. Não um fluxograma que finge que a vida é arrumada — um punhado de perguntas honestas, por ordem, que tendem a resolver a questão mais depressa do que qualquer comparação de funcionalidades.

1. 1
   As pessoas já provaram que querem isto?

   Se tem clientes pagantes ou uma lista de espera, pode justificar o à medida. Se ainda é uma hipótese, incline-se para o no-code e prove-o primeiro a baixo custo.
2. 2
   A sua funcionalidade central é vulgar ou genuinamente inédita?

   Se o coração do seu produto é um padrão comum (formulários, marcações, painéis, faturação simples), o no-code voará. Se é algo que ninguém fez bem assim, o código dá-lhe margem que a plataforma não dará.
3. 3
   Quão grande precisa de chegar a ser para funcionar?

   Uma ferramenta para um nicho de 500 empresas pode viver feliz em no-code para sempre. Um produto que aponta a centenas de milhares de utilizadores deve planear o código mais cedo.
4. 4
   O que acontece se tiver de reconstruir mais tarde?

   Se uma futura reconstrução fosse um passo gerível e planeado, o no-code é um começo de baixo risco. Se uma reconstrução fosse ruinosa, construa-o bem à primeira.
5. 5
   Seja honesto sobre o que está a otimizar

   A otimizar para aprender? No-code. A otimizar para a longevidade e a escala de um produto comprovado? À medida. A maioria dos fundadores está no primeiro grupo e finge estar no segundo.

Se passar uma ideia por estas cinco perguntas e as respostas apontarem em direções diferentes, isso não é um problema — é informação. Costuma significar que está num ponto de transição, e a jogada certa é a híbrida em que quase ninguém se lembra de pensar: começar em no-code, manter as junções limpas e planear migrar as partes que importam quando a prova chegar.

O caminho que a maioria dos fundadores de sucesso realmente segue

Eis o que a oposição «à medida ou no-code» esconde: em muitos dos melhores resultados que vi, a resposta foi ambos, por ordem. No-code para descobrir se a ideia tem pernas para andar, depois à medida para construir a coisa a sério assim que tem. O erro não é escolher um — é escolher um e depois recusar-se a largá-lo quando a situação muda.

Fase um: prove-o a baixo custo

Use no-code, ou até uma primeira construção propositadamente tosca, para pôr algo de real à frente de utilizadores pagantes depressa. O seu único objetivo aqui é a prova. As pessoas registam-se? Voltam? Vão pagar? Está a comprar respostas e quere-as o mais baratas possível, porque a maioria das ideias precisa de várias rondas de erro antes de estar certa.

Fase dois: construa bem a coisa comprovada

Assim que tem tração real — clientes que ficariam incomodados se desaparecesse —, as contas invertem-se. Agora o teto, o aprisionamento e os custos de escala do no-code começam a importar, e o custo do desenvolvimento à medida é justificado por um produto que sabe que as pessoas querem. É a altura certa para investir em algo construído para durar, porque agora não está a apostar. Está a proteger algo que já funciona.

Os erros que mais custam

Depois de muitas destas conversas, os padrões de fracasso tornam-se familiares. Dois deles fazem a maior parte do estrago, e são imagens espelhadas um do outro.

O primeiro é construir a mais cedo demais: contratar programadores e encomendar uma plataforma escalável e à prova de futuro para uma ideia que nunca encontrou um cliente pagante. Parece responsável. Na verdade é a forma mais cara possível de descobrir que a sua ideia precisava de mudar — porque agora cada pivô significa reescrever código pago caro. O segundo é agarrar-se ao no-code tempo demais: bater na parede à escala real, com clientes reais a depender de si, e só então começar a reconstrução que devia ter iniciado meses antes — sob pressão, enquanto a plataforma geme.

Ambos vêm de tratar a escolha como permanente. Os fundadores que se saem bem tratam-na como uma fase. Escolhem a ferramenta mais barata que responde à pergunta deste trimestre, e estão emocionalmente dispostos a ultrapassá-la. Essa disposição — começar à desenrasca e investir a sério quando chega a altura — vale mais do que qualquer decisão de plataforma que venha a tomar.

Perguntas frequentes