Usar menos frameworks reduce el cambio de contexto, simplifica la incorporación y fortalece las herramientas compartidas, ayudando a los equipos a entregar funciones más rápido con menos sorpresas.
"Menos frameworks" no significa reducir toda tu pila tecnológica a una única herramienta. Significa limitar intencionadamente el número de formas de construir la misma clase de cosa—para que los equipos puedan compartir código, habilidades, patrones y herramientas en lugar de reinventarlos.
La proliferación de frameworks ocurre cuando una organización acumula múltiples frameworks solapados para productos similares—a menudo por adquisiciones, alta autonomía de equipos o decisiones de "probemos esto" que nunca se retiran.
Ejemplos comunes:
Ninguno de estos es automáticamente incorrecto. El problema surge cuando la variedad supera tu capacidad de soportarla.
Velocidad no es "cuántos puntos quemamos". En equipos reales, la velocidad se manifiesta como:
Cuando los frameworks se multiplican, estas métricas suelen degradarse porque cada cambio requiere más contexto, más traducción y más herramientas a medida.
La consolidación es una estrategia, no un contrato de por vida. Un enfoque sano es: elegir un pequeño conjunto que encaje con tus necesidades ahora, establecer puntos de revisión (p. ej., anual) y hacer que el cambio sea una decisión deliberada con un plan de migración.
Cederás cierta optimización local (equipos eligiendo su herramienta favorita) por ganancias a nivel de sistema (onboarding más rápido, componentes compartidos, CI/CD más simple y menos fallos de casos límite). El resto de este artículo cubre cuándo vale esa compensación—y cuándo no.
Los equipos rara vez adoptan “solo un framework más” y sienten el coste de inmediato. El impuesto aparece como pequeños retrasos—reuniones extra, PRs más largos, configuraciones duplicadas—que se acumulan hasta que la entrega se siente más lenta aunque todos trabajen duro.
Cuando hay múltiples formas aceptables de construir la misma funcionalidad, los ingenieros pasan tiempo eligiendo en lugar de construyendo. ¿Esta página usa el routing del Framework A o del B? ¿Qué enfoque de estado? ¿Qué test runner? Incluso si cada elección toma 30 minutos, repetida en muchas tareas consume días.
Con una pila mixta, las mejoras no se propagan. Una corrección de rendimiento, un patrón de accesibilidad o un enfoque de manejo de errores aprendido en un framework a menudo no se puede reutilizar en otro sin traducirlo. Eso hace que los mismos bugs reaparezcan y que las mismas lecciones las vuelvan a aprender equipos distintos.
Los patrones inconsistentes obligan a los revisores a cambiar de contexto. Un PR no es solo “¿es correcto?”—también es “¿cómo espera este framework que se haga esto?” Eso aumenta el tiempo de revisión y eleva el riesgo de errores, porque los casos límite específicos del framework se cuelan.
La proliferación de frameworks tiende a duplicar trabajo en:
El resultado no es solo código extra: es mantenimiento extra. Cada framework adicional añade otro conjunto de actualizaciones, parches de seguridad y conversaciones de “¿cómo hacemos X aquí?”.
La velocidad no es solo lo rápido que alguien escribe código: es lo rápido que puede entender un problema, hacer un cambio seguro y desplegar con confianza. La proliferación de frameworks aumenta la carga cognitiva: los desarrolladores pasan más tiempo recordando “cómo hace las cosas esta app” que resolviendo la necesidad del usuario.
Cuando los equipos manejan múltiples frameworks, cada tarea incluye un coste oculto de calentamiento. Cambias mentalmente entre sintaxis, convenciones y herramientas. Incluso diferencias pequeñas—patrones de routing, defaults de gestión de estado, librerías de testing, configs de build—añaden fricción.
Esa fricción aparece como revisiones más lentas, más mensajes de “espera, ¿cómo hacemos X aquí?” y mayor lead time para cambios. En una semana, no es un gran retraso de una vez; son docenas de pequeños retrasos.
La estandarización mejora la productividad porque hace el comportamiento predecible. Sin ella, depurar se convierte en una búsqueda del tesoro:
El resultado: más tiempo diagnosticando, menos tiempo construyendo.
Integraciones comunes como auth, analytics y reporting de errores deberían ser aburridas. Con muchos frameworks, cada integración necesita glue code personalizado y manejo especial—creando más casos límite y más formas de romper silenciosamente. Eso aumenta la carga operativa y hace el on-call más estresante.
La velocidad del equipo depende de refactorizaciones con confianza. Cuando pocas personas entienden realmente cada base de código, los ingenieros dudan en hacer mejoras estructurales. Parchean alrededor de los problemas en vez de arreglarlos, lo que aumenta la complejidad y mantiene la carga cognitiva en ascenso.
Tener menos frameworks no elimina problemas difíciles—pero reduce el número de momentos de “¿por dónde empezamos?” que drenan tiempo y enfoque.
La proliferación de frameworks no solo ralentiza la entrega de features: también hace más difícil que la gente colabore. Cuando cada equipo tiene su propia “forma de construir”, la organización paga en tiempo de rampa, fricción en contratación y colaboración más débil.
Los nuevos deben aprender tu producto, tus clientes y tu flujo de trabajo. Si además tienen que aprender múltiples frameworks para contribuir, el onboarding se alarga—especialmente cuando el “cómo construimos” varía por equipo.
En lugar de ganar confianza por repetición (“así estructuramos las páginas”, “así obtenemos datos”, “así testeamos”), están constantemente cambiando de contexto. El resultado es más espera a otros, más errores pequeños y un camino más largo hacia la propiedad independiente.
La mentoría funciona mejor cuando los seniors detectan problemas rápidamente y enseñan patrones transferibles. Con muchos frameworks, la mentoría pierde eficacia porque los seniors se dispersan entre stacks.
Acabas con:
Un conjunto más pequeño de frameworks compartidos permite que los seniors mentoreen con apalancamiento: la guía se aplica a muchos repos y los juniors reutilizan lo aprendido inmediatamente.
Contratar se complica con una larga lista de frameworks “imprescindibles”. Los candidatos se autoexcluyen (“no tengo experiencia con X, Y y Z”) o las entrevistas derivan en trivia de herramientas en lugar de resolver problemas.
Con una pila estándar puedes contratar por fundamentos (pensamiento de producto, debug, diseño de sistemas) y formar en los detalles del framework de forma consistente.
La ayuda entre equipos—pairing, code reviews, soporte en incidentes—funciona mejor con patrones compartidos. Cuando la gente reconoce la estructura de un proyecto, puede contribuir con confianza, revisar más rápido y entrar en momentos urgentes.
Estandarizar unos pocos frameworks no eliminará todas las diferencias, pero aumenta dramáticamente la superficie en la que “cualquier ingeniero puede ayudar”.
Cuando los equipos comparten un pequeño conjunto de frameworks, la reutilización deja de ser aspiracional y se vuelve rutinaria. Los mismos bloques de construcción funcionan en varios productos, así que la gente pasa menos tiempo resolviendo lo mismo y más tiempo entregando.
Un design system es “real” cuando es fácil de adoptar. Con menos stacks, una única librería UI puede servir a la mayoría de equipos sin necesitar múltiples puertos (versión React, versión Vue, versión “legacy”). Eso significa:
La variedad de frameworks a menudo obliga a equipos a reconstruir utilidades idénticas—a veces con comportamientos ligeramente distintos. Estandarizar hace práctico mantener paquetes compartidos para:
En lugar de “nuestra app lo hace distinto”, obtienes patrones portables en los que los equipos pueden confiar.
Accesibilidad y calidad son más fáciles de imponer cuando los mismos componentes y patrones se usan en todas partes. Si tu componente de input incorpora comportamiento de teclado, estados de foco y atributos ARIA, esas mejoras se propagan automáticamente por los productos.
De forma similar, linters compartidos, helpers de testing y listas de verificación de revisión cobran sentido porque aplican a la mayoría de repos.
Cada framework multiplica la documentación: guías de setup, uso de componentes, convenciones de testing, notas de despliegue. Con menos stacks, la documentación se vuelve más clara y completa porque la mantiene más gente y se usa con más frecuencia.
El resultado son menos “casos especiales” y menos workarounds tribales—especialmente valioso para nuevos que leen playbooks internos.
La velocidad no es solo qué tan rápido escribe código un desarrollador. También es qué tan rápido ese código puede construirse, probarse, desplegarse y operarse de forma segura. Cuando los equipos usan un pequeño y acordado conjunto de frameworks, tu "máquina de producción" se simplifica—y notablemente se acelera.
La proliferación suele significar que cada repo necesita lógica de pipeline especial: comandos de build distintos, test runners distintos, pasos de containerización distintos, estrategias de caching diferentes. Estandarizar reduce esa variedad.
Con pasos de build y test consistentes puedes:
En lugar de pipelines a medida, tendrás unos pocos patrones aprobados que la mayoría de proyectos puede adoptar con mínimos ajustes.
Una gran variedad de frameworks expande tu superficie de dependencias. Eso aumenta los avisos de vulnerabilidad que debes rastrear, los tipos de parches y la probabilidad de que una actualización rompa algo.
Con menos frameworks puedes estandarizar cómo manejar:
Esto convierte el trabajo de seguridad en mantenimiento de rutina y no en apagar fuegos—especialmente cuando aparece una vulnerabilidad crítica y hay que parchear muchos repos.
Logging, métricas y tracing son más útiles cuando son consistentes. Si cada framework tiene un stack de middleware distinto, convenciones diferentes para request IDs y límites de error dispares, la observabilidad se fragmenta.
Una pila más pequeña permite alinear defaults comunes (logs estructurados, dashboards compartidos, trazas consistentes) para que los equipos pasen menos tiempo “haciendo que la telemetría funcione” y más tiempo usándola para mejorar la fiabilidad.
Linters, generación de código, plantillas y herramientas de scaffolding son caras de construir y mantener. Pagan cuando muchos equipos pueden usarlas con poco ajuste.
Cuando estandarizas frameworks, el trabajo de plataforma o enablement escala: una buena plantilla acelera docenas de proyectos, y un conjunto de convenciones reduce ciclos de revisión en toda la organización.
Como ejemplo relacionado: algunos equipos usan una plataforma de “vibe-coding” como Koder.ai para imponer una pila paved-road en herramientas internas nuevas—p. ej., generar frontends React y backends Go + PostgreSQL desde un flujo de chat—de modo que la salida encaje con los defaults de la organización (y aún así pueda exportarse como código fuente y mantenerse como cualquier otro repo).
Elegir menos frameworks no significa escoger un ganador único para siempre. Significa definir una pila por defecto y un conjunto corto y claro de alternativas aprobadas—para que los equipos puedan moverse rápido sin debatir fundamentos cada sprint.
Apunta a una por cada gran superficie (por ejemplo: front end, servicios backend, móvil, datos). Si realmente necesitas opciones, limítalas a 1–2 por plataforma. Una regla simple: si un proyecto nuevo empieza, debería poder elegir el por defecto sin reunirse.
Esto funciona mejor cuando la pila por defecto es:
Acordad criterios fáciles de explicar y difíciles de manipular:
Si un framework puntúa bien pero aumenta la complejidad operativa (tiempos de build, ajuste en runtime, respuesta a incidentes), trátalo como un coste real—no como algo secundario.
Crea un grupo pequeño (normalmente equipo de plataforma o un consejo de ICs senior) para aprobar excepciones. Mantenlo rápido:
Haz los estándares descubribles y actuales. Pon la pila por defecto, la lista aprobada y el proceso de excepciones en una única fuente de verdad (por ejemplo: /docs/engineering-standards), y enlázala desde plantillas de proyecto y materiales de onboarding.
Estandarizar en menos frameworks no requiere una reescritura dramática. Las migraciones más seguras se sienten casi aburridas: ocurren en pasos pequeños, siguen entregando valor y reducen riesgo en cada release.
Comienza haciendo que la pila estándar sea la opción por defecto para todo lo nuevo: apps nuevas, servicios, superficies UI nuevas y herramientas internas. Esto frena la proliferación sin tocar sistemas legacy.
Si una app legacy es estable y entrega valor, déjala por ahora. Las reescrituras forzadas suelen crear congelamientos largos, plazos perdidos y un equipo distraído. En su lugar, que la migración la impulse el cambio real de producto.
Cuando haya que modernizar, migra siguiendo límites naturales:
El patrón es simple: mantiene el sistema antiguo funcionando, redirige una porción funcional al nuevo stack y repite. Con el tiempo la implementación nueva “estrangulará” a la antigua hasta que el legado restante sea pequeño y seguro de retirar.
La gente sigue el camino de menor resistencia. Crea plantillas y kits de inicio que incorporen tus estándares:
Ponlos en un lugar conocido y enlázalos desde la docs internas (p. ej., /engineering/stack y /engineering/starter-kits).
La migración falla cuando no es responsabilidad de nadie. Para cada framework o dependencia que retires define:
Publica el progreso y las excepciones abiertamente, para que los equipos puedan planificar en vez de descubrir cambios rotos al último minuto.
La estandarización funciona solo si es realista. Habrá momentos en que un framework no estándar sea la decisión correcta—pero necesitas reglas que impidan que “una excepción” se convierta en cinco stacks paralelos.
Permite excepciones solo por razones claras y defendibles:
Si la justificación es “al equipo le gusta”, trátala como preferencia hasta que se respalde con resultados medibles.
Cada excepción debe enviarse con un “contrato de soporte” ligero, acordado por adelantado:
Sin esto, estás aprobando un coste operacional futuro sin presupuesto asociado.
Las excepciones deben expirar a menos que se renueven. Una regla simple: revisar cada 6–12 meses. En la revisión, pregunta:
Crea una lista corta para separar gusto personal de necesidad real: objetivos de rendimiento, requisitos de cumplimiento, coste total de propiedad, impacto en contratación/onboarding e integración con CI/CD y observabilidad. Si no pasa la lista, no entra en la pila.
Consolidar frameworks es una apuesta: menos proliferación debería reducir carga cognitiva y aumentar productividad. Para saber si la apuesta funcionó, mide resultados en el tiempo—no solo sensaciones durante la migración.
Elige una ventana base (p. ej., 6–8 semanas antes de la consolidación) y compárala con periodos en estado estable después de que los equipos hayan entregado trabajo real en la pila estandarizada. Espera una caída temporal durante la transición; lo que importa es la tendencia una vez absorbido el cambio.
Usa un conjunto pequeño de métricas que reflejen el camino completo de la idea al software en ejecución:
Son especialmente útiles para equipos de plataforma y de enablement porque son difíciles de manipular y fáciles de graficar.
La consolidación debería reducir el tiempo de incorporación. Mide:
También observa señales de colaboración entre equipos, como cuántas veces se reutilizan componentes compartidos sin retrabajo.
Monitorea tiempo de revisión de PR, bucles de rework y tasas de defectos antes y después de la estandarización. Más rápido es mejor solo si la calidad se mantiene.
Haz encuestas cortas y recurrentes (5 preguntas máximo) sobre fricción percibida, calidad de la documentación y confianza al desplegar cambios. Combina esto con algunas entrevistas para captar lo que las métricas no muestran.
Estandarizar en menos frameworks es menos una decisión técnica que una decisión de confianza. La gente teme que una regla de “una sola pila” frene la innovación, cree lock-in o quite autonomía. Avanzar será más fácil si respondes a esos miedos directamente y haces que el camino parezca práctico, no punitivo.
“Esto matará la innovación.” Aclara que el objetivo es entregar más rápido, no reducir la experimentación. Fomenta pruebas con límite de tiempo, pero fija la expectativa de que los experimentos exitosos deben facilitar su adopción amplia—o deben quedarse contenidos.
“Nos quedaremos encerrados.” El lock-in suele venir del glue personalizado y conocimiento tribal, no de elegir un framework popular. Reduce el lock-in documentando límites claros (APIs, tokens de diseño, contratos de servicio) para que las elecciones de framework no se filtren por todas partes.
“Quitáis autonomía a los equipos.” Replantea la autonomía como lograr resultados con menos fricción. Los equipos siguen decidiendo dirección de producto; la plataforma simplemente elimina la varianza evitable en cómo se construye y opera el trabajo.
Ofrece una pila por defecto bien soportada (la paved road): plantillas, librerías, docs y tooling listo para on-call. Luego define un proceso claro de excepciones para casos en que la opción por defecto no encaje—así las excepciones son visibles, justificadas y soportadas sin recrear la proliferación.
Lanza un proceso RFC para los estándares, organiza office hours recurrentes y ofrece soporte de migración (ejemplos, pairing y un backlog de “victorias fáciles”). Publica una página sencilla con los frameworks elegidos, versiones soportadas y qué significa “soportado”.
¿Cuándo puede justificarse mantener múltiples frameworks?
Unos pocos casos son razonables: experimentos de corta duración donde aprender rápido importa más que el mantenimiento; productos adquiridos que no puedes refactorizar de inmediato; y restricciones de tiempo de ejecución verdaderamente distintas (p. ej., embebido vs web). La clave es tratarlos como excepciones con plan de salida, no como un “vale todo” permanente.
¿Cómo decidimos entre “estandarizar”, “modularizar” o “reescribir”?
¿Y si los equipos ya invirtieron mucho en stacks distintos?
No invalides el trabajo. Empieza por alinear en interfaces: contratos de componentes, convenciones de API, observabilidad y requisitos de CI/CD. Luego elige un framework por defecto para lo nuevo y converge gradualmente migrando las áreas de mayor cambio (no las más “molestas”).
Para orientación más profunda, ve a /blog/engineering-standards. Si evalúas herramientas de enablement o soporte de plataforma, /pricing puede ayudar.
"Menos frameworks" significa limitar el número de formas solapadas de construir el mismo tipo de producto (por ejemplo: una pila web UI por defecto, un framework de servicios por defecto), para que los equipos puedan reutilizar habilidades, componentes, herramientas y prácticas operativas.
No implica reducir todo a una sola herramienta ni prohibir excepciones; se trata de reducir la variedad innecesaria.
La proliferación de frameworks ocurre cuando acumulas múltiples stacks que resuelven problemas similares (a menudo por autonomía, adquisiciones o experimentos que nunca se retiran).
Una comprobación rápida: si dos equipos no pueden compartir componentes, revisar código o ayudarse en on-call porque sus apps “funcionan distinto”, estás pagando el impuesto de la proliferación.
Mide la velocidad de extremo a extremo, no por puntos de historia. Señales útiles incluyen:
Sí—cuando las restricciones son genuinamente diferentes o tienen límite temporal. Casos válidos comunes:
Trata estos casos como excepciones con propiedad explícita y fecha de revisión.
Elige una pila por defecto para cada superficie principal (web, servicios, móvil, datos) y permite sólo 1–2 alternativas aprobadas.
Acordad criterios antes de debatir herramientas:
La meta es que nuevos proyectos elijan la opción por defecto .
Mantén la gobernanza ligera y rápida:
Documenta todo en un lugar obvio (p. ej., /docs/engineering-standards).
Evita reescrituras de golpe. Patrones más seguros:
Esto reduce el riesgo mientras se sigue entregando valor de producto continuamente.
Requiere un “contrato de soporte” antes de aprobar la excepción:
Si una excepción no puede comprometerse a soporte y revisión, probablemente es solo una preferencia y recreará la proliferación.
La consolidación suele ayudar porque aumenta la reutilización y reduce el tiempo de rampa:
Mide “tiempo hasta el primer PR mergeado” y “tiempo hasta la primera feature desplegada” para visibilizar el impacto.
Haz que se sienta como habilitación, no castigo:
Enlaza los estándares y el proceso de excepciones desde el onboarding y las plantillas (p. ej., /docs/engineering-standards).
Toma una línea base antes de la consolidación, espera una caída temporal durante la transición y luego compara tendencias una vez que los equipos están en estado estable.
