Construir o comprar IA: guía para pymes

Casi todo proyecto de IA arranca con la misma bifurcación: ¿pagamos una suscripción a una herramienta que ya existe, o construimos algo a la medida? La respuesta por defecto de la industria es "compra, siempre". La respuesta honesta es "depende, y hay reglas para decidir".

Este post es el framework que usamos para resolver esa decisión en la auditoría. No es una defensa de construir — construimos software, sí, pero vender un build cuando un SaaS de 30 dólares al mes resuelve tu problema sería pésimo negocio para ti y para la confianza. Es un método para que la decisión la tomes con números, no con moda.

Los cuatro factores que deciden

Toda decisión de construir o comprar se reduce a cuatro variables. Pásalas por tu caso antes de cotizar nada — la mayoría brinca directo al precio, y el precio es lo que más te engaña cuando lo ves solo.

1. Ajuste al proceso. ¿Qué tan bien encaja la herramienta lista con cómo trabajas de verdad? Un SaaS te da el 80% que resolvió para el promedio de sus clientes. La pregunta es si tu 20% restante es un lujo o es justo donde vives.
2. Integración. ¿Se conecta con tus sistemas actuales o te obliga a recapturar datos a mano? Una herramienta que no se integra crea trabajo nuevo mientras promete quitarlo.
3. Costo total. No la mensualidad. El costo a tres años, incluyendo lo que cuesta por usuario, por volumen, y el tiempo de tu equipo peleándose con lo que no encaja.
4. Lock-in. Si mañana quieres salirte, ¿te llevas tus datos y tu lógica, o quedas atrapado? El costo de salida es parte del precio de entrada, aunque no aparezca en la cotización.

Cuándo comprar (SaaS gana)

Comprar es la decisión correcta más seguido de lo que a un desarrollador le gusta admitir. Compra cuando:

• El problema es genérico y ya está resuelto. Facturación, contabilidad, correo, videollamadas. No construyas lo que un producto maduro hace mejor por 30 dólares al mes.
• Tu proceso encaja con el flujo estándar de la herramienta. Si el 80% que te da el SaaS cubre lo que necesitas y el 20% restante es tolerable, cómpralo.
• El volumen es bajo o incierto. Si todavía no sabes cuánto vas a usar algo, una suscripción cancelable es más barata que un build que quizá no ocupes.
• Necesitas empezar mañana. El SaaS ya existe. Un build toma semanas. Si el tiempo es el factor crítico, compra ahora y evalúa construir después.

La trampa del SaaS no es la mensualidad. Es cuando la herramienta casi encaja y terminas contratando gente para trabajar alrededor de sus limitaciones. Ahí el "barato" se vuelve caro y ni lo notas en la factura.

Cuándo construir (build gana)

Construir gana cuando tu proceso es tu ventaja o cuando el SaaS te sale caro precisamente por lo que te hace distinto. Construye cuando:

• El proceso es tu diferenciador. Si la forma en que operas es parte de por qué ganas clientes, moldearte a la herramienta genérica de un tercero es apagar tu ventaja.
• La integración con tus sistemas es el punto. Un build se conecta a lo que ya tienes; un SaaS te pide vivir dentro de su jardín.
• El volumen hace que el SaaS escale contra ti. Muchas herramientas cobran por usuario o por acción. A cierto volumen, un build a la medida corriendo en tu propia infraestructura sale más barato mes con mes.
• Necesitas lógica que las plantillas no resuelven. Texto en español coloquial, decisiones sobre varias tablas, reglas que cambian por cliente. Ahí un sistema que razona sobre tus datos le gana a encadenar plantillas frágiles.

Cuándo un build de 5,000 dólares le gana a una suscripción

El número donde la balanza se voltea es más bajo de lo que la gente cree. Un ejemplo hipotético con matemáticas simples.

Supón una herramienta que a tu escala cuesta 400 dólares al mes: son 4,800 al año, 14,400 a tres años. Y supón que, por no encajar del todo con tu proceso, tu equipo pierde algunas horas cada semana peleándose con ella. Un build de alcance cerrado que empieza en 5,000 dólares, corre en tu infraestructura y no cobra mensualidad, se paga en poco más de un año solo contra la suscripción — y antes si cuentas las horas recuperadas.

La cuenta se voltea a favor de construir cuando se cumplen tres cosas a la vez: el SaaS te cobra por volumen o por usuario y ese número crece, la herramienta no encaja del todo con tu proceso, y el problema es estable, no un experimento que quizá abandones. Si las tres aplican, construir suele ganar. Si solo aplica una, la suscripción casi siempre es la apuesta más inteligente; saca la cuenta con honestidad y deja que los números decidan. Los rangos completos y qué mueve el precio están en cuánto cuesta de verdad adoptar IA.

Cuándo NO construir

La parte que un vendedor de software no te va a decir. No construyas si:

• No has validado el proceso a mano. Si el flujo todavía cambia cada semana, construir lo congela demasiado pronto. Primero estabiliza el proceso.
• El problema es chico y aislado. Para conectar dos herramientas una vez, una automatización simple o un SaaS es más que suficiente. No necesitas software a la medida para eso.
• Nadie va a ser dueño del sistema. Un build sin responsable interno se muere igual que un piloto abandonado. Por qué pasa eso está en por qué mueren los pilotos de IA.
• Solo quieres experimentar. Si es exploración, prueba un SaaS cancelable. Cuando sepas que el problema es real y estable, construye.

Un checklist de cinco preguntas

Antes de decidir, respóndete esto. Tres o más "sí" inclina la balanza hacia construir; menos, hacia comprar.

1. ¿El proceso es parte de cómo te diferencias de tu competencia?
2. ¿El SaaS te cobra por usuario o por volumen, y ese número va a crecer?
3. ¿La herramienta lista deja fuera algo que de verdad necesitas?
4. ¿La integración con tus sistemas actuales es crítica?
5. ¿El problema es estable, no un experimento que podrías abandonar?

Ninguna de las cinco es decisiva por sí sola. Un solo "sí" fuerte, como que el proceso sea tu diferenciador central, puede pesar más que tres "sí" tibios. El checklist ordena la conversación, no la reemplaza: el número final importa menos que entender cuál de las cinco pesa más en tu negocio.

Si no estás seguro de tus respuestas, esa duda es normal y es exactamente lo que resolvemos en la auditoría: metemos tu caso al framework y sale la recomendación con números, aunque la recomendación sea comprar.

Preguntas frecuentes

¿No es obvio que construir siempre da más control?

Más control, sí, pero también más responsabilidad. Un build a la medida es tuyo de mantener y evolucionar. Si el problema es genérico y un SaaS lo resuelve bien, ese control extra es peso que no necesitas cargar. Control por control no vale la pena; control sobre lo que te diferencia, sí.

¿Puedo combinar las dos estrategias?

Casi siempre es la respuesta correcta. Compras SaaS para lo genérico — correo, facturación, contabilidad — y construyes solo donde tu proceso es tu ventaja. El error es construir todo o comprar todo por dogma en lugar de decidir pieza por pieza.

¿Un build a la medida no es más riesgoso que un SaaS establecido?

El riesgo real no es que el build falle técnicamente, es que nadie lo adopte. Un build bien acotado, desplegado en tu infraestructura y con un responsable interno capacitado es tan confiable como cualquier SaaS, y sin el riesgo de que el proveedor suba precios o cierre.