O que é uma tech stack? O guia do fundador não-técnico

O guia do fundador não-técnico sobre a tech stack: não como escolher uma, mas como saber se a decisão de stack é boa ou ruim, quais escolhas são caras de reverter e quais perguntas fazer para quem constrói o seu produto.

A primeira vez que a maioria dos fundadores ouve as palavras “tech stack” ditas com peso é numa sala que eles não conseguem ler por completo. Para a Priya, foi numa call de due diligence de Série A. O sócio do outro lado da mesa, simpático até aquele instante, perguntou qual era a stack dela. Ela conhecia o produto. Sabia os números de cor. Mas não sabia se “Rails e Postgres na AWS” era a resposta certa ou uma confissão, e o meio segundo de silêncio deixou claro para todo mundo na sala qual das duas era.

Uma tech stack é o conjunto de tecnologias sobre as quais o seu software é construído: as linguagens de programação, os frameworks, o banco de dados e a infraestrutura que, empilhados, rodam o seu produto. Essa é a definição inteira. Uma pergunta do tipo “o que é uma tech stack” quase nunca quer mais do que isso, e os diagramas em camadas que enchem os resultados de busca fazem parecer mais misterioso do que é. A pergunta difícil, a que ninguém que escreve sobre tech stack parece responder, é a que a Priya realmente tinha: você não escolheu a sua stack, não consegue ler o código que roda em cima dela, então como deveria saber se a sua presta?

Este é o guia que a gente gostaria que aquela fundadora tivesse antes da call. Ele não vai te ensinar a escolher uma stack. Como fundador não-técnico, você não deveria estar escolhendo uma, do mesmo jeito que não deveria estar escrevendo o SQL. Ele vai te ensinar a avaliar a que te entregaram, a saber quais partes são caras de errar e a fazer as quatro perguntas que separam uma stack escolhida para o seu negócio de uma stack escolhida para o currículo de alguém.

O que é uma tech stack, em português claro

Imagine o seu produto como um prédio. A tech stack é tudo que é estrutural mais tudo com que você mobiliou o lugar. Em geral as pessoas descrevem em camadas, e as camadas mapeiam direitinho em coisas que você já entende como operador.

O frontend é o que os seus usuários veem e tocam: as telas, os botões, o app no celular. Quando alguém diz “React” ou “Swift”, está nomeando as ferramentas usadas para construir essa superfície. O backend é a parte que o usuário nunca vê: a lógica que decide o que acontece quando ele clica, quem pode fazer o quê, como um pedido vira uma cobrança. O banco de dados é onde fica guardado tudo o que o seu negócio sabe: seus clientes, suas transações, o histórico deles. A infraestrutura é o chão em que tudo se apoia: os servidores, normalmente alugados da Amazon, Google ou Microsoft, que mantêm a coisa no ar às 3 da manhã.

Um exemplo concreto, porque “o que é uma tech stack” se responde melhor com um. Um produto SaaS típico de estágio inicial pode rodar React no frontend, um backend em Node ou Ruby, um banco Postgres, hospedado na AWS, com o Stripe ligado para pagamentos e mais alguns serviços parafusados para e-mail e analytics. Essa frase é uma tech stack completa. Se o seu desenvolvedor não consegue descrever a sua numa frase tão simples assim, vale reparar, e a gente volta nesse ponto.

O que segurar: cada camada é uma decisão de negócio vestida de roupa técnica. O banco de dados não é só onde os dados moram; é a velocidade com que você responde à pergunta de um cliente e o tamanho da dor de mudar esses dados de lugar daqui a três anos. A infraestrutura não é só servidor; é uma conta mensal que cresce junto com o seu crescimento. Nada disso exige que você programe. Exige que você traduza.

Você não vai escolher a sua stack. Mesmo assim, precisa saber lê-la.

Existe uma armadilha dos dois lados. Um fundador trata a stack como assunto que não é dele, entrega tudo a um desenvolvedor e descobre dois anos depois que um único prestador é a única pessoa viva que entende como a empresa funciona. O outro fundador lê três posts de blog, cria opiniões sobre se o time devia usar MongoDB e começa a passar por cima das pessoas que ele contratou justamente para tomar essa decisão. Os dois estão errados. O trabalho não é escolher a stack nem delegar 100% dela. O trabalho é conseguir lê-la.

Lê-la significa três coisas. Você consegue descrever a sua stack em linguagem simples para um investidor ou um novo contratado. Você sabe quais escolhas dentro dela são reversíveis e quais são quase permanentes. E você consegue perceber quando uma decisão técnica está sendo tomada por um motivo técnico e quando está sendo tomada por um motivo pessoal. Essa última habilidade é o jogo inteiro, e a maioria dos fundadores nunca a desenvolve porque ninguém avisa que é algo que eles têm o direito de avaliar.

É aqui também que a stack se conecta a uma decisão que talvez você já tenha enfrentado: construir algo sob medida ou comprar uma solução de prateleira. Toda resposta “construir” te compromete com uma stack. Saber ler essa stack é a diferença entre uma decisão de construir que você controla e uma que controla você.

As decisões que são baratas de mudar, e as que não são

Nem toda escolha na sua stack carrega o mesmo peso, e a coisa mais útil que um fundador não-técnico pode aprender é distinguir as pesadas das leves.

Algumas decisões são reversíveis. A ferramenta de analytics, o serviço que dispara o seu e-mail transacional, a biblioteca que desenha os seus gráficos: dá para trocar numa tarde, ou pelo menos numa sprint, sem ninguém perder o sono. Se o time escolheu uma e ela se mostrou errada, o custo de ter errado é pequeno. Você pode deixar essas decisões serem tomadas rápido e mudadas depois.

Outras decisões são estruturais, do tipo que sustenta o teto. A sua linguagem de programação principal, o seu banco de dados, o formato básico de como o sistema é organizado: isso é despejado feito uma fundação. Mudar depois não é uma troca; é uma reconstrução. Uma empresa que decide, com trinta engenheiros, sair da sua linguagem original está olhando para um projeto medido em trimestres e queimando dinheiro de verdade, o tipo de reconstrução que ninguém queria. A pergunta de plataforma de ir nativo ou cross-platform no mobile também mora nessa categoria mais pesada: é reversível na teoria e cara na prática.

Você não precisa saber qual banco de dados é o melhor. Você precisa saber que o banco é uma decisão que sustenta o teto e que o provedor de e-mail não é, para saber onde ir devagar e fazer perguntas e onde deixar o time correr. Quando um desenvolvedor diz “isso a gente muda depois”, seu único trabalho é perguntar uma coisa: isso é mesmo uma decisão mudável depois, ou você está me dizendo que é porque já está tomada? Bons construtores vão te falar a verdade. A distinção entre reversível e estrutural é a versão de engenharia estrutural do fundador. Você não está despejando o concreto. Você está garantindo que alguém checou quais paredes seguram o telhado.

A leitura de quatro perguntas: como avaliar uma stack que você não programa

Aqui está o roteiro. Quando alguém propõe uma stack, ou quando você herda uma e quer saber sobre o que está pisando, faça estas quatro perguntas e escute menos as respostas do que o jeito como elas são dadas.

1. “Por que isso e não a escolha óbvia e sem graça?” Quase sempre existe um default para cada tarefa, a opção que a maioria dos times pega porque é bem compreendida. Se o seu desenvolvedor escolheu o default, ele deve conseguir dizer isso na lata. Se escolheu outra coisa, deve haver um motivo ligado ao seu negócio, não à tecnologia ser interessante. “Usamos Postgres porque é a escolha certa e sem graça” é uma ótima resposta. “Usamos um banco de grafos porque encaixa melhor no formato real desses dados” é uma ótima resposta. “Usamos porque eu queria aprender” é a resposta que você está procurando, e ela deve te deixar em alerta.

2. “Quantas pessoas conseguem trabalhar nisso se você for atropelado por um ônibus?” Suavize a pergunta se quiser, mas ela é real. Uma stack construída sobre tecnologia popular e amplamente usada significa que você contrata os seus próximos três desenvolvedores de um universo de milhares. Uma stack construída sobre algo exótico significa que o seu pool de talento é um grupo de WhatsApp. Você não está só comprando software quando aprova uma stack; está comprando a sua capacidade futura de contratar gente para ela.

3. “O que acontece com essa conta conforme a gente cresce?” Algumas stacks são baratas com dez usuários e brutais com dez mil. Peça ao time para te levar pelo que a infraestrutura custa hoje e como ela fica com dez vezes a sua carga atual. Você não vai conseguir conferir a conta, mas vai descobrir se eles pensaram nisso. Um time que nunca modelou isso é um time que vai te surpreender com uma fatura.

4. “Me mostra a parte de que você menos se orgulha.” A resposta honesta a isso te diz mais do que qualquer diagrama de arquitetura bonito. Todo sistema real tem um canto preso com fita, um atalho tomado no aperto do prazo, um pedaço conhecido de dívida técnica. Um time que consegue apontar a sua e explicar a troca é um time que é honesto com você. Um time que afirma que está tudo limpo está mentindo ou não sabe, e você não consegue distinguir qual dos dois, o que já é um problema por si só.

Você vai reparar que nenhuma dessas quatro perguntas exige que você entenda a resposta tecnicamente. Elas exigem que você leia a pessoa que responde. Essa é a habilidade de verdade, e fundadores que vêm de finanças e consultoria já a têm. Você já avaliou gente que não conseguia superar no conhecimento técnico. É o mesmo músculo. É também o mesmo músculo que você usa quando vai escolher uma empresa de desenvolvimento de software lá no começo: você está julgando o julgamento, não o código.

Os sinais de alerta: quando a stack foi escolhida para o engenheiro, não para o negócio

Existe um modo de falha no software que tem nome entre os desenvolvedores: desenvolvimento orientado a currículo. É quando a tecnologia é escolhida não porque é certa para o problema, mas porque fica bonita no CV da pessoa ou porque é o framework que todo mundo comentava na última conferência. É um dos erros mais comuns e mais caros do software de estágio inicial, e um fundador não-técnico é singularmente vulnerável a ele porque não consegue ver acontecendo.

Os sinais, porém, dá para conhecer. Desconfie quando a stack está cheia de tecnologias muito novas, em que o argumento a favor delas é empolgação e não encaixe. Desconfie quando duas partes do sistema não usam a mesma abordagem, sinal de que quem construiu estava colecionando ferramentas em vez de resolver um problema. Desconfie, acima de tudo, quando você pergunta por que algo foi escolhido e a resposta escorrega para o quão moderno é, o quão na ponta é, o quanto é o futuro. O futuro não é um motivo. O encaixe no seu problema real é um motivo.

A questão mais profunda é que uma stack escolhida por moda transfere risco para você, de mansinho. O engenheiro fica com o aprendizado e com a linha no currículo. Você fica com um sistema difícil de contratar para ele, difícil de manter e construído sobre algo que pode ser abandonado em dois anos. A gente já viu fundadores herdarem bases de código escritas em frameworks que ficaram na moda por dezoito meses e estavam sem suporte na hora em que a empresa precisou escalar. A conta dessa moda cai no fundador, nunca em quem escolheu. Uma stack deve ser sem graça do mesmo jeito que um encanamento bom é sem graça. Você quer que funcione, não que impressione os seus amigos.

Por que o sem graça costuma ganhar

As tech stacks mais populares são populares por um motivo nada glamoroso: tanta gente usa que os problemas já estão resolvidos, a documentação é grossa e o pool de talento é fundo. Quando você constrói sobre tecnologia amplamente adotada, está pisando sobre a depuração acumulada de milhões de outros desenvolvedores. Quando você constrói sobre a coisa exótica, está depurando você mesmo, sozinho, no pior momento possível.

Você não precisa acreditar nisso por fé. O Stack Overflow Developer Survey pergunta a dezenas de milhares de desenvolvedores em atividade, todo ano, o que eles realmente usam, e as respostas são um mapa utilizável do que tem bom suporte e do que é fácil de contratar. As escolhas sem graça e dominantes daquela lista são dominantes porque continuam funcionando. Para uma empresa de estágio inicial, “popular e bem compreendido” ganha de “novo e impressionante” quase sempre, porque a sua restrição raramente é a tecnologia em si. A sua restrição é a sua capacidade de contratar gente para trabalhar nela, consertar rápido quando quebra e não ficar refém da única pessoa que entende a parte esperta.

Esse é o mesmo instinto que a Pixel Breeders leva para cada projeto. Sob medida não quer dizer exótico. Quer dizer um sistema moldado para o seu negócio, feito para servir e feito para escalar, sobre uma fundação em que outras pessoas conseguem pisar depois de você. O capricho está no encaixe, não na novidade das peças. Uma stack que você consegue contratar para ela, explicar numa frase e passar para a próxima pessoa sem cerimônia não é um meio-termo. É o objetivo.

A Priya, para constar, tinha uma stack boa. Rails e Postgres na AWS é a escolha certa e sem graça para uma empresa do estágio dela, e a pergunta do sócio não era uma armadilha; era um teste exatamente dessa autoconsciência que ela agora construiu. Da próxima vez que perguntarem qual é a stack dela, o meio segundo de silêncio não vem. Não porque ela aprendeu a programar. Porque ela aprendeu a ler.

Perguntas frequentes

O que é uma tech stack?
Uma tech stack é o conjunto de tecnologias sobre as quais o seu software roda: as linguagens de programação, os frameworks, o banco de dados e a infraestrutura que se combinam para fazer o produto funcionar. Um exemplo comum é React no frontend, uma linguagem de backend como Ruby ou Node, um banco Postgres, hospedado na AWS. Como fundador, você não precisa escolher, mas deveria conseguir descrever a sua numa frase simples.

O que é um exemplo de tech stack?
Uma stack típica de SaaS de estágio inicial: React para a interface, um backend em Node.js ou Ruby on Rails para a lógica, PostgreSQL como banco de dados, hospedado na Amazon Web Services, com o Stripe cuidando dos pagamentos. Cada peça faz um trabalho, e juntas elas são a tech stack da empresa. Se o seu time não consegue resumir a sua de forma tão simples, pergunte por quê.

Qual é a tech stack mais popular?
Não há um único vencedor, mas as peças mais usadas costumam se concentrar em algumas opções bem suportadas: JavaScript e TypeScript no frontend, linguagens como Python, Ruby, Node ou Java no backend, PostgreSQL ou MySQL para dados e AWS, Google Cloud ou Azure para hospedagem. Popularidade importa porque significa mais documentação, mais problemas resolvidos e um pool mais fundo de gente para contratar.

Qual é uma boa tech stack para uma startup?
Uma boa stack de startup é sem graça de propósito: construída sobre tecnologia popular e bem documentada para a qual você consegue contratar, sem escolhas exóticas a menos que exista um motivo claro de negócio. A melhor stack para uma empresa de estágio inicial é a que te deixa lançar, mudar barato onde dá e contratar fácil, não a mais nova ou mais impressionante.

Um fundador não-técnico deve escolher a tech stack?
Não. Escolher a stack é trabalho do seu desenvolvedor ou parceiro técnico. O seu trabalho é avaliar a escolha: saber quais decisões são caras de reverter, perguntar por que cada peça grande foi escolhida e garantir que a stack foi selecionada para o seu negócio, não para o currículo de alguém. Você julga o julgamento, não o código.

Como sei se a minha tech stack está ultrapassada?
Os sinais são práticos, não técnicos: está ficando difícil contratar gente que conhece a tecnologia, o time evita mexer em certas partes, o construtor original é a única pessoa que entende aquilo, ou a tecnologia de base não tem mais suporte ativo. Uma stack envelhecida raramente falha em alto e bom som. Ela só fica mais lenta e mais cara de mudar até a reconstrução virar inevitável.