Build vs Buy IA: Migré mi app IA custom a SaaS y esto aprendí

TL;DR

Construir tu propia app IA parece más barato hasta que calculas el costo real de mantenerla viva. Después de 6 meses y unos $1.400 mensuales en costos ocultos, volví a SaaS. Te explico cuándo tiene sentido cada camino y cómo tomar la decisión build vs buy IA sin que la hoja de cálculo te engañe.

El error que cometen los equipos técnicos al evaluar build vs buy IA

La hoja de cálculo siempre miente igual. Calculas el costo de las licencias SaaS, lo comparas con el costo estimado de desarrollo y llegas a una conclusión que parece obvia: en 8 meses el custom se paga solo.

Lo que no calculas es lo que pasa después del lanzamiento.

Nosotros lanzamos una app interna de procesamiento de contratos con un LLM propio en octubre de 2025. El caso parecía sólido: 2.500 contratos mensuales, lógica de extracción muy específica para regulación local, y un SaaS competidor que cobraba $890/mes sin cubrir ni el 60% de nuestros casos de uso.

Seis meses después, migramos. Aquí está lo que no vimos venir.

Este artículo detalla los costos reales que descubrimos, la matriz de decisión que usamos para evaluar si quedarnos o salir, y las lecciones prácticas para cualquier equipo en LatAm que esté enfrentando la misma decisión hoy.

Por qué la hoja de cálculo inicial siempre falla

El problema no es la intención del análisis sino su estructura. La mayoría de los equipos arman una tabla con dos columnas: costo de desarrollo (custom) versus costo de licencia (SaaS). Esa comparación es correcta pero incompleta porque solo captura el momento del lanzamiento, no el ciclo de vida completo del sistema.

Un modelo en producción no es un activo estático. Es un sistema vivo que interactúa con APIs externas que cambian, con datos que evolucionan, y con un equipo operativo que necesita interpretarlo y corregirlo de forma continua. Ninguno de esos costos aparece en la columna de “costo de desarrollo” porque técnicamente ocurren después del desarrollo. Pero ocurren igual.

El sesgo del equipo técnico en la decisión

Existe un segundo factor que pocas empresas reconocen abiertamente: el equipo técnico tiene incentivos para elegir custom. No por malicia, sino porque construir es intrínsecamente más estimulante que configurar. Un proyecto de ingeniería nuevo representa aprendizaje, visibilidad interna y un problema interesante para resolver. Un SaaS bien configurado representa horas de documentación y ajuste de prompts.

Ese sesgo no invalida la decisión de construir, pero sí significa que el análisis debe hacerlo alguien que no tenga un interés directo en el resultado, o al menos que se audite con criterios externos. Si la única voz que evalúa build vs buy IA es el equipo que va a construirlo, las señales de SaaS van a tener un peso menor del que merecen.

Los costos que no aparecen en el pitch interno

El modelo en producción no se queda quieto. Los proveedores actualizan APIs, deprecan versiones, cambian comportamientos de output sin previo aviso. Cada cambio de OpenAI o Anthropic que afecta tu pipeline requiere alguien que lo detecte, lo diagnostique y lo parchee.

En nuestro caso, entre noviembre de 2025 y marzo de 2026 tuvimos 4 incidencias de producción que tardaron entre 3 y 11 horas en resolverse. A un costo real de $65/hora de ingeniería, eso suma $2.145 solo en tiempo de resolución, sin contar el costo de oportunidad.

El monitoreo tampoco es gratis. Detectar alucinaciones requiere evaluación humana periódica o un segundo sistema de validación. El nuestro corría en una función Lambda que evaluaba muestras aleatorias, pero alguien tenía que revisar los resultados y actuar cuando la tasa de error subía del 3%.

Más allá del monitoreo puntual, existe un costo de fondo que rara vez aparece en las proyecciones: el tiempo que un ingeniero senior dedica cada semana simplemente a mantener el sistema estable. No a mejorarlo, no a agregar features, sino a asegurarse de que no se rompa. En nuestro equipo eso representaba entre 4 y 6 horas semanales de atención sostenida, lo que equivale a casi 0.15 FTE de ingeniería consumido solo por estabilidad operativa.

El costo real mensual de mantener viva la app llegó a $1.420, distribuido así:

Rubro	Costo mensual estimado
Tiempo de ingeniería (mantenimiento)	$620
On-call e incidencias (promedio)	$380
Infraestructura y APIs	$290
Monitoreo y revisión humana	$130

Contra los $890 del SaaS que habíamos descartado, la ecuación ya no era tan clara.

Desglose por tipo de costo: directo vs. indirecto

Vale la pena separar los costos en dos categorías para entender dónde duele más.

Los costos directos son los que aparecen en facturas: infraestructura cloud, llamadas a APIs de modelos, herramientas de monitoreo con licencia propia. En nuestro caso sumaban $420 mensuales, una cifra que todavía parecía competitiva frente al SaaS de $890.

Los costos indirectos son los que se esconden en el calendario del equipo: horas de on-call, revisiones de calidad de outputs, comunicaciones internas cuando algo falla, y el costo de oportunidad de no haber usado ese tiempo en el producto principal. Estos sumaban $1.000 adicionales al mes, y ninguno aparecía en la proyección original. Es exactamente esta brecha entre costos directos e indirectos la que hace que la decisión build vs buy IA sea tan difícil de evaluar con honestidad.

Cuando sumas ambas categorías, el número real supera en un 60% la estimación inicial. Si tu equipo solo calculó los directos, es probable que esté en la misma trampa en la que caímos nosotros.

Cómo estimar los costos ocultos antes de lanzar

Si todavía estás en la fase de evaluación, hay tres preguntas que puedes responder ahora mismo para proyectar los costos indirectos con mayor precisión.

Primero: ¿cuántas veces en el último año una herramienta técnica crítica de tu empresa generó una incidencia que requirió intervención fuera del horario normal? Ese número, multiplicado por el costo promedio de una hora de tu ingeniero más caro, te da una baseline de on-call realista para cualquier sistema nuevo.

Segundo: ¿quién en tu equipo tiene el conocimiento para mantener este sistema en 12 meses? Si la respuesta es una sola persona, el costo de riesgo por rotación de esa persona es un número que debe entrar en la ecuación.

Tercero: ¿cuántas horas por semana está dispuesto a ceder tu equipo de forma permanente para sostener esta app? No para lanzarla, sino para mantenerla viva indefinidamente. Si esa cifra no cabe en el calendario actual, el custom va a robar tiempo de algo más importante.

Cuándo el custom sí gana: los casos que sobreviven el escrutinio

Dicho esto, hay escenarios donde construir tu propia solución de app IA custom tiene sentido real, no solo en papel.

Caso 1: privacidad de datos sin negociación posible

Si tu industria requiere que los datos nunca salgan de tu infraestructura (salud, legal, defensa), el SaaS simplemente no es opción, sin importar el precio. Aquí el custom no es una elección, es una restricción del entorno. Este escenario es especialmente relevante en LatAm, donde las regulaciones de datos en sectores como salud y finanzas están endureciéndose rápidamente. En varios países de la región, las normativas de protección de datos ya equiparan el procesamiento por terceros con una transferencia de datos que requiere consentimiento explícito del titular, lo que hace que muchos SaaS internacionales no pasen el filtro legal sin cláusulas contractuales adicionales que no siempre están disponibles.

Caso 2: volumen extremo que cambia la economía

Cuando procesas 500.000 llamadas mensuales a un LLM, las licencias SaaS escalan de forma brutal. Una app propia con un modelo fine-tuned puede costar 4 veces menos por llamada en esa escala. El umbral donde esto aplica en LatAm está generalmente por encima de las 200.000 llamadas mensuales para equipos que ya tienen infraestructura existente. Por debajo de ese umbral, el ahorro por llamada casi nunca compensa el costo operativo adicional que implica sostener la app propia.

Caso 3: lógica de negocio genuinamente irreplicable

No la lógica que crees que es única, sino la que genuinamente no puedes aproximar con configuración, prompts o integraciones. Esto es más raro de lo que parece: en el 70% de los casos que hemos visto, un SaaS con buen prompting cubre el caso de uso. La trampa es confundir familiaridad con singularidad; el equipo técnico conoce tan bien el problema que asume que nadie más puede resolverlo, cuando en realidad ya existe una herramienta que lo hace con el 85% de precisión necesaria.

Caso 4: ventaja competitiva basada en datos propietarios

Un escenario emergente, menos documentado pero creciente en la región, es el de las empresas que necesitan combinar datos propietarios con capacidades de IA de una forma que ningún SaaS existente permite. Aquí el custom no compite contra el SaaS en precio sino en posibilidad técnica. Si tu ventaja competitiva depende de una combinación específica de datos internos y razonamiento de IA, construir puede ser la única forma de materializarla. El criterio clave para validar este caso es la pregunta: ¿el valor diferencial que genera esta app desaparece si usamos un SaaS estándar? Si la respuesta es sí, y puedes demostrarlo con datos, el custom tiene una justificación sólida.

La matriz de decisión: cuatro preguntas antes de comprometerte

Antes de construir, responde estas 4 preguntas. Si la mayoría de respuestas apuntan al lado derecho, el custom probablemente no vale la pena ahora.

Pregunta	Señal de custom	Señal de SaaS
¿Tienes un ingeniero dedicado con slack real?	Sí, al menos 0.5 FTE	No, o el equipo ya va saturado
¿El SaaS cubre menos del 50% de tu caso?	Sí, brecha documentada	No, cubre el 70%+ con ajustes
¿Tus datos no pueden salir de tu infra?	Requisito regulatorio claro	No hay restricción explícita
¿El volumen justifica el ahorro por llamada?	Más de 200k llamadas/mes	Menos de 100k llamadas/mes

Nosotros teníamos 2 señales de custom y 2 de SaaS. El error fue ignorar las 2 de SaaS porque el equipo técnico quería el proyecto.

La quinta pregunta que no aparece en los frameworks

Más allá de la tabla, existe una pregunta que no aparece en ningún framework pero que en la práctica determina el resultado: ¿quién va a ser el dueño de esto dentro de 12 meses?

Si no hay una persona con nombre y apellido que asuma la responsabilidad operativa de la app IA a largo plazo, el custom es una deuda técnica esperando materializarse. Hemos visto proyectos técnicamente bien construidos que colapsan operativamente porque el ingeniero que los hizo se fue a otro proyecto y nadie más entendía el sistema con suficiente profundidad para mantenerlo.

Cómo aplicar la matriz en equipos con recursos limitados

En equipos pequeños, la matriz tiene un sesgo natural hacia el SaaS porque la disponibilidad de ingeniería es casi siempre el factor limitante. Una startup con 8 personas no tiene 0.5 FTE de slack de ingeniería por definición; ese tiempo existe sobre papel pero en la práctica siempre compite con prioridades de producto más urgentes.

Para esos equipos, la recomendación es tratar la matriz como un umbral mínimo, no como un marco de puntuación. Si no cumples al menos 3 de las 4 condiciones de custom con evidencia concreta, el SaaS es el camino por defecto hasta que la escala del negocio justifique otro análisis. El momento correcto para replantear la decisión es cuando el volumen de uso supera el umbral de rentabilidad o cuando las limitaciones del SaaS empiezan a bloquear casos de uso que el negocio necesita con urgencia.

Por qué la narrativa del “control total” es una trampa

El argumento que más convence internamente es el del control: si es nuestro, podemos cambiarlo cuando queramos, no dependemos de decisiones de terceros, podemos escalar sin sorpresas de precio.

Es parcialmente cierto y completamente engañoso.

El control real requiere capacidad de ejercerlo. Cuando el equipo técnico está saturado con el producto principal, el “control total” sobre la app IA se convierte en deuda técnica congelada que nadie toca por miedo a romper algo.

El control como fricción ante cambios de modelos

Hay otro ángulo del control que raramente se menciona: la velocidad de adaptación. Cuando OpenAI lanza un modelo nuevo con mejor rendimiento en tu caso de uso, un SaaS maduro lo integra en días o semanas. Con tu app custom, la decisión de migrar a ese modelo implica pruebas de regresión, ajustes de prompts, validación de outputs y un ciclo de deployment que puede tomar meses si el equipo no tiene ancho de banda. El control se convierte en fricción.

Los SaaS maduros de 2026 ofrecen algo que subestimamos: absorben el costo de mantenerse al día con los cambios de modelos, manejan las actualizaciones de infraestructura, y tienen equipos dedicados a la estabilidad que ninguna PyME puede replicar con su stack interno.

Cuándo el control sí es un activo real

Eso no significa que el SaaS siempre gane. Significa que el costo del control hay que calcularlo honestamente, incluyendo el costo de no poder ejercerlo cuando el equipo está ocupado con prioridades más urgentes.

El control es un activo real en dos situaciones concretas. La primera es cuando la empresa tiene un equipo técnico con slack permanente y documentación suficiente para que cualquier ingeniero del equipo pueda operar el sistema sin depender del que lo construyó. La segunda es cuando los cambios que la empresa necesita hacer al sistema son tan frecuentes o tan específicos que el ciclo de feedback de un SaaS (reportar el problema, esperar que el proveedor lo priorice, recibir la actualización) introduce un retraso inaceptable para el negocio. Fuera de esos dos escenarios, el control es más una narrativa tranquilizadora que una ventaja operativa real.

La migración: lo que duele y lo que no

Migrar de custom a SaaS tomó 3 semanas, no 3 días como esperábamos. El cuello de botella no fue técnico sino humano: el equipo de operaciones había construido flujos de trabajo alrededor de los outputs específicos de nuestra app, con su formato particular de JSON y sus campos propios.

El SaaS de destino devolvía datos en un esquema diferente. Adaptar los 6 flujos de n8n que consumían esos datos tomó más tiempo que la migración técnica en sí.

Los datos históricos migraron bien porque habíamos mantenido los contratos originales en S3 con formato estándar. Si hubiéramos guardado solo los outputs procesados, la historia habría sido diferente.

El impacto humano del cambio de herramienta

Otro aspecto que subestimamos fue el impacto en la confianza del equipo de operaciones. Después de 6 meses usando una herramienta propia con comportamientos conocidos y predecibles, la transición a una interfaz nueva con outputs ligeramente distintos generó resistencia legítima. No porque el SaaS fuera peor, sino porque cualquier cambio en herramientas que el equipo usa 40 horas por semana requiere un proceso de adopción real. En nuestro caso, dedicamos una semana completa a sesiones de entrenamiento y acompañamiento que no estaban en el plan original.

Buenas prácticas para facilitar una migración futura

Un consejo práctico: si hoy tienes una app custom y hay posibilidad de que migres en el futuro, mantén los datos fuente siempre en formato estándar y accesible. El costo de hacerlo es casi cero; el costo de no haberlo hecho puede ser semanas de trabajo.

Documenta los flujos de trabajo del equipo operativo desde el primer día, no cuando ya estés en medio de una migración. Ese mapa de flujos es el activo más valioso que puedes tener cuando llega el momento de cambiar de herramienta, porque es lo que permite estimar con precisión cuánto trabajo de adaptación implica el cambio y qué equipo necesita acompañamiento.

Una práctica adicional que hubiera reducido el tiempo de migración a la mitad: definir desde el inicio una capa de abstracción entre los outputs de la app IA y los flujos de trabajo que los consumen. En lugar de que los flujos de n8n llamaran directamente al esquema JSON de nuestra app, podrían haber llamado a un esquema normalizado propio que la app mapeara internamente. Cambiar el origen de los datos entonces hubiera requerido actualizar solo ese mapeo, no los 6 flujos por separado.

Lo que haríamos diferente hoy

Con 6 meses de distancia y el análisis completo disponible, la decisión no fue un error absoluto sino un error de timing. Construir la app custom tenía sentido potencial, pero no con el tamaño de equipo que teníamos ni en el momento del ciclo de producto en que lo hicimos.

Si volviéramos a evaluar la decisión de build vs buy IA desde cero, haríamos tres cosas distintas. Primero, correríamos un piloto de 60 días con el SaaS antes de comprometernos con el custom, documentando específicamente los gaps de cobertura con datos reales en lugar de estimaciones. Segundo, calcularíamos el costo de mantenimiento mensual antes del costo de desarrollo, invirtiendo el orden habitual del análisis. Tercero, pondríamos en la ecuación el costo de oportunidad explícito: cada hora de ingeniería dedicada a mantener la app IA es una hora que no va al producto principal, y ese tradeoff merece un número en la hoja de cálculo.

La decisión correcta no es siempre SaaS ni siempre custom. Es la que surge de un análisis honesto que incluye todos los costos, no solo los que aparecen en las primeras dos filas de la hoja de cálculo.

Conclusión

Construir tu propia app IA no es malo; es caro de una forma específica que pocas hojas de cálculo capturan. La decisión build vs buy IA para app IA custom vs SaaS depende menos de la tecnología y más de la capacidad operativa real de tu equipo para sostener lo que construye. Antes de comprometerte, calcula el costo de mantenimiento mensual con el mismo rigor con que calculas el costo de desarrollo, y ponle precio real al tiempo de on-call. Si después del cálculo honesto el custom todavía gana, construye sin culpa. Si no, el SaaS que descartaste probablemente era la respuesta correcta desde el principio.

¿Necesitas ayuda para construir esto?

Kreante acompaña a PyMEs y founders en LatAm que quieren reemplazar SaaS caro con IA personalizada. Hemos shipped 265+ proyectos (60% LowCode/AI, 70% B2B) en US, Europa y LatAm.

Agenda una llamada de 30 minutos con Kreante