La semana pasada vi a un desarrollador junior de nuestro equipo poner en marcha una aplicación CRUD funcional con autenticación, migraciones de bases de datos y una interfaz de usuario medianamente decente en unos 90 minutos. Con Copilot. Desde cero.
Hace cinco años, esa misma tarea habría llevado una semana. Tal vez dos si se cuenta el yak-shaving alrededor de las configuraciones de despliegue y los flujos de OAuth. Y ese cambio, esa compresión del tiempo de construcción de días a horas, está desmantelando silenciosamente una de las cuestiones más antiguas del software: ¿debemos construir o debemos comprar?
El viejo marco está muerto
Durante décadas, "construir frente a comprar" era un cálculo de costes. Se estimaba cuántos meses-desarrollador se necesitarían para construir una cosa, se multiplicaba por el salario cargado, se añadía algún amortiguador para el mantenimiento, y se comparaba con la cuota de licencia anual de cualquier producto SaaS que hiciera más o menos lo mismo. Si el SaaS era más barato, usted compraba. Si sus requisitos eran lo suficientemente extraños, usted construía.
Ese marco suponía que construir era caro. Y lo era. Pero según los datos de Octoverse 2025 de GitHub, el desarrollo asistido por IA produce ahora un aumento del rendimiento del 20 al 30 por ciento. El 80% de los nuevos desarrolladores en GitHub utilizan Copilot en su primera semana. Más de 1,1 millones de repositorios públicos ya integran los SDK de LLM. Construir se ha abaratado drásticamente, casi de la noche a la mañana.
Así que la pregunta ya no es realmente "construir vs comprar". Es algo más como: ¿qué está pagando realmente cuando compra SaaS?
El nuevo cálculo
Esto es lo que creo que la mayoría de los fundadores de SaaS (yo incluido, sinceramente) no quieren oír: si toda su propuesta de valor es "le evitamos construirlo", tiene problemas. Porque ese foso acaba de hacerse mucho menos profundo.
Cuando un equipo puede crear un prototipo de una herramienta interna funcional en un día, el listón de lo que justifica una suscripción mensual sube mucho. Usted no sólo necesita ser mejor que lo que ellos podrían construir. Tiene que ser mejor que lo que ellos podrían construir con la ayuda de la IA.
Gartner predijo en abril de 2026 que para 2028, más de la mitad de las empresas dejarán de pagar por la inteligencia asistida y favorecerán las plataformas que se comprometan con los resultados del flujo de trabajo. Aún más crudo: prevén que para 2030, las empresas de software que superpongan IA sobre aplicaciones heredadas en lugar de rediseñarlas para la ejecución agéntica se enfrentarán a una compresión de márgenes de hasta el 80%.
Ochenta por ciento. No se trata de un error de redondeo.
Entonces, ¿qué es lo que realmente sobrevive?
He estado pensando mucho en esto, en parte porque estamos construyendo Rasepi y necesito ser honesto conmigo mismo sobre dónde se encuentra nuestro valor. Y creo que la respuesta se reduce a tres cosas que son realmente difíciles de replicar con un sprint de codificación de fin de semana, por muy bueno que sea su asistente de IA.
**Cualquiera puede construir un editor de texto. ¿Construir un sistema de traducción que rastree los cambios de contenido a nivel de párrafo, detecte las traducciones obsoletas mediante hash de contenido y gestione la adaptación estructural entre idiomas? Eso lleva años de conocimiento del dominio incorporado en la arquitectura. La IA puede ayudarle a escribir el código más rápido, pero no puede decirle qué construir.
Alguien todavía tiene que ejecutarlo y mantenerlo. Esto es lo que pasa con la construcción: es divertida. ¿Mantener? Nada divertido. Manejar casos extremos en sistemas de permisos multiusuario, mantenerse al día con las peculiaridades de los navegadores, gestionar migraciones de bases de datos entre versiones, parchear CVE a las 2 de la madrugada, lidiar con ese error de exportación de PDF que sólo aparece en Safari. La IA hace que la compilación inicial sea más rápida, seguro. Pero la investigación de Forrester de abril de 2026 muestra que la mayoría de las empresas aún no pueden convertir la adopción de la IA en un impacto medible, en parte porque la parte difícil nunca fue escribir código. Es mantenerlo en funcionamiento, actualizado y funcionando correctamente durante años. La construcción es la parte fácil. Es el tiempo de actividad, las rotaciones de guardia y las correcciones incrementales lo que realmente le cuesta.
Confianza, seguridad y privacidad de los datos. Este aspecto está infravalorado. Cuando construye algo usted mismo, usted es el dueño de la seguridad. Usted es responsable de la encriptación en reposo, el registro de auditoría, las pruebas de penetración, el cumplimiento del GDPR, SOC 2, y la próxima regulación de la que nadie ha oído hablar todavía. Un buen proveedor de SaaS tiene un equipo entero cuyo único trabajo es asegurarse de que sus datos no terminan en algún lugar donde no deberían estar. Para la mayoría de las empresas, ése no es un coste que quieran asumir internamente. Y, sinceramente, la mayoría de las herramientas internas que he visto ni siquiera tienen controles de acceso adecuados, por no hablar de una pista de auditoría de seguridad.
El término medio componible
Lo interesante es que la respuesta cada vez más no es "construir" o "comprar". Es componer. Elija las herramientas SaaS que hacen bien las cosas difíciles, exponen buenas API y le permiten construir a su alrededor.
Esta es la razón por la que las arquitecturas de plugins importan tanto ahora mismo (y sí, esto es exactamente en lo que hemos estado invirtiendo con el sistema de plugins de Rasepi). Los productos SaaS que prosperarán son los que digan: "Nosotros nos encargamos del núcleo duro y específico del dominio. Usted personaliza todo lo demás". No "aquí está nuestro monolito, tómelo o déjelo".
El informe de Forrester de abril de 2026 descubrió que la mayoría de las empresas siguen luchando por convertir la adopción de la IA en un impacto empresarial medible. Las empresas que más la adoptan tienen un 47% más de probabilidades de trabajar con socios consultores para preparar sus datos y sistemas. El mensaje es claro: la capacidad bruta de construcción no es el cuello de botella. Saber qué construir y disponer de la infraestructura que lo respalde es la verdadera limitación.
Lo que esto significa para SaaS
Si usted dirige una empresa SaaS en 2026, creo que hay algunas verdades incómodas:
- Su argumento "le ahorraremos tiempo" es más débil que nunca. El ahorro de tiempo era la venta clásica de SaaS. Pero cuando la IA comprime el tiempo de construcción en un 20-30%, la cifra de "tiempo ahorrado" en su hoja de cálculo de ROI se reduce proporcionalmente. Necesita una historia diferente.
- Las características son apuestas de mesa, los resultados son el producto. A nadie le importa que tenga 47 integraciones. Les importa que su documentación se mantenga actualizada, que sus traducciones sean precisas, que su equipo utilice realmente la herramienta. El lenguaje de Gartner sobre el "flujo de trabajo centrado en los resultados" no es sólo jerga de analistas. Es hacia donde se dirige el mercado.
- La apertura gana al cierre. El instinto de cerrar su plataforma y dificultar el cambio es comprensible. Pero Gartner advirtió explícitamente de que "los proveedores de SaaS heredados que intenten cerrar los sistemas de registro corren el riesgo de ser eludidos por las capas de orquestación en las que confían más las empresas." Ouch.
La versión honesta
Seré franco sobre dónde aterrizo en esto. Construir frente a comprar nunca fue realmente una cuestión de tecnología. Siempre se trató de la confianza. ¿Confío en que este proveedor entienda mi problema con la suficiente profundidad como para que su solución sea mejor que la que yo pueda improvisar?
En 2026, "improvisar" recibió una actualización masiva. Así que el listón de la confianza también subió.
Para nosotros en Rasepi, eso significa que no podemos ser simplemente una herramienta de documentación que casualmente soporta traducciones. Tenemos que ser tan buenos en los problemas difíciles, el seguimiento de la traducción a nivel de bloque, la aplicación de la frescura del contenido, la complejidad multi-inquilino, que construir un sustituto sería realmente doloroso incluso con las mejores herramientas de IA del mundo.
Ese es el nuevo "construir vs comprar". No "¿puede construirlo?", sino "¿debería gastar su energía en construirlo cuando otro ya ha resuelto las partes difíciles?".
La cuestión nunca fue realmente el coste. Se trataba de dónde quiere gastar su atención. Y en un mundo en el que construir es barato, la atención es el único recurso escaso que queda.