La lectura errónea más común de "elegimos el stack según el proyecto" es que no tenemos opinión sobre nada. No es verdad, y sería inútil si lo fuera. Lo que en realidad significa es que los defaults existen, y tienes que argumentarnos para sacarnos de ellos.
Parece una distinción menor. No lo es. Es la diferencia entre un equipo senior y un grupo de contratistas con una camiseta de equipo senior.
Un default es lo que elegimos cuando nada nos dice que elijamos otra cosa
Esa es la definición completa. No es "lo único que conocemos". No es "lo que vamos a imponer en tu proyecto sin importar si encaja". Es la respuesta que damos cuando el proyecto todavía no nos ha dado una razón para responder distinto.
Un studio sin defaults es un studio que vuelve a debatir cada proyecto desde cero. Cada kickoff se convierte en dos semanas de discusión sobre el almacén relacional. Cada decisión de caché se vuelve una mesa redonda. Cada conversación de frontend empieza en "¿deberíamos usar HTML?". Eso no es senior. Eso es junior perpetuo, disfrazado de mente abierta.
La ingeniería senior es lo contrario. Es una lista corta de defaults fuertes, aplicados sin ceremonia, y una lista larga de condiciones bajo las cuales los soltaríamos con gusto. Conocer ambas listas es lo que hace senior al equipo. Memorizar una sin la otra es lo que vuelve rígido o sin rumbo a un equipo.
Así que aquí va la lista corta, por categoría. Te la diremos en la primera llamada también, en menos tiempo del que te tomó leer este párrafo.
Almacén relacional: Postgres, casi siempre
Postgres es una navaja suiza. No es el mejor motor relacional en ninguna cosa específica — hay warehouses columnares que lo ganan en analítica, motores embebidos que lo ganan en simplicidad de proceso único, y document stores que lo ganan en flexibilidad schema-less. En lo que Postgres es mejor es en ser bueno en muchas cosas a la vez: transacciones ACID, JSONB, búsqueda full-text, índices parciales, listen/notify, foreign data wrappers, extensiones maduras, y una comunidad que ya ha visto cada modo de falla que estás a punto de descubrir.
Para aproximadamente nueve de cada diez proyectos que tomamos, ese paquete gana. No tienes que ser el mejor en una sola cosa si eres la herramienta correcta para casi todo lo que el proyecto va a lanzarte en los primeros dos años.
Elegiríamos otra cosa en casos específicos. ¿Cargas analíticas pesadas con miles de millones de filas y agregaciones de solo lectura? DuckDB en local o un warehouse columnar en remoto. ¿Un caso embebido de un solo tenant donde desplegar un servidor es exagerado? SQLite, encantados. ¿Una forma de documento que genuinamente no encaja en relacional — irregular, profundamente anidada, schema-on-read por naturaleza? A regañadientes Mongo, y querríamos una conversación seria sobre si la irregularidad es real o solo es pensamiento sin terminar.
Esas son razones reales. "Leí un post de blog" no lo es.
Cola y caché: Redis
Redis es la caché por default, la cola corta por default, el rate limiter por default, el servicio de locks por default, el pub/sub por default para fan-out pequeño. Es rápido, es simple, tiene modos de falla conocidos, y la superficie operativa es lo bastante pequeña como para que un ingeniero pueda hacerse cargo sin que le coma la semana.
Elegiríamos un broker de verdad — Kafka, NATS, a veces RabbitMQ según la forma — cuando el proyecto tiene event streams que necesitan replay durable, fan-out a una escala en la que Redis pub/sub se atraganta, o garantías estrictas de orden entre particiones. Esos no son la mayoría de los proyectos. Cuando sí lo son, no fingimos que Redis basta; pero tampoco fingimos que no basta cuando sí basta.
Frontend: un framework de componentes tipado con server rendering de primera
Aquí también tenemos un default. Es el framework que se paga a sí mismo más rápido en el tipo de trabajo que solemos hacer: superficies de marketing, dashboards, herramientas internas, el frente de un SaaS. Tipado. Basado en componentes. Server rendering como ciudadano de primera, no como un parche encima de una SPA client-only.
Cambiaríamos a otro framework tipado — misma familia, marca distinta — si el equipo que va a heredar el código ya lo conoce mejor que el nuestro. El encaje del hand-over le gana al encaje del autor. Siempre.
Empujaríamos fuerte en contra de un stack que eligió un framework de frontend porque estaba en la portada de Hacker News la semana pasada. Eso no es una razón; es una vibra.
Backend: Python o TypeScript por default, Go donde la contención es la restricción real
Python y TypeScript cubren la mayoría de lo que nos piden construir. Ambos tienen ecosistemas maduros, ambos son agradables para ingenieros senior y abordables para los más junior que el cliente pueda eventualmente contratar, y ambos son lo bastante rápidos para la carga de casi cualquier proyecto que no sea una mesa de trading de alta frecuencia.
Elegimos Go cuando la latencia bajo contención es la restricción real, no la imaginada. "Quizá algún día tengamos que manejar diez mil requests por segundo" es imaginada. "Nuestro p95 actual bajo carga se duplica cuando añadimos una quinta réplica" es real. No prepagues un rendimiento del que aún no puedes medir la carencia.
Despliegues: contenedores, orquestación simple, nada de Kubernetes salvo que se pague solo
El default son contenedores construidos una vez, promovidos entre entornos, y corridos en la plataforma más simple que baste para la escala del proyecto — muchas veces un solo VPS con un reverse proxy, a veces un servicio gestionado de contenedores, ocasionalmente una flota pequeña detrás de un load balancer. Despliegues aburridos. Despliegues reproducibles. Despliegues que un ingeniero pueda depurar a las 2am desde el teléfono.
Kubernetes es brillante cuando la escala del equipo y la del proyecto justifican su coste. Para la mayoría de los proyectos en fase temprana e intermedia, no lo justifica, y consume más tiempo senior del que devuelve. Hemos visto equipos de cuatro personas corriendo clusters de cincuenta nodos porque alguien lo añadió en la semana dos. No te haremos eso.
Por qué importan los defaults — y por qué no son lo mismo que dogma
Los defaults reducen el coste de decisión en las cosas aburridas, para que podamos gastar nuestro criterio en las difíciles. Ese es el juego entero. La ingeniería senior no es "cada decisión desde primeros principios, cada vez, en cada proyecto, para cada componente". Es "primeros principios cuando la decisión es load-bearing para este proyecto, y la respuesta estándar en todo lo demás".
Un studio que cree que los defaults son debilidad termina quemando a su gente más afilada en debates de color del cobertizo. Un studio que cree que los defaults son innegociables termina entregando stacks que no encajan porque son cómodos. La posición intermedia — defaults fuertes, sustituidos con gusto cuando el proyecto da una razón — es la que de verdad entrega.
Esa es la posición que sostenemos. No vamos a fingir que no la tenemos.
Qué puedes preguntarnos en la primera llamada
"¿Qué stack van a usar?" es una pregunta justa, y la respuesta honesta es corta: depende, pero esto es lo que elegiríamos primero, y esto es lo que nos haría elegir otra cosa.
Pregúntanos. Trae las partes de tu proyecto que crees que son inusuales. Te diremos cuáles de nuestros defaults sobreviven al contacto con tus restricciones y cuáles cambiaríamos, y por qué. Esa conversación es corta, productiva, y exactamente del tipo que tendríamos en la primera llamada — bastante antes de que nadie firme nada.
La forma de un buen engagement se ve en esa conversación. La de uno malo también.