El stack con el que construimos, y para qué sirve cada parte

Pregúntanos. La lista es lo que aparece con suficiente frecuencia como para escribirlo, no un límite. La mayoría de los stacks son variaciones sobre las mismas pocas ideas, y un equipo que conoce bien una base de datos relacional o un framework de componentes rara vez queda indefenso frente a otro. Cuando algo sí queda fuera de lo que podemos sostener con responsabilidad, te lo decimos en la primera llamada y no lo descubrimos con tu presupuesto.

No. Si ya tienes equipo, código existente o un estándar de empresa, la tecnología correcta suele ser la que tu gente pueda mantener cuando nosotros ya no estemos. Diremos cuándo creemos que una elección te va a costar más adelante, y luego construiremos con lo que elijas. La excepción es una decisión que sea genuinamente insegura y no simplemente distinta, y eso es lo bastante raro como para discutirlo en serio cuando pasa.

Partiendo de las restricciones y no de las preferencias. Quién lo mantiene después del lanzamiento, qué tan fácil es contratar para eso, si el trabajo es sobre todo de interfaz o sobre todo de datos, si algo funciona lejos de una red, y cuánto tiempo tiene que seguir funcionando. Esas respuestas normalmente lo reducen a dos opciones razonables, y en ese punto la diferencia entre ellas importa mucho menos que elegir una y ser consistente.

Registran cuánto de nuestro propio trabajo se apoya en cada tecnología, para que la amplitud nunca se confunda con profundidad pareja. Principal es lo que usamos a diario en nuestros productos y con clientes. Frecuente es lo que entregamos en proyectos cuando el trabajo lo pide. Disponible es trabajo que tomamos, casi siempre para mantener o migrar algo que ya existe. Las tres son reales. No son igual de profundas, y preferimos decirlo antes que insinuar lo contrario con cien logos.

Depende de si es viejo o si está sin soporte, que son cosas distintas. Maduro y estable normalmente es bueno. Pasado su fin de vida es otra cosa: significa que los parches de seguridad se detuvieron, que las tiendas pueden terminar rechazando la aplicación y que cada año hay menos gente dispuesta a trabajar en ello. Si no sabes de qué lado estás, eso es justo lo que responde una auditoría de software.

Muchas veces es el mejor arreglo. Podemos tomar un subsistema mientras tu equipo lleva el resto, acompañarlos en una parte del stack que no dominan, o construir algo y entregarlo para que ellos lo administren. Escribimos el código, la documentación y el proceso de despliegue asumiendo esa entrega, porque un software que tu propio equipo no puede mantener es un riesgo por bien que funcione hoy.