Elegir un stack es un compromiso a largo plazo que haces con información incompleta, así que lo correcto es decidir con tradeoffs, no hype. El framework más vistoso del circuito de conferencias rara vez es el que sirve al proyecto dos años después. Mi sesgo predeterminado es hacia tecnología aburrida y probada a menos que haya una razón concreta para desviarse.
| Elige probado cuando | Considera novedoso cuando |
|---|---|
| Problema estándar, patrones conocidos | Una restricción real que nada maduro resuelve |
| El equipo debe moverse rápido | Tienes tiempo y ganas de aprender |
| De larga duración, debe ser mantenible | La ganancia es grande y medible |
Una decisión de stack moldea silenciosamente la contratación, velocidad y costo operacional durante años, y revertirla después es brutalmente cara. Elegir tecnología porque es emocionante en lugar de porque se ajusta es uno de los errores de liderazgo técnico más comunes y más dañinos. Decidir deliberadamente, con los tradeoffs escritos, es lo que distingue una elección de arquitectura de una elección de moda.