Comprar un SaaS se siente seguro: precio predecible, soporte incluido, alguien más resuelve los bugs. Construir software propio se siente como control: exactamente lo que necesitas, sin funciones que no usas. Ambas intuiciones son parcialmente correctas, y la decisión equivocada en cualquier dirección sale cara.
Este artículo no es una defensa del desarrollo a la medida —es un criterio para saber cuándo tiene sentido y cuándo no.
El error más común: confundir preferencia con necesidad
La mayoría de las empresas que llegan pidiendo software propio en realidad tienen un problema de configuración. Usan mal el SaaS que ya tienen, o eligieron uno que no corresponde a su industria, y concluyen que “el software no sirve para nosotros”.
Antes de cotizar desarrollo, vale la pena responder una pregunta directa: ¿el proceso que quieres digitalizar existe en algún SaaS del mercado, aunque sea imperfecto? Si la respuesta es sí, el camino más barato casi siempre es adaptar el proceso al SaaS —no al revés.
Lo vemos seguido en Eurema con clientes de manufactura: llegan convencidos de que necesitan un sistema de producción completamente nuevo, y al mapear sus flujos reales, resulta que el 70% de lo que necesitan ya lo cubre un MES o un ERP mid-market con algo de configuración. El 30% restante es lo que hay que evaluar con cuidado.
Las tres señales de que el SaaS no va a funcionar
Hay escenarios donde la personalización de un SaaS llega a su límite estructural. Estas son las señales concretas:
1. Tu proceso central es tu diferenciador. Una empresa de logística en Monterrey que ha desarrollado durante 10 años un algoritmo propio de ruteo y pricing no puede meter esa lógica en un SaaS genérico sin perder lo que la hace competitiva. Si el proceso es commodity, el SaaS funciona. Si el proceso es la razón por la que tus clientes te eligen, probablemente no.
2. El costo de licencias a escala supera el de desarrollo. Muchos SaaS cobran por usuario o por transacción. Una empresa con 150 usuarios activos en una plataforma de MXN 400/usuario/mes está pagando MXN 60,000 mensuales —MXN 720,000 al año. Si el software propio equivalente cuesta MXN 800,000 de desarrollo y MXN 150,000 de mantenimiento anual, el breakeven está en menos de 18 meses.
3. Las integraciones necesarias no existen o son frágiles. Si para conectar tu SaaS con tu ERP necesitas un middleware custom que un proveedor externo mantiene y que falla cada vez que alguno de los dos sistemas actualiza su API, ya estás pagando por desarrollo sin tener el control.
Las tres señales de que SÍ debes comprar el SaaS
Para ser simétrico: hay casos donde construir es claramente el error.
1. El proceso todavía no está maduro. Si no puedes describir con precisión cómo funciona hoy el proceso que quieres automatizar —quién hace qué, bajo qué condiciones, con qué excepciones— construir software propio es construir sobre arena. El SaaS te obliga a operar dentro de una estructura que ya fue pensada. Eso a veces es exactamente lo que necesitas para ordenar el caos.
2. No tienes equipo para mantenerlo. Software a la medida sin mantenimiento es deuda técnica acumulando intereses. Si tu empresa no tiene un desarrollador interno o un proveedor de confianza para evolucionar el sistema, en 18 meses tienes un sistema que “funciona pero nadie quiere tocar”. El costo de ese escenario es mayor que el del SaaS más caro del mercado.
3. El tiempo de implementación importa más que la precisión. Un SaaS bien elegido puede estar operando en semanas. Un desarrollo a la medida de alcance medio toma entre 3 y 6 meses en condiciones normales. Si necesitas resolver el problema ahora, el SaaS gana por default.
Cómo hacer el análisis sin sesgarte
El criterio que usamos en Eurema para evaluar si un proyecto vale la pena construirlo es un cálculo de tres variables:
| Variable | Pregunta clave |
|---|---|
| Costo total de propiedad a 3 años | ¿Cuánto cuesta el SaaS vs. desarrollo + mantenimiento en 36 meses? |
| Costo de no encajar | ¿Cuántas horas/mes se pierden en workarounds por limitaciones del SaaS? |
| Riesgo de ejecución | ¿Tienes proveedor y equipo para construir y mantener el sistema? |
Si el SaaS sale más barato a 3 años y el costo de no encajar es bajo, la decisión es clara. Si el desarrollo sale más barato o el costo de no encajar es alto (más de 40 horas/mes en workarounds, por ejemplo), empieza a tener sentido construir.
Lo que no recomendamos es tomar la decisión sin hacer este cálculo. “Se siente que necesitamos algo propio” no es un criterio financiero.
El modelo híbrido que más funciona en B2B LatAm
En la práctica, la mayoría de las empresas medianas en LatAm terminan en un modelo mixto: SaaS para funciones horizontales (CRM, facturación, RRHH) y software a la medida para los procesos verticales que son específicos de su negocio.
Una empresa de servicios profesionales puede usar HubSpot para su pipeline comercial y tener un sistema propio para gestionar expedientes de clientes con lógica regulatoria específica de México. Eso no es contradicción —es eficiencia. No tiene sentido construir un CRM desde cero cuando HubSpot resuelve el problema, y no tiene sentido meter la gestión de expedientes en un SaaS genérico que no conoce las particularidades del proceso.
En proyectos de Software a la medida con clientes de servicios profesionales y salud, la arquitectura que más veces hemos visto funcionar es exactamente esa: comprar lo horizontal, construir lo diferenciador.
Qué hacer antes de tomar la decisión
Si estás en este punto de análisis, el siguiente paso práctico no es pedir cotizaciones —es mapear el proceso. Documenta cómo funciona hoy, quién participa, qué excepciones existen y cuánto tiempo consume. Con eso sobre la mesa, cualquier evaluación de SaaS o desarrollo va a ser más honesta.
Si después del mapeo sigues sin claridad sobre qué ruta tomar, eso ya es información útil: significa que el proceso no está lo suficientemente maduro para sistematizarlo bien, sea con SaaS o con código propio.