Escolher uma stack tecnológica para o seu primeiro SaaS: um guia honesto para fundadores

Pergunte a dez engenheiros que stack tecnológica deve usar para o seu primeiro SaaS e obterá quinze respostas, três delas proferidas com a certeza de uma religião. A maioria dessas respostas está certa, para quem as dá. Nenhuma diz respeito a si, à sua margem de manobra ou aos clientes que ainda não conquistou. Se é fundador, a olhar para esta decisão e a sentir-se ligeiramente mal, eis o que ninguém diz em voz alta: a stack importa muito menos do que o levaram a crer, e as poucas formas em que importa não são aquelas sobre as quais se discute online.

Ajudei bastantes fundadores estreantes a passar de uma apresentação de slides para um produto pelo qual pessoas reais pagam. Quase nenhum era técnico. Quase todos chegaram já tendo absorvido uma quantidade assustadora de folclore sobre stacks: que precisavam de microsserviços, que uma dada framework estava "morta", que escolher mal os condenaria. E quase sempre a stack acabou por ser uma das decisões menos determinantes que tomaram nesse ano. O que matava os projetos era o âmbito, a falta de responsabilidades claras e construir lindamente a coisa errada. Nunca a framework.

Por isso, este é o guia que dou a esses fundadores antes de escrevermos uma única linha de código. Não lhe dirá para usar uma stack específica, porque quem o promete sem conhecer o seu negócio está a vender-lhe algo. Em vez disso, dar-lhe-á uma forma de pensar, para que, seja o que for que escolha, ou seja o que for que a sua equipa proponha, possa avaliá-lo com bom senso, como um adulto, em vez de acenar nervosamente.

Porque esta decisão parece mais difícil do que é

A questão da stack parece enorme porque é a primeira escolha de aparência irreversível que faz, e vem embrulhada numa língua que não fala. Palavras como Postgres, React, Kubernetes, serverless são lançadas como se escolher entre elas fosse como escolher os alicerces de um edifício: engana-se e tudo desaba.

Mas o software não é um edifício. Assemelha-se muito mais a uma cozinha que se pode remodelar enquanto se continua a cozinhar. As empresas bem-sucedidas reescrevem partes da sua stack constantemente; a versão de um produto que encontra os primeiros cem clientes quase nunca é a que serve os primeiros cem mil. O objetivo da sua primeira stack não é durar para sempre. É permitir-lhe construir, mudar e lançar com rapidez suficiente para descobrir se alguém quer isto sequer. É uma fasquia totalmente diferente, e muito mais baixa, do que "perfeita para a próxima década".

Assim que aceitar isto, a pressão reduz-se a metade. Já não está a tentar prever o futuro. Está a tentar fazer uma aposta razoável e reversível que o leve a um produto que funciona e a utilizadores pagantes. E as apostas razoáveis são algo que um fundador não técnico consegue perfeitamente avaliar.

O que é realmente uma "stack", em termos simples

Antes de decidir o que quer que seja, ajuda desmistificar a palavra. Uma stack tecnológica é apenas o conjunto de ferramentas usadas para construir e fazer funcionar o seu software. Pode pensar nela em quatro camadas, e não precisa de compreender nenhuma em profundidade: basta-lhe saber que existem.

• O frontend: o que os utilizadores veem e clicam no navegador ou na aplicação. É a parte por que todos o julgam.
• O backend: a lógica e as regras que correm num servidor: quem pode fazer o quê, o que acontece quando o faz, como o dinheiro circula.
• A base de dados: onde a sua informação realmente reside: utilizadores, encomendas, subscrições, tudo o que lhe seria devastador perder.
• A infraestrutura: os servidores e serviços que mantêm tudo o acima online, com cópias de segurança e acessível às 3 da manhã.

Quando alguém diz "vamos usar uma stack moderna de JavaScript" ou "Rails sobre Postgres", está a descrever escolhas ao longo destas quatro camadas. É tudo. Todo o SaaS, de um projeto paralelo de duas pessoas a uma empresa cotada, é alguma versão destas quatro coisas empilhadas. Os pomposos diagramas de arquitetura são exatamente isto, desenhados com mais caixas.

As coisas que importam realmente (e as que não importam)

É aqui que a maioria dos conselhos sobre stacks falha: otimizam coisas que não afetam os seus dois primeiros anos e ignoram aquelas que afetam. Deixe-me ser franco quanto a ambas as listas.

O que importa realmente

Quem a consegue construir e manter. O fator de longe mais importante não é a tecnologia: são as pessoas. A melhor stack para si é aquela em que a sua equipa (ou o parceiro que contratar) consegue realmente trabalhar, com à-vontade, hoje. Uma stack "perfeita" que só um raro especialista compreende é uma pior escolha do que uma aborrecida que qualquer programador competente consegue retomar. Contratação e continuidade ganham sempre à elegância teórica.

Com que rapidez consegue mudar as coisas. No início, vai estar constantemente enganado quanto ao seu produto. O verdadeiro trabalho da stack é tornar barato mudar de ideias. Ferramentas maduras, bem documentadas e com grandes comunidades fazem-no avançar depressa, porque as respostas aos seus problemas já existem. As ferramentas de ponta tornam-no a pessoa que descobre os erros.

Se consegue contratar para ela. Escolha algo obscuro e prende o seu futuro a quem a construiu. Escolha algo comum e aborrecido e poderá sempre encontrar o próximo programador, a próxima agência, a próxima pessoa para assumir. Aborrecido é uma virtude quando o seu negócio depende disso.

O que importa muito menos do que se diz

O desempenho puro e a "escala". Não tem um problema de escala. Tem um problema de ninguém-a-usa-ainda, que é o problema oposto. Arquiteturas concebidas para milhões de utilizadores irão atrasá-lo quando tiver onze. As famosas empresas que imita construíram primeiro a versão simples e reconstruíram-na mais tarde, financiadas pelo sucesso. Você também deveria.

Que framework específico está a "ganhar" este ano. As frameworks sobem e descem num ciclo de moda que quase nada tem a ver com a capacidade de construírem bem o seu SaaS de faturação. Qualquer das opções convencionais e largamente usadas fará o trabalho. A tendência é ruído; escolha do meio aborrecido e popular e siga em frente.

Porque a tecnologia "aborrecida" geralmente vence

Há uma sabedoria discreta entre os construtores experientes que os recém-chegados acham desiludente: a melhor tecnologia para um novo negócio é geralmente a aborrecida, comprovada e ligeiramente fora de moda. Não porque as ferramentas novas sejam más, mas porque cada escolha que faz gasta um orçamento limitado de novidade: o número de coisas desconhecidas, sem suporte e surpreendentes que a sua pequena equipa consegue gerir de uma vez.

Gaste esse orçamento naquilo que torna o seu negócio especial: o produto em si, a perceção que só você tem. Não o gaste numa base de dados de que ninguém ouviu falar só para se sentir moderno. Uma stack aborrecida e madura significa que os problemas já foram resolvidos, a documentação existe, contratar é fácil e a ferramenta não desaparecerá no próximo ano quando o seu único mantenedor perder o interesse. O aborrecido permite-lhe colocar todo o seu entusiasmo onde ele rende: no cliente.

É também aqui que a IA muda um pouco o quadro, e não como o entusiasmo sugere. Os assistentes de programação com IA são muitíssimo melhores com as tecnologias aborrecidas e populares, porque foram treinados com uma década de respostas públicas sobre elas. Escolha uma stack convencional e a sua equipa (e as suas ferramentas) recebem ajuda mais rápida de graça. Escolha algo exótico e estará por sua conta exatamente quando menos o pode pagar.

Um método de decisão que pode mesmo usar

Chega de princípios. Eis uma forma concreta de chegar a uma decisão, quer escolha você próprio, instrua um freelancer ou avalie o que uma agência propõe. Nada disto lhe exige escrever código: apenas perguntar as coisas certas e ponderar as respostas.

1. 1
   Parta da equipa, não da tecnologia

   Pergunte: quem vai construir e manter isto nos próximos dois anos? Aquilo que já dominam bem é a sua opção predefinida mais sólida. Mudar de stack para perseguir uma moda raramente bate o à-vontade.
2. 2
   Por defeito, o convencional e comprovado

   Escolha do meio popular e bem documentado de cada camada. Se não encontrar depressa tutoriais, vagas e grandes comunidades para uma ferramenta, encare isso como um aviso, não como uma virtude.
3. 3
   Otimize para a mudança, não para a escala

   Prefira a escolha que torna editar o seu produto rápido e barato. Vai estar enganado repetidamente quanto ao produto: o trabalho da stack é tornar o engano sobrevivível.
4. 4
   Mantenha a arquitetura tão simples quanto possível

   Uma base de dados. Um backend. Um frontend. Nada de microsserviços, nada de espertos sistemas distribuídos, até que um problema real e medido o force. A simplicidade é o objetivo, não o compromisso.
5. 5
   Escreva porque a escolheu

   Um parágrafo: quem a constrói, o que escolheu e o que teria de mudar para a reconsiderar. Esta nota poupa-o de voltar a litigar a decisão sempre que alguém lê uma opinião polémica.

Se não seguir mais nada, siga os passos um e quatro. Construa com as pessoas que tem, na arquitetura mais simples que funciona. Essa combinação evita em silêncio os dois modos de falha que afundam a maioria dos primeiros produtos SaaS: ninguém capaz de o manter e um sistema demasiado complicado para o seu tamanho.

Perguntas a fazer a quem propõe uma stack

A maioria dos fundadores não escolhe a stack sozinha: um programador, uma agência ou um amigo CTO propõem uma. Não precisa de verificar a tecnologia você próprio. Precisa de fazer um punhado de perguntas e ouvir como respondem. Respostas seguras e em linguagem clara são um bom sinal. O jargão defensivo não é.

• "Porquê esta e não a aborrecida opção popular?" — uma boa resposta gira em torno das suas necessidades específicas, não do que está na moda.
• "Se fosse atropelado por um autocarro, com que facilidade alguém poderia assumir isto?" — a resposta revela quão rara e arriscada é a escolha.
• "Qual é a versão mais simples desta arquitetura que ainda funciona?" — repare se vai à simplicidade ou à complexidade.
• "Quão fácil será contratar o próximo programador para isto?" — competências comuns significam um mercado saudável; competências exóticas significam dependência.
• "O que acontece quando precisarmos de mudar uma funcionalidade central daqui a três meses?" — quer ouvir que a mudança é barata, não temida.

Armadilhas comuns que parecem boas ideias

Alguns padrões surgem tão frequentemente que vale a pena nomeá-los, porque cada um parece responsável no momento e lhe sai caro depois.

Construir para uma escala que não tem. O impulso de "fazer bem feito" leva os fundadores a arquitetar para milhões de utilizadores antes de terem dez. Cada porção dessa antecipação ao futuro é complexidade que paga agora, em tempo e dinheiro, para resolver um problema que talvez nunca chegue. Construa para os próximos cem utilizadores. Rearquitete quando o crescimento o tornar necessário, e que seja um problema feliz.

Perseguir a novidade. Uma framework reluzente lançada no mês passado não tem historial, tem documentação escassa e uma comunidade minúscula. Passará as noites a depurar a ferramenta em vez de construir o seu produto. Deixe que outros sejam os adotantes precoces; você tem um negócio para lançar.

Subcontratar quem for mais barato, no que ele preferir. A proposta mais baixa vem muitas vezes com uma stack obscura que só aquela equipa conhece. No dia em que se separarem, o seu produto torna-se uma ilha que mais ninguém consegue alcançar. Barato à partida, ruinoso depois. Exija tecnologia convencional e com mercado de contratação mesmo quando subcontrata, sobretudo quando subcontrata.

Quando é realmente altura de rever a sua stack

Nada disto significa "nunca mudar". Significa mudar por razões reais, medidas, não imaginadas. Saberá que é realmente altura de fazer evoluir a sua stack quando surgirem sinais concretos, não quando um artigo de blogue o deixa ansioso.

Repare no padrão: as razões reais dizem respeito a uma dor medida no seu negócio real. As falsas dizem respeito a moda, comparação e inquietação. Quando surge um sinal real, muda uma peça de cada vez, não toda a stack numa reescrita heroica que paralisa tudo durante seis meses. Evolução, não revolução.

Perguntas frequentes