Cuando un cliente nos contacta para construir algo desde cero, o para migrar una plataforma existente, una de las primeras preguntas que hacemos no es técnica. Es esta:
¿Cuántas personas van a mantener esto en dos años, y cuánto tiempo tienen para aprender algo nuevo?
La respuesta a esa pregunta determina casi todo lo demás.
El error más común: elegir el stack más interesante
Hay una tentación enorme, especialmente en equipos técnicos jóvenes, de elegir las tecnologías más nuevas, más discutidas en Twitter, más emocionantes. Lo entiendo. Yo caí en esa trampa más de una vez.
El problema es que el stack más interesante rara vez es el stack más apropiado. Un framework nuevo puede tener bugs sin resolver, documentación incompleta, poca gente disponible para contratación y comunidades chicas. Todo eso se paga caro cuando el proyecto está en producción y algo falla un domingo a las 3am.
La regla que aplicamos en Sintaxyz es simple: el stack tiene que ser aburrido de la manera correcta.
El framework que usamos para decidir
Cuando evaluamos tecnologías para un proyecto, pasamos por cinco dimensiones:
1. Madurez del ecosistema
¿Cuántos años tiene? ¿Está mantenido activamente? ¿Tiene empresa detrás o depende de un mantenedor individual? ¿Qué pasa con la seguridad cuando aparece una vulnerabilidad?
Esto importa porque los proyectos de scale-ups no son pruebas de concepto: van a vivir en producción por años. Un framework que desaparece o que no tiene patches de seguridad activos es una deuda enorme.
2. Disponibilidad de talento
Si el proyecto va a necesitar incorporar tres devs más en los próximos seis meses, ¿existe esa gente en el mercado? ¿A qué precio?
Esta dimensión la ignoramos cuando éramos más jóvenes. Construimos una plataforma con un framework de nicho que funcionaba perfectamente, pero cuando el cliente quiso escalar el equipo, tardó cuatro meses en encontrar gente que lo conociera.
3. Fit con el problema
No toda tecnología sirve para todo. Django es excelente para sistemas con lógica de negocio compleja y necesidad de admin interno rápido. FastAPI brilla en APIs de alto rendimiento y proyectos con tipado estricto. Next.js tiene sentido cuando el SEO y el tiempo de carga inicial son críticos. Astro aplica cuando el contenido es mayormente estático.
La pregunta no es “¿cuál es mejor?”, sino “¿cuál resuelve mejor este problema específico?“.
4. Costo operacional
Algunos stacks son baratos de correr, otros no. Un sistema en Go puede manejar el mismo tráfico que uno en Python con un tercio de la infraestructura. Eso no siempre importa, pero cuando el cliente es una startup con presupuesto ajustado, importa mucho.
También entra aquí el costo de hosting, la complejidad del deployment, y cuánto tiempo pasa el equipo en infraestructura en vez de en features.
5. Velocidad de iteración inicial
Al principio de un proyecto, la velocidad de desarrollo es crítica. Un framework que permite hacer mucho con poco código acelera la validación de hipótesis de negocio. Esto pesa más en las primeras etapas y menos cuando el sistema ya está estabilizado.
Un ejemplo real: la decisión entre Django y FastAPI
Hace unos meses tuvimos un proyecto de una startup fintech. Necesitaban una API para procesar transacciones, integrarse con tres pasarelas de pago distintas, y tener un dashboard interno para que el equipo de operaciones pudiera revisar casos manualmente.
La discusión interna fue interesante. Alguien propuso FastAPI porque es más moderno y tiene soporte nativo para async. Era una buena opción técnica.
Pero cuando aplicamos el framework:
- Madurez: Django lleva 20 años. FastAPI lleva 6. Ambos son seguros, pero Django tiene un ecosistema más amplio para lo que necesitaban (autenticación, permisos, admin).
- Talento: El equipo existente del cliente usaba Python y conocía Django. FastAPI habría requerido onboarding.
- Fit: Tenían lógica de negocio compleja (reglas de compliance, estados de transacción, conciliación). Django ORM y su sistema de permisos encajaban perfectamente. El dashboard interno lo hicimos con Django Admin en dos días.
- Velocidad: El admin de Django nos ahorró tres semanas de desarrollo de un panel custom.
Elegimos Django. El cliente pudo lanzar en ocho semanas.
¿Hubiera funcionado FastAPI? Sí. ¿Era la decisión correcta para ese proyecto y ese equipo? No.
La regla del 80/20 del stack
Con el tiempo desarrollé una heurística que comparto con los clientes:
Elegí la tecnología más convencional que resuelva el 80% de tus problemas. Usá tecnología especializada solo cuando la convencional falla en algo que importa.
Eso significa que si Django resuelve tus problemas, no hay razón para meterse con algo más exótico. Si necesitás rendimiento extremo en una sola ruta crítica, podés usar una solución específica para esa ruta sin migrar todo el sistema.
La fragmentación innecesaria del stack es uno de los problemas más caros que vemos en proyectos que heredamos para rescatar.
Lo que el stack no puede resolver
Por último, algo que aprendí de la manera difícil: el mejor stack del mundo no salva un proyecto mal diseñado.
He visto sistemas en Django, FastAPI, Rails, NestJS y Go, tanto bien construidos como un desastre total. La tecnología no es la variable determinante. Lo son la claridad de los requerimientos, la calidad de las decisiones de arquitectura, y la consistencia con la que se aplican las convenciones.
Un proyecto bien estructurado en Django es infinitamente más mantenible que un desastre bien intencionado en Rust.
El stack importa. Pero importa menos de lo que la mayoría cree.
Si estás evaluando el stack para tu próximo proyecto y querés una segunda opinión, con gusto revisamos el problema con vos.