HTML, CSS e JavaScript não afundaram seu produto. Seu código é lindo, seu produto é uma merda.
Eu não sou dev. Construo produtos, e é exatamente por isso que vejo esse problema com tanta clareza.
Você escolhe a stack "certa". O código está limpo, testado, bem documentado, os commits são semânticos, o CI/CD tá rodando liso.
E o usuário abre o sistema, não entende nada, e fecha em 30 segundos.
O problema não é técnico. É de prioridade.
A cultura de desenvolvimento tem um vício sério: romantizou demais o "como é feito" e esqueceu completamente do "o que é feito" e pra quem é feito.
Virou status ter uma stack impressionante. Virou currículo usar o framework que saiu faz três meses. Virou símbolo de senioridade torcer o nariz pra HTML, CSS e JavaScript, como se dominar o box model e criar uma experiência fluida fosse coisa de dev júnior sem ambição.
Mas o usuário não sabe o que é um ORM. Ele não sabe a diferença entre REST e GraphQL. Ele não se importa se você usou Server Components ou não.
O que ele sabe é que o botão estava num lugar inesperado, que ele clicou três vezes sem nada acontecer, que o formulário limpou tudo depois de um erro de validação, que ele desistiu.
"Só funcionar" não é entregar valor
Eu quero que o usuário não precise de treinamento pra usar. Quero que ele chegue no fluxo certo sem pensar. Quero que quando ele errar, o sistema o ajude a corrigir sem punição. Quero que ele saia com a sensação de que o produto foi feito pensando nele.
Isso não é perfumaria. Isso é o produto.
Um restaurante onde a comida não tem gosto mas também não envenena tecnicamente cumpriu a função. Mas ninguém volta, ninguém indica, ninguém cria vínculo. É exatamente isso que acontece com produto que "só funciona".
Planejamento de fluxo não é opcional
A maioria dos times começa a codar antes de responder perguntas básicas:
- Por onde o usuário entra?
- O que ele quer fazer nos primeiros 30 segundos?
- Onde ele pode travar?
- O que acontece quando ele erra?
- Como ele aprende a usar sem ler manual?
Essas perguntas não são de designer. São de quem constrói produto. E quando a equipe ignora isso, o retrabalho aparece, o suporte explode, o churn aumenta, e aí culpam o mercado, o usuário, ou a concorrência desleal.
Frontend virou o primo pobre da engenharia
E isso tem um custo real.
Quando a cultura do time trata frontend como "a parte chata", como "coisa que qualquer um faz", o que acontece? As decisões de UX ficam pra última hora. O fluxo de uso nunca é discutido em profundidade. A interface vira consequência do backend, em vez de ser o ponto de partida do design do sistema.
O usuário sente isso. Ele não sabe nomear, mas sente.
E a ironia: um frontend bem feito, com performance real, acessibilidade, estados de erro bem tratados, feedback visual preciso e fluxo pensado, é tecnicamente tão desafiador quanto qualquer sistema backend complexo.
O que eu aprendi construindo produto
Produto bom começa com empatia pelo usuário, não com escolha de stack.
A stack é meio, não fim. O fim é alguém conseguir fazer o que precisa, de forma simples, sem fricção, e sair com a sensação de que aquilo foi feito pra ele.
Quando essa ordem se inverte, quando a tecnologia vem antes da experiência, o resultado é um código impressionante dentro de um produto que ninguém quer usar.
E no mercado, quem decide se o seu produto sobrevive não é o seu tech lead. É o usuário que vai ou não vai voltar amanhã.
Isso é opinião de quem está do outro lado do balcão, observando o produto ser usado, não o código ser escrito. Se alguma parte cutucou, talvez valha a pena sentar e perguntar: o último projeto que entrei em produção, eu realmente pensei no usuário antes de pensar na stack?