Tu equipo ya te propone cosas que no entiendes: así se filtran
No necesitas entender cada detalle técnico para decidir bien. Aprende a filtrar refactorizaciones, migraciones e inversiones con preguntas de negocio, costo, urgencia y operación.
Criterio tecnológico para dueños · 10 de septiembre de 2026 · 11 min de lectura
Tu app funciona. Tienes usuarios. Hay un equipo que la mantiene.
Y, sin embargo, cada cierto tiempo llega una junta en la que alguien suelta una frase que suena suficientemente técnica como para ser importante y suficientemente grave como para costar dinero:
“Tenemos que refactorizar esto.”
“Ya deberíamos migrar a microservicios.”
“Esta arquitectura no va a escalar.”
“Hay que cambiar esta parte antes de que se vuelva un problema.”
El problema no es que no entiendas cada detalle técnico.
El problema es que nadie te dio un filtro para decidir qué hacer con esas propuestas.
Entonces aparecen dos miedos opuestos: aprobar algo que en realidad no necesitabas y descubrir meses después que ahora tienes más infraestructura, más proveedores y más gasto; o frenarlo y quedarte con la duda de si algún día escucharás un “te dijimos que esto iba a pasar”.
Ahí es donde muchos dueños terminan diciendo sí por precaución.
No porque la propuesta esté justificada.
Porque no tienen suficientes elementos para cuestionarla.
Y dirigir tecnología así sale caro.
Decir sí a todo y decir no a todo son el mismo problema
Cuando no tienes criterio para evaluar una propuesta técnica, es fácil caer en uno de dos extremos.
El primero es aprobar casi todo para “no estorbarle al equipo”.
Suena razonable. Contrataste especialistas precisamente porque saben cosas que tú no sabes. Pero llevado demasiado lejos puede terminar en infraestructura sobredimensionada, herramientas que resuelven problemas que todavía no existen, servicios duplicados o una arquitectura mucho más sofisticada de lo que la operación realmente necesita.
El segundo extremo es rechazar cualquier iniciativa que no tenga un beneficio comercial evidente en ese mismo momento.
También parece prudente. Hasta que la deuda técnica se acumula, una vulnerabilidad permanece abierta demasiado tiempo o una parte crítica del sistema se vuelve cada vez más difícil de modificar.
Ninguna reacción es dirección.
Aprobar todo delega la decisión. Rechazar todo la bloquea. Dirigir consiste en pedir la evidencia suficiente para decidir.
Tu equipo ve cosas que tú no ves. Tú también.
Un desarrollador vive dentro del sistema.
Ve una clase que nadie quiere tocar, un proceso que tarda demasiado, una librería que dejó de recibir mantenimiento, una integración frágil, una base de datos que empieza a sufrir o una arquitectura que obliga a hacer cambios incómodos.
Que quiera corregirlo es legítimo.
De hecho, quieres que tu equipo detecte esos problemas antes de que se conviertan en incidentes.
Pero el criterio técnico es solo una parte de la decisión.
El equipo sabe cuánto duele mantener determinada pieza de software. Tú sabes cuánto factura el producto, qué tan rápido está creciendo, cuánto puedes invertir, qué compromisos comerciales existen y qué otras prioridades compiten por el mismo dinero.
Esa información no te pone en desventaja frente al técnico.
Es la parte de la decisión que solamente tú puedes aportar.
Por eso una buena propuesta de arquitectura no debería terminar en “esto es técnicamente mejor”. Debería poder conectar la decisión técnica con una consecuencia operativa o de negocio.
Incluso la documentación de Microsoft sobre arquitectura de microservicios advierte que este enfoque incorpora retos de complejidad, pruebas, operación, consistencia de datos, latencia, observabilidad y habilidades del equipo. Del mismo modo, el AWS Well-Architected Framework señala que dividir una aplicación en servicios más pequeños puede mejorar agilidad y escalabilidad, pero también aumentar la carga operativa y hacer más complejo depurar y rastrear interacciones.
La conclusión no es que una arquitectura sea buena y otra mala.
Es que la sofisticación técnica siempre tiene un costo que debe ganarse.
No todas las propuestas técnicas merecen la misma respuesta
Una forma sencilla de empezar a filtrar es separar lo que te propone el equipo en cuatro categorías.
Un filtro simple para clasificar lo que te propone el equipo
| Concepto | Cómo reconocerla | Qué hacer |
|---|---|---|
| Necesaria y urgente | Existe riesgo concreto de caída, pérdida de información, vulnerabilidad relevante o afectación inmediata a clientes | Atender y asignar responsable |
| Necesaria, no urgente | Hay deuda técnica o una limitación real, pero el sistema puede continuar operando razonablemente mientras se planea | Calendarizar, estimar y priorizar |
| Deseable | Mejoraría elegancia, experiencia técnica o capacidad futura, pero todavía no existe un problema de negocio que la exija | Pedir evidencia y comparar alternativas |
| Innecesaria hoy | Optimiza algo sin uso significativo, resuelve una escala que todavía no existe o agrega complejidad sin beneficio demostrable | No hacerla por ahora |
La diferencia está en la evidencia, no en cómo suena la propuesta
La diferencia parece obvia cuando la ves escrita.
En una junta no siempre lo es.
“Esto no escala” puede significar que el sistema ya está llegando a un límite medido.
O puede significar que, en teoría, llegará a ese límite cuando tenga diez veces más usuarios.
Son conversaciones completamente distintas.
Lo mismo ocurre con “hay que refactorizar”. Puede existir una pieza que ya provoca incidentes y frena entregas cada semana. O puede tratarse de código incómodo que al desarrollador le gustaría dejar más limpio.
Ambos problemas pueden ser reales.
Pero no necesariamente tienen la misma prioridad.
Las propuestas de las dos categorías intermedias —necesarias pero no urgentes y deseables— normalmente no necesitan aprobarse en la misma junta en la que aparecen.
Necesitan convertirse en decisiones.
Las cuatro preguntas que cambian la junta
No necesitas aprender Kubernetes, patrones de diseño ni arquitectura distribuida para evaluar mejor una inversión técnica.
Necesitas hacer cuatro preguntas.
1. ¿Qué problema real de negocio resuelve esto y qué pasa si no lo hacemos?
Esta pregunta obliga a bajar la propuesta desde la arquitectura hasta la operación.
No basta con:
“Va a escalar mejor.”
¿Hoy existe un problema de capacidad?
¿Cuántos usuarios soporta la arquitectura actual?
¿Cuánto crecimiento esperamos?
¿Qué métrica indica que nos estamos acercando al límite?
Tampoco basta con:
“Tenemos mucha deuda técnica.”
¿Dónde se manifiesta?
¿Está provocando errores?
¿Hace más lentas las entregas?
¿Aumenta el tiempo de soporte?
¿Impide modificar una parte importante del producto?
Si el problema no puede describirse todavía, quizá la propuesta necesita más diagnóstico antes de presupuesto.
2. ¿Cuánto cuesta mantenerlo al año, no solamente implementarlo?
Muchas decisiones parecen baratas cuando se presentan como proyecto.
“Nos toma tres semanas.”
“Solo necesitamos contratar este servicio.”
“La migración no es tan complicada.”
Pero después llegan los costos que no estaban en la diapositiva: infraestructura, monitoreo, respaldos, licencias, alertas, actualizaciones, soporte, disponibilidad, documentación y tiempo del equipo.
El State of the Cloud Report 2026 de Flexera, elaborado con 753 profesionales y líderes relacionados con cloud, encontró que las organizaciones encuestadas estiman en 29% el gasto desperdiciado en IaaS y PaaS.
Eso no significa que 29% de tu factura esté necesariamente mal gastada.
Sí demuestra algo más útil: incluso organizaciones que trabajan activamente con infraestructura cloud siguen teniendo dificultades para convertir consumo técnico en gasto eficiente.
Por eso la pregunta correcta rara vez es “¿cuánto cuesta migrar?”.
Es:
¿cuánto cuesta vivir con esta decisión todos los años?
3. ¿Qué se rompe si lo dejamos seis meses para después?
Esta es probablemente la pregunta más incómoda para una propuesta que llegó demasiado pronto.
Si la respuesta es:
“Nada se rompe, pero después será más difícil.”
Perfecto. Entonces ya sabes que existe una deuda que puedes planear.
Si la respuesta es:
“Tenemos una vulnerabilidad explotable en un componente expuesto.”
La prioridad cambia.
Si la respuesta es:
“Con el crecimiento actual, en dos meses llegaremos al límite que medimos en producción.”
También cambia.
El objetivo no es retrasar todo seis meses.
Es separar urgencia demostrada de urgencia percibida.
Una arquitectura sana no se construye reaccionando a cada incomodidad técnica. Tampoco ignorándola. Se construye haciendo visible cuándo una limitación empieza a convertirse en riesgo.
4. ¿Quién lo va a operar y mantener cuando esté listo?
Una tecnología no termina el día que se libera a producción.
Ese día empieza su vida real.
Si migras a otra plataforma, introduces un nuevo lenguaje o divides el sistema en múltiples servicios, alguien tendrá que entenderlo cuando falle, actualizarlo, monitorearlo y explicárselo al siguiente desarrollador que entre al equipo.
Microsoft incluye precisamente el skill set y una cultura DevOps madura entre los factores que deben evaluarse antes de adoptar microservicios. AWS, por su parte, señala que una mayor segmentación implica operar más componentes independientes.
Esto vuelve muy concreta una pregunta que a veces parece secundaria:
¿estamos comprando capacidad o estamos comprando dependencia?
Una solución puede ser técnicamente excelente y seguir siendo una mala decisión para tu empresa si solo una persona sabe mantenerla.
El costo técnico que no aparece en la factura de AWS
Cuando alguien habla de sobrearquitectura, es fácil imaginar únicamente servidores caros.
Ese no siempre es el costo más importante.
También pagas cuando:
- un nuevo desarrollador tarda semanas en entender una infraestructura innecesariamente compleja;
- una funcionalidad simple exige modificar varios servicios;
- cada despliegue depende de más piezas;
- un incidente requiere revisar múltiples registros y sistemas;
- una tecnología poco común reduce la cantidad de personas que puedes contratar para mantenerla;
- el equipo dedica más tiempo a operar la plataforma que a resolver necesidades del producto.
Esto no convierte la complejidad en algo malo.
Hay empresas cuya escala, disponibilidad, número de equipos o necesidad de despliegues independientes justifican perfectamente esa inversión.
Pero la complejidad debería aparecer después de que el problema la exige, no antes porque la arquitectura “se ve más seria”.
Martin Fowler lleva años describiendo este fenómeno como el **microservice premium**: la complejidad adicional que incorpora una arquitectura de microservicios y que solo compensa cuando el sistema realmente necesita las ventajas que ofrece.
Amazon también tuvo que cuestionar una arquitectura que parecía correcta
Uno de los ejemplos más citados sobre este tema viene de Prime Video.
En 2023, el equipo encargado de un servicio de análisis de calidad de audio y video explicó que había construido inicialmente una solución distribuida con componentes serverless. Al intentar llevarla a la escala requerida encontró límites técnicos y costos demasiado altos.
La solución no fue agregar todavía más infraestructura.
El equipo movió los componentes de ese servicio específico a un solo proceso, reduciendo transferencias entre componentes y simplificando la orquestación. Según el caso publicado por Prime Video y recogido por The Stack, el cambio redujo en más de 90% el costo de infraestructura del servicio.
El dato interesante no es “Amazon descubrió que los monolitos son mejores”.
No descubrió eso.
Lo interesante es que un equipo de una de las compañías con más experiencia en infraestructura cloud encontró que una arquitectura que parecía apropiada dejó de tener sentido cuando la confrontaron con costo, escala y comportamiento real.
Eso es exactamente lo que deberías exigirle a una propuesta técnica.
No fidelidad a una moda.
Evidencia.
“Lo correcto” depende del problema que tienes
Hay momentos en los que migrar a microservicios es una decisión excelente.
Si distintos dominios del producto necesitan escalar de forma independiente, si varios equipos deben desplegar sin coordinar cada liberación, si necesitas aislar ciertos fallos o si una parte del sistema tiene demandas radicalmente distintas, la separación puede generar valor real.
También hay momentos en los que mantener una aplicación modular dentro de una arquitectura más sencilla es perfectamente razonable.
De hecho, la propia guía de modernización de AWS recomienda evaluar qué aplicaciones realmente deben descomponerse y comprender primero el caso de negocio, la tecnología y sus dependencias.
Ese es el punto que suele perderse cuando una decisión se convierte en discusión de tecnología.
La pregunta no debería ser:
“¿Microservicios o monolito?”
Debería ser:
“¿Qué presión real del negocio o del sistema hace que necesitemos cambiar lo que tenemos?”
Cuando aparece esa presión, entonces sí tiene sentido discutir arquitectura.
Así se ve una propuesta lista para aprobarse
Imagina que tu equipo llega con esto:
“Queremos migrar el módulo de generación de reportes a un servicio independiente.”
Podrías aprobarlo porque suena razonable.
O podrías pedir que la propuesta llegue así:
Problema: los reportes consumen tantos recursos que, durante ciertos horarios, afectan la respuesta de las funciones principales de la aplicación.
Evidencia: los registros muestran degradación de X a Y durante la generación masiva y ya tuvimos determinados incidentes relacionados.
Alternativas: optimizar consultas, ejecutar procesos en segundo plano, aumentar temporalmente recursos o separar el procesamiento.
Costo de implementación: estimación de horas, infraestructura y riesgo de migración.
Costo recurrente: infraestructura, monitoreo y mantenimiento anual estimado.
Consecuencia de esperar seis meses: con el crecimiento proyectado, se espera determinada carga o frecuencia de incidentes.
Responsable: persona o equipo que operará el componente después de liberarlo.
Ahora tienes una decisión.
Tal vez siga siendo técnica.
Pero ya no es ciega.
Tu trabajo no es convertirte en CTO
Puedes dirigir una empresa de software sin saber escribir código.
También puedes ser dueño de una empresa con un sistema propio sin aprender cada herramienta que usa tu equipo.
Lo que no puedes delegar por completo es el criterio con el que se asigna dinero, tiempo y complejidad.
Cuando alguien te proponga una migración, una refactorización o una nueva pieza de infraestructura, no necesitas responder de inmediato.
Antes de aprobar una propuesta técnica, verifica esto
- ¿Qué problema real resuelve y qué pasa si no lo hacemos?
- ¿Cuánto cuesta mantenerlo al año?
- ¿Qué se rompe si esperamos seis meses?
- ¿Quién lo operará cuando esté listo?
Dirigir no significa desconfiar de tu equipo
Si la propuesta no puede responder esas cuatro preguntas, todavía no está lista para que la apruebes.
Eso no significa desconfiar de tu equipo.
Significa dirigirlo.
Y quizá esa sea la diferencia más importante: dejar de decir “confío en ti, hazlo” y empezar a decir “entiendo por qué lo necesitamos; hagámoslo”.
¿Cuándo fue la última vez que frenaste una propuesta técnica con una pregunta y no simplemente con un sí?