Un dato citado en r/microsaas generó una discusión larga y matizada sobre el futuro del negocio del software: según McKinsey, alrededor del 32% de las empresas —y más del 40% en el sector tecnológico— están optando por construir internamente en lugar de comprar software, porque sus propios equipos ya pueden montar versiones simples de las herramientas que necesitan usando agentes de código con IA. A primera vista, esto suena como una amenaza existencial para cualquiera que esté pensando en lanzar un SaaS. Analizado con más detenimiento, sin embargo, abre una categoría de oportunidad nueva que muy pocos founders están explorando todavía: construir las herramientas que esos equipos internos necesitan para que sus propios «mini-SaaS» no se conviertan en un problema mayor del que intentaban resolver.
Por qué las empresas están construyendo en lugar de comprar
La razón de fondo detrás de este cambio no es ideológica, es puramente económica. Hasta hace poco, construir una herramienta interna —por ejemplo, un dashboard de seguimiento de proyectos adaptado a un flujo de trabajo muy específico— requería asignar a un equipo de desarrollo dedicado durante semanas o meses, un coste que rara vez se justificaba frente a comprar una licencia de una herramienta ya existente, aunque no encajara perfectamente. Con agentes de código capaces de generar una primera versión funcional en cuestión de días, esa ecuación económica ha cambiado radicalmente: ahora, para necesidades simples y bien acotadas, construir internamente puede salir más barato que pagar una suscripción anual a una herramienta genérica, especialmente si esa herramienta genérica incluye funciones que la empresa nunca va a usar pero que sigue pagando.
Esto explica por qué el efecto es mucho más pronunciado en empresas de tecnología, donde ya existe el talento interno capaz de dirigir estos agentes de código de forma efectiva, y mucho menos pronunciado en sectores sin esa capacidad técnica interna, que seguirán dependiendo de proveedores de software externos durante bastante más tiempo.
El coste oculto de construir internamente
Lo que la mayoría de equipos no calcula bien al decidir construir en lugar de comprar es el coste total a largo plazo, más allá del coste inicial de desarrollo. Una herramienta interna construida rápidamente con un agente de código no viene con soporte, no tiene un roadmap de mejoras planificado, no incluye actualizaciones de seguridad automáticas, y casi nunca tiene documentación adecuada para que alguien distinto de quien la construyó pueda mantenerla en el futuro. Con el tiempo, estas «mini-herramientas» internas se acumulan en lo que en ingeniería de software se conoce como deuda técnica: código que funciona hoy pero que nadie entiende completamente, que nadie se atreve a modificar por miedo a romper algo, y que termina generando más fricción de la que la herramienta comprada originalmente habría evitado.
La oportunidad de negocio: gobernanza para software generado internamente
Aquí es donde aparece una categoría de SaaS completamente nueva: herramientas que ayuden a las empresas a gestionar, documentar, dar soporte y mantener observabilidad sobre todas esas mini-herramientas que sus propios equipos están construyendo con agentes de código. En lugar de vender «otra herramienta que hace X», este tipo de producto vende una capa de gobernanza que responde a preguntas que hoy nadie en la empresa puede contestar fácilmente: cuántas herramientas internas existen, quién las construyó, qué dependencias externas usan, cuándo se actualizaron por última vez, y qué pasaría si la persona que las construyó dejara la empresa mañana.
Un producto de este tipo podría escanear automáticamente los repositorios de código internos de una empresa, identificar qué proyectos son «mini-SaaS» construidos por equipos no técnicos con ayuda de agentes de IA, y generar un inventario centralizado con alertas sobre riesgos de seguridad, dependencias obsoletas o ausencia de documentación básica. Es, en esencia, aplicar a software interno generado por IA la misma disciplina de gestión de activos que ya existe para infraestructura tradicional, pero adaptada a una realidad nueva donde el volumen de «software en la sombra» está creciendo mucho más rápido de lo que los equipos de TI pueden supervisar manualmente.
Documentación automática: el problema que nadie quiere resolver manualmente
Una de las quejas más repetidas sobre el código generado con agentes de IA es que, aunque funcione correctamente, rara vez viene acompañado de documentación clara sobre cómo funciona o por qué se tomaron ciertas decisiones de diseño. Un SaaS que se conecte automáticamente a estos repositorios internos y genere, usando IA, documentación legible a partir del propio código y del historial de cambios, resuelve un problema que hoy prácticamente nadie prioriza hasta que ya es demasiado tarde: cuando la persona que construyó la herramienta ya no está disponible para explicarla. Esta función, aparentemente secundaria, puede convertirse en el argumento de venta principal para directores de tecnología que ya han vivido la experiencia de heredar un sistema interno sin ninguna documentación.
Soporte y mantenimiento como servicio, aplicado a herramientas hechas a medida
Otra vertiente de oportunidad es ofrecer, como servicio externo, el mantenimiento continuo de estas herramientas internas construidas rápidamente. Muchos equipos que construyen una herramienta con un agente de código no tienen intención ni capacidad de mantenerla activamente a largo plazo; simplemente necesitaban resolver un problema puntual. Un servicio que se especialice en «adoptar» estas herramientas huérfanas —revisando su código, corrigiendo problemas de seguridad, y ofreciendo un canal de soporte cuando algo falla— ocupa un espacio intermedio entre comprar software comercial completo y quedarse completamente solo con una herramienta interna sin respaldo, y es exactamente el tipo de servicio que crece en popularidad a medida que la cantidad de software generado internamente sigue aumentando.
Por qué esta categoría todavía está prácticamente vacía
La razón por la que apenas existen productos maduros en esta categoría todavía es que el propio fenómeno —empresas construyendo software interno a gran escala con agentes de IA— es reciente, y la mayoría de los equipos de TI todavía no han sentido el dolor acumulado de gestionar decenas de estas mini-herramientas dispersas. Eso es exactamente lo que hace interesante moverse ahora: construir una solución de gobernanza y observabilidad para este problema antes de que se convierta en una necesidad urgente y ampliamente reconocida da a un founder una ventana de tiempo considerable para perfeccionar el producto con clientes early adopters, en lugar de entrar en un mercado ya maduro y competitivo cuando el problema se vuelva evidente para todo el mundo.
Cómo validar esta idea dentro de una sola empresa amiga
Antes de construir un producto de escaneo automático de repositorios, la validación más directa consiste en ofrecerse a hacer manualmente ese inventario para una empresa conocida que ya tenga varios equipos construyendo herramientas internas con IA. Recorrer sus repositorios, catalogar qué herramientas existen, quién las mantiene y qué riesgos de seguridad o dependencias obsoletas presentan, y entregar ese informe como un documento estructurado, permite comprobar en cuestión de días si ese tipo de visibilidad genera valor real para un director de tecnología, antes de invertir en construir la automatización completa. Si el primer informe manual provoca la reacción de «esto no lo teníamos y lo necesitábamos», la idea está validada; si genera indiferencia, es una señal temprana de que el dolor todavía no es lo bastante agudo en esa organización concreta como para justificar un producto dedicado.
Un modelo de precios pensado para equipos de plataforma e ingeniería
El comprador natural de este tipo de producto no es un usuario individual, sino un equipo de plataforma o de seguridad interna, lo que sugiere un modelo de precios por empresa en lugar de por usuario, similar al de las herramientas de observabilidad de infraestructura tradicional. Cobrar en función del número de repositorios o proyectos internos monitorizados, con un nivel de precio que aumente según la profundidad del análisis (inventario básico frente a auditoría de seguridad completa con recomendaciones automáticas de remediación), permite capturar tanto a empresas pequeñas que solo quieren visibilidad básica como a organizaciones grandes con cientos de estas mini-herramientas dispersas, donde el riesgo acumulado —y por tanto la disposición a pagar por mitigarlo— es mucho mayor.
Los riesgos de construir en una categoría todavía inmadura
Entrar pronto en una categoría de producto tiene ventajas, pero también riesgos que conviene anticipar: si el problema que se está resolviendo todavía no es percibido como urgente por la mayoría de compradores potenciales, el ciclo de venta puede ser mucho más largo de lo esperado, porque hay que invertir tiempo en educar al mercado sobre por qué este riesgo merece atención antes de poder vender la solución. La forma de mitigar este riesgo es buscar activamente a las organizaciones que ya han sufrido un incidente relacionado —una herramienta interna que falló en un momento crítico, o una vulnerabilidad de seguridad descubierta en código generado por un agente de IA sin revisión adecuada— porque esos compradores ya tienen la urgencia necesaria y no requieren el mismo trabajo de educación previa que el resto del mercado.
Lo que esto significa para el resto de la industria del SaaS
Más allá de la oportunidad concreta de gobernanza, el dato de McKinsey señala un cambio estructural que cualquier fundador de SaaS debería tener en cuenta al diseñar su producto de aquí en adelante: si construir una versión simple de tu herramienta ya está al alcance de los propios clientes potenciales, competir únicamente en funcionalidad básica deja de ser una estrategia sostenible. La defensa a largo plazo para un SaaS ya no puede depender solo de «hacemos esto mejor que si lo construyeras tú mismo en un fin de semana», porque ese argumento cada vez convence a menos compradores técnicos. La defensa real está en la profundidad de los datos acumulados, la calidad del soporte, las integraciones con el resto del ecosistema, y la fiabilidad demostrada a largo plazo, elementos que un equipo interno construyendo una versión rápida con un agente de código simplemente no puede replicar en un fin de semana, por muy bueno que sea el modelo de IA que usen.