Toda vez que um cliente chega com a ideia de um novo sistema, uma das primeiras perguntas que surge é: qual tecnologia vamos usar?
É uma pergunta legítima. E a resposta errada pode custar caro, não só em dinheiro, mas em tempo de manutenção, dificuldade para contratar e problemas que só aparecem em produção meses depois.
Aqui está o raciocínio que uso para chegar nessa decisão.
A pergunta certa não é “qual é a melhor linguagem?”
A melhor linguagem de programação não existe. O que existe é a melhor escolha para o seu contexto específico.
Quando um cliente me pergunta “qual linguagem devemos usar?”, eu devolvo com outras perguntas: que tipo de sistema é esse? Você já tem uma equipe técnica? Qual é o prazo real? A carga esperada é de 100 usuários simultâneos ou 100.000?
Essas respostas definem a stack, não a preferência pessoal nem o hype do momento.
Backend: por que começo quase sempre com PHP e Laravel
Para a maioria dos projetos de software sob medida no mercado brasileiro, sistemas de gestão, painéis administrativos, APIs de negócio, começo com PHP e Laravel. Isso não é falta de criatividade. É pragmatismo.
O Laravel tem mais de 10 anos e resolve “o óbvio” de forma consistente: autenticação, autorização, filas, agendamento de tarefas, envio de e-mails, migrations de banco de dados. Você começa a desenvolver o negócio no dia 1, não a infraestrutura.
Tem mais: qualquer servidor Linux com PHP roda Laravel. Sem containers obrigatórios para o primeiro ambiente. Sem horas perdidas configurando infra antes de escrever a primeira linha do sistema real.
Isso não significa que Node.js não tem lugar. Quando o sistema precisa de tempo real de verdade, chat ao vivo, notificações sem polling, é mais natural trabalhar com Node. Ou quando o time vai usar TypeScript no frontend e no backend e quer reduzir o custo de contexto entre as duas camadas. Nesses casos específicos, faz sentido. Para sistemas CRUD-heavy, o Laravel entrega mais rápido na minha experiência.
Frontend: a maioria dos projetos não precisa de React
Sério. Muitos projetos acabam com React porque está na moda, não porque o problema exige.
Se o sistema é um painel administrativo com formulários, tabelas e relatórios, Bootstrap com JavaScript vanilla funciona bem e carrega muito mais rápido. Uso esse stack em vários projetos de gestão interna. O cliente não sente diferença e o projeto fica mais simples de manter por anos.
Uso React quando a interface tem estado complexo que muda frequentemente sem recarregar a página, ou quando o projeto é genuinamente uma SPA onde a experiência de navegação justifica o peso do bundle. Mas não chego com React na primeira reunião.
Banco de dados: PostgreSQL é minha escolha padrão hoje
Para novos projetos onde tenho controle sobre a infra, escolho PostgreSQL. O motivo principal é confiabilidade: ACID desde sempre, planejador de queries mais inteligente e tipos de dados que resolvem problemas reais sem precisar de gambiarra na aplicação.
JSONB com índice GIN, arrays nativos, UUID como tipo, full-text search embutido. Esses recursos não são enfeite. Eles evitam tabelas extras, queries complexas e às vezes eliminam a necessidade de um serviço externo para buscas.
MySQL ainda faz sentido quando a infra já existe, a equipe tem anos de operação configurados, ou a hospedagem não oferece PostgreSQL. Mas em projeto novo, verde, fico com PostgreSQL.
O fator que mais impacta a decisão: o prazo real
Na prática, o que mais define a stack é o prazo. Não o ideal técnico.
Se o cliente precisa de algo funcional em 4 semanas e a equipe já conhece determinada tecnologia, trocar por algo mais moderno “porque é a tendência” é um risco desnecessário. A produtividade vai no chão nas primeiras semanas de aprendizado. A entrega atrasa. O custo sobe. Já vi isso acontecer em projetos que não eram meus e que chegaram para mim no meio do caminho.
Quando faço consultoria, o processo é: primeiro entendo o problema de negócio. Depois mapeio as restrições reais de prazo, orçamento e equipe. Depois listo os requisitos técnicos que não são negociáveis. Só aí escolho a stack.
Parece óbvio, mas a maioria das conversas sobre tecnologia começa pela resposta antes de entender a pergunta.
Stack ideal é a que entrega
Não é a mais moderna. Não é a que está no hype. É a que entrega o sistema funcionando, dentro do prazo e do orçamento, com qualidade suficiente para crescer.
Isso muda de projeto para projeto. Parte do meu trabalho é fazer essa análise com o cliente antes de escrever a primeira linha de código.
Se você está planejando um novo projeto e tem dúvidas sobre qual caminho tomar, entra em contato pelo gabriels.dev.br. A conversa inicial é sem compromisso.