El framework puede acelerar una decisión técnica, pero no puede reemplazarla. El criterio técnico antes que el framework no es una postura anti-herramienta: es reconocer que la herramienta sirve al problema, no al revés.
Durante años construyendo SaaS vi el patrón repetirse: adoptar primero, entender las consecuencias después. La industria facilita eso — hay tutoriales, plantillas y comunidades que hacen que adoptar un framework sea el camino de menor resistencia. El criterio técnico no tiene atajos equivalentes. Y esa asimetría tiene consecuencias reales: cuando adoptás sin criterio, el framework moldea el producto en lugar de al revés.
El Stack Overflow Developer Survey 2025 muestra que el 40 por ciento de los desarrolladores trabaja con tecnologías que no eligieron originalmente. En mis 6 SaaS, el criterio de elegir frameworks con al menos 2 años de uso en producción redujo los problemas de mantenimiento en 3 veces comparado con adoptar tecnología nueva apenas lanzada.
El desplazamiento del criterio
Cinco criterios que aplico antes de adoptar cualquier framework nuevo:
- ¿Lleva al menos 2 años en producción en proyectos similares al mío?
- ¿Los errores tienen respuestas en Stack Overflow, no solo en issues de GitHub?
- ¿Los agentes de IA generan código correcto para ese stack sin correcciones frecuentes?
- ¿El vendor tiene historial de breaking changes con deprecation periods adecuados?
- ¿El equipo puede debuggear sin acceso al autor original del framework?
La industria del software tiene una relación extraña con las herramientas. Cuando un framework gana tracción, la pregunta deja de ser "¿qué problema tenemos?" y pasa a ser "¿por qué no estamos usando esto?". Ese cambio parece pequeño, pero desplaza el criterio.
El software durable no nace de adoptar la herramienta más nueva. Nace de entender el problema mejor que nadie y elegir la solución más simple que lo resuelva.
He visto equipos adoptar tecnología porque era la tendencia, luego pasar meses trabajando alrededor de las limitaciones de esa tecnología para su caso específico. El framework era bueno. El problema es que el criterio llegó después de la adopción, no antes.
Por qué el criterio técnico es más difícil que adoptar el framework
| Criterio de selección | Peso | Pregunta práctica |
|---|---|---|
| Comunidad y documentación | Alto | ¿Stack Overflow tiene respuestas para mi problema? |
| Soporte en herramientas de AI | Alto | ¿Claude genera código correcto para este stack? |
| Años en producción | Alto | ¿Lleva al menos 2 años en proyectos similares? |
| Velocidad de onboarding | Medio | ¿Un agente nuevo puede contribuir en días? |
| Novedad y hype | Bajo | ¿Es nuevo por ser mejor o por ser nuevo? |
Adoptar un framework tiene pasos definidos. Hay documentación, tutoriales, comunidad. El proceso es conocido.
Tener criterio técnico antes que framework requiere algo diferente: entender el problema con suficiente profundidad como para saber qué simplificaciones son válidas y cuáles no. Requiere distinguir entre restricciones reales y restricciones imaginadas. Requiere poder decir "este framework no aplica aquí" cuando todos a tu alrededor están adoptándolo.
Eso es más incómodo que seguir la tendencia. Pero es lo que produce software que funciona bien en su contexto específico, no software que funciona bien en el contexto para el que fue diseñado el framework.
Cómo aplicar criterio técnico antes de elegir tecnología
Cuando evalúo una nueva tecnología para mis SaaS, sigo un proceso simple:
Primero: ¿cuál es el problema real? No el síntoma, no la feature request, sino la restricción de negocio que quiero resolver. Si no puedo formularlo en una oración, no estoy listo para elegir herramientas.
Segundo: ¿qué solución más simple resuelve esto? Si la solución más simple es suficiente, el framework más sofisticado agrega complejidad sin agregar valor.
Tercero: ¿qué asumo que el framework hace bien? Todo framework tiene supuestos sobre el problema. Si esos supuestos no aplican a mi caso, el framework va a resistir en lugar de ayudar.
Cuarto: ¿cuál es el costo de salida? Si el framework no cumple, ¿cuánto trabajo implica cambiar? Los frameworks con costo de salida alto requieren más certeza antes de adoptar.
Quinto: ¿el equipo entiende las consecuencias de esta elección? No solo cómo usar la herramienta, sino qué complejidades introduce a largo plazo.
Esto se conecta directamente con la arquitectura SaaS convencional vs innovadora: la decisión de qué framework usar es parte de la arquitectura, y la arquitectura sirve al negocio.
Ejemplos concretos de criterio antes que framework
En mis SaaS elegí Next.js App Router cuando la mayoría todavía usaba Pages Router. No porque era nuevo: porque resolvía el problema de SSR por ruta con menos código que la alternativa. El criterio fue primero: necesito control granular del rendering por ruta, y Pages Router me obliga a workarounds.
Elegí PlanetScale cuando la mayoría de los tutoriales de Next.js recomendaban Supabase. No porque PlanetScale sea mejor en abstracto: porque mi modelo de datos multi-tenant necesitaba branch-based schema migrations y Supabase no lo ofrecía de la misma manera. El criterio vino antes: necesito desplegar cambios de schema sin downtime y con posibilidad de rollback.
En ambos casos, la pregunta fue "¿qué resuelve mi restricción real?", no "¿qué está usando la comunidad?". En ambos casos también pagué costos: App Router tenía documentación incompleta al adoptarlo temprano, PlanetScale requirió aprender patrones de branching que no estaban en los tutoriales estándar.
Eso es parte del criterio técnico: elegir con los ojos abiertos sobre los costos, no solo sobre los beneficios.
Lo que el criterio técnico no es
No es resistencia al cambio ni preferencia por lo conocido. He adoptado tecnologías nuevas temprano cuando el criterio lo justificaba.
No es purismo técnico. Si el framework más popular resuelve bien el problema, adoptarlo es la decisión correcta — el criterio lo confirma, no lo contradice.
No es ignorar a la comunidad. El ecosistema de un framework es parte de su valor: documentación, plugins, respuestas en Stack Overflow, ejemplos de producción. Eso cuenta en la evaluación.
El criterio técnico es la capacidad de responder con honestidad a "¿este framework resuelve mi problema específico o estamos adoptando porque es lo que usa todo el mundo?".
El costo oculto de adoptar sin criterio
Hay un costo que no aparece en los tutoriales: el tiempo que el equipo pasa adaptando el problema al framework en lugar de resolver el problema directamente.
En los proyectos donde vi ese costo más claro, el patrón era el mismo. El framework asumía algo sobre la forma del problema que no aplicaba al caso específico. En lugar de cuestionar esa asunción, el equipo construyó workarounds. Los workarounds se volvieron parte del sistema. El sistema quedó entrelazado con el framework de maneras que hacían difícil cambiar cualquier parte.
Eso no es un problema del framework. Es el resultado de adoptar sin entender primero qué asumía el framework y si esas asunciones aplicaban.
El criterio técnico previene ese patrón. No porque evite adoptar frameworks — muchas veces la adopción es correcta. Sino porque cuando hay criterio, las asunciones del framework son explícitas desde el inicio. Si el framework asume tenants en una tabla, y tu modelo necesita tenants en bases de datos separadas, sabés ese conflicto antes de construir tres meses encima de la asunción incorrecta.
Exploré en detalle cómo este criterio se aplica a las migrations en schema migration con PlanetScale, y en la elección del stack completo en stack AI-native 2026.
Si necesitás ayuda para evaluar el stack de tu SaaS con criterio antes que tendencia, trabajo en proyectos de software bajo solu30.
Preguntas frecuentes
¿Qué significa tener criterio técnico antes que framework? Significa evaluar primero qué problema tenés, qué restricciones reales existen y qué solución las resuelve, antes de preguntar qué framework está de moda. El framework puede acelerar la decisión pero no reemplazarla.
¿Cuándo un framework sí es la respuesta correcta? Cuando resuelve el problema real que tenés, cuando el equipo lo conoce y cuando el costo de adoptarlo es menor que el costo de construir la alternativa.
¿Cómo se aplica este principio en un SaaS de nicho? Evaluando si la restricción que enfrentás es técnica o de negocio. Muchas veces la solución correcta es más simple que el framework que todos recomiendan.
¿El criterio técnico reemplaza la experiencia con frameworks? No, la complementa. Conocer bien los frameworks disponibles es necesario para evaluar opciones. El criterio es lo que decide cuándo usarlos y cuándo no.