Internalicé mi stack SaaS con IA: los números reales (y cuándo NO hacerlo)

Tiempo de lectura: 8 minutos

Hace seis meses ITNOVE pagaba cuatro SaaS distintos para CRM, LMS, e-commerce y automatizaciones. Hoy paga uno — más la API de Anthropic. Y lo que más cambió no fue el coste.

Empezó casi por accidente. Rediseñé la web de ITNOVE con ayuda de IA y, cuando vi que lo había hecho en dos semanas, pensé: ¿y por qué no el resto? Seis meses después había sustituido buena parte de mi stack SaaS por una plataforma propia. No es magia, y los números son reales. Te los cuento sin maquillar — incluyendo lo que no ganarás y los casos en los que no deberías intentarlo.

01 · El detonante: por qué me planteé dejar de pagar SaaS.

ITNOVE es una operación de una sola persona con el stack típico de cualquier pyme digital de servicios: un SaaS para email y automatizaciones, otro para los cursos, otro para el e-commerce, otro para conectar todo lo anterior. Cada uno funcionaba. El problema no era ninguno por separado — era el conjunto.

• Datos en silos: las compras en un sitio, los contactos en otro, las inscripciones en un tercero. Cruzarlos exigía exportar CSVs y montar conectores.
• Personalización limitada: cada SaaS imponía su modelo de datos. Algo tan simple como "este alumno terminó el curso gratuito, mándale el upsell del premium del mismo tema" requería reescribir la lógica a mano porque ninguna plataforma exponía el evento útil.
• Sin capa de IA nativa: pegar Claude o GPT a cualquier flujo era prácticamente imposible sin código a medida. Y código a medida sobre SaaS = más conectores, más scripts, más dolor.

El coste mensual era manejable. El coste oculto — el tiempo de pegamento manual entre sistemas — no tanto.

02 · Los números reales (sin maquillar).

Esta es la comparativa de gasto anual: lo que pagaba antes en plataformas, frente a lo que pago ahora con infraestructura propia + IA.

Antes · stack SaaS

Ahora · plataforma propia con IA

El ahorro bruto es 3.356 €/año — un 73%. Pero ese número merece una nota honesta.

El 73% es mi caso real, donde el mantenimiento es prácticamente cero porque lo hago yo (más sobre esto en un momento). Si eres más conservador y presupuestas, pongamos, 1.440 €/año de mantenimiento, el ahorro baja al 42%. Sigue siendo mucho — pero prefiero darte el rango entero a venderte el número grande.

Dos matices más que no salen en las tablas:

• Lo que no se sustituye: unos 788 €/año en Zoom, Miro, Google Workspace y similares. Hay herramientas que internalizar no tiene sentido.
• El coste de migrar: unas 60 horas, repartidas en seis meses y hechas a ratos (a 60 €/h, 3.600 € de esfuerzo único). El ahorro recurrente lo compensa en ~13 meses; a partir de ahí, todo es margen.

03 · Qué internalicé y qué mantuve.

No internalicé todo. Internalizar tiene sentido cuando ganas integración, datos o capacidad nueva. No lo tiene cuando solo reinventas un commodity.

Sustituí lo que era core de mi operación y vivía en silos: el CRM, el email marketing, la plataforma de cursos, el e-commerce, los conectores, los diagnósticos y hasta el gestor de publicaciones de LinkedIn. Todo lo que generaba pegamento manual o me impedía aplicar IA a mis propios datos.

Mantuve lo que es infraestructura genérica y bien resuelta por terceros: videollamadas, pizarras colaborativas, ofimática, almacenamiento. Reescribir eso no me daría ninguna ventaja — solo trabajo y riesgo.

04 · Cómo lo hice (y qué construí por el camino).

No fue un big bang, fue un goteo de seis meses, capa por capa. La red de seguridad fue empezar con shadow write: cada captación se escribía en paralelo en el SaaS antiguo y en mi base de datos nueva. Solo apagué cada sistema cuando el propio ya llevaba semanas funcionando.

Algunos hitos para que veas que esto es operación real, no un experimento:

• 991 pedidos históricos importados en una sola noche, con creación automática de contactos, etiquetas e inscripciones.
• 5 cursos migrados desde el LMS anterior y 71 vídeos recableados a un nuevo proveedor de streaming.
• 7 simuladores de examen premium con más de 2.000 preguntas curadas.
• Kill-switch en junio: cero llamadas a SaaS externos en producción.

Y aquí viene lo interesante: algunas piezas no son migraciones, son cosas nuevas que antes no eran viables. Un sistema de productividad personal con Kanban, OKRs y CRM propio. Un programa de referidos con atribución de dos niveles. Un trivial gamificado de certificaciones que funciona como lead magnet. Nada de esto existía antes — no porque no quisiera, sino porque montarlo sobre SaaS habría sido inviable.

05 · La capa de IA: lo que de verdad cambia.

Esta es la parte menos obvia y la más importante. Cuando todo es código propio, añadir IA a cualquier flujo deja de ser un proyecto y pasa a ser un .

Algunos ejemplos que ya están en producción:

• Corrección de respuestas abiertas en los cursos. El alumno escribe 100-300 palabras; Claude devuelve nota, feedback al alumno y — esto es lo bueno — feedback estructurado al profesor: qué se entendió, qué no, qué lagunas tiene el propio curso.
• Clasificación automática de newsletters que leo, sintetizadas y archivadas en mi vault de notas sin tocar nada.
• Pregunta a tus datos: consulto mi propio backlog y mi tiempo en lenguaje natural.
• Pulido de contenido de LinkedIn dentro del mismo gestor donde lo escribo.

En el stack anterior, cada uno de estos casos habría exigido un conector, un script y un SaaS que diera webhooks útiles. Era infranqueable. Ahora es una línea de código.

Y para ser justo, también lo honesto sobre la IA: no uso RAG ni embeddings — para mi dominio, meter la rúbrica y el texto en el prompt da mejores resultados con menos complejidad. Y la IA no es gratis: una corrección con el modelo grande cuesta unos 0,10 € por ejecución. A volumen alto compensa; conviene tenerlo presente.

06 · Lo que no sale en la hoja de cálculo.

Si esto fuera solo una nota de prensa te contaría únicamente el 73%. Pero hay una columna de "en contra" que es de justicia poner:

• Más mantenimiento: lo que se rompe ya no lo arregla el soporte de un SaaS. Lo arreglo yo.
• Curva de aprendizaje alta: durante el goteo hubo regresiones puntuales (un enlace roto en la home, una URL mal escrita en base de datos) que un SaaS habría evitado por imposición.
• Coste de oportunidad: son horas que no dediqué a otras cosas.

Y una columna de "a favor" que el Excel tampoco recoge:

• Aprendizaje: volver a tocar todos los roles de desarrollo y trabajar con agentes ha sido, para mí, una pequeña revolución.
• Integración real: menos funciones sueltas, más funcionalidad por tener todo conectado.
• Dueño de mis datos: ahora puedo sacarles partido — para mi análisis y para los usuarios — en vez de tenerlos repartidos en cuatro plataformas.

La objeción que más vas a oír es esta: «te estás saltando el coste real — mantener y asegurar tu propio software cuesta más de lo que ahorras, y por eso compensa pagar el SaaS». Es una crítica legítima, y en muchos casos es cierta. En el mío, menos, por un matiz que lo cambia todo: no administro servidores.

La seguridad, los backups, el parcheado, la disponibilidad y el cumplimiento a nivel de infraestructura los gestionan las plataformas sobre las que construyo — Vercel, Supabase, Stripe, Cloudflare — igual que los gestionaba el SaaS. No he cambiado seguridad gestionada por seguridad casera: he cambiado el proveedor que la gestiona. Lo que queda de mi lado es la capa de aplicación (cómo manejo datos, permisos y flujos de pago), y para alguien técnico ese coste marginal es bajo — vigilancia ocasional sobre código que ya entiendo, no un trabajo nuevo a tiempo completo.

Por eso, en mi caso, el mantenimiento tiende a cero y el ahorro real se acerca al 73%. Pero la otra cara es igual de importante: si no puedes delegar la seguridad de infraestructura en plataformas gestionadas, o no tienes el perfil para llevar la capa de aplicación, la objeción te aplica de lleno — y entonces pagar el SaaS es la decisión correcta.

07 · ¿Deberías hacerlo tú?

El cálculo de build vs. buy se ha movido con la IA. Lo que antes requería un equipo de desarrollo hoy lo puede abordar una persona con criterio y las herramientas adecuadas. Pero "se ha movido" no es lo mismo que "ha desaparecido". Antes de lanzarte, hazte cuatro preguntas:

• ¿Tienes (o tienes acceso a) capacidad técnica real? Si la respuesta es no, párate aquí.
• ¿Qué es core y qué es commodity? Internaliza solo lo que te dé ventaja de integración o de datos.
• ¿Quién asume el mantenimiento y la seguridad? Si nadie, vuelve al SaaS.
• ¿Tienes volumen para amortizar la IA? A poco uso, el ahorro tarda; a volumen, compensa rápido.

Esto no es un análisis de costes que valga para cualquier organización. Es mi caso. Pero el patrón es transferible: cuando controlas tu propia plataforma, la IA deja de ser una capa que pegas por fuera y pasa a ser parte del producto. Y ahí es donde está el valor que no cabe en la tabla.

¿Tú qué SaaS internalizarías primero — y cuál no tocarías ni con un palo? Si quieres seguir estas reflexiones sobre IA aplicada al negocio, las publico cada semana en la newsletter de ITNOVE: itnove.com/newsletter.

Etiquetas: IA · Automatización · SaaS · Build vs Buy · Productividad · Estrategia