Conviene abrir con la declaración de interés: INGEN desarrolla software a la medida. Es lo que vendemos. Y aun así, la respuesta correcta para la mayoría de las empresas que nos escriben es comprar un SaaS y seguir con su día. Un marco de decisión que solo apunta hacia el desarrollo propio no es un marco, es un folleto.
Lo que sigue son los criterios que usamos internamente para decidir si un proyecto debe existir, con los datos que pudimos verificar en fuente primaria y una nota explícita sobre los que no.
Primero, la advertencia sobre las cifras
En cualquier búsqueda sobre este tema aparece el CHAOS Report del Standish Group, con su famoso porcentaje de proyectos de software fracasados. No lo vamos a citar. El informe no publica su metodología ni sus datos, y ha sido cuestionado en literatura arbitrada: Eveleens y Verhoef, en The Rise and Fall of the Chaos Report Figures (IEEE Software, vol. 27, núm. 1, 2010, pp. 30-36), aplicaron las definiciones de Standish a su propio conjunto de 5,457 pronósticos sobre 1,211 proyectos reales y concluyeron que las cifras no reflejaban la realidad de los casos. Su crítica de fondo: las definiciones miden exactitud de la estimación, no valor entregado, y premian a quien infla el presupuesto inicial.
Lo mismo aplica a las cifras de "costo total de propiedad" que circulan en este tema. Números como "el mantenimiento es 15 a 20% anual del presupuesto de desarrollo" o "78% del costo de vida del software ocurre después del lanzamiento" aparecen repetidos en blogs de proveedores, atribuidos a reportes que no son de acceso público. Son plausibles y coinciden con nuestra experiencia, pero no son evidencia y no los presentamos como tal.
Lo que sí resiste verificación: el estudio de McKinsey con el BT Centre for Major Programme Management de Oxford sobre más de 5,400 proyectos de TI, que reporta que los proyectos grandes (arriba de 15 millones de dólares) exceden en promedio 45% el presupuesto y entregan 56% menos valor del previsto. Y el trabajo de Flyvbjerg y Budzier sobre 1,471 proyectos de TI, publicado en Harvard Business Review en 2011: sobrecosto promedio de 27%, pero uno de cada seis proyectos resultó ser un "cisne negro" con sobrecosto promedio de 200% y retraso cercano a 70%.
La lectura útil para un director de PyME no es "los proyectos de software fracasan". Es esta: el riesgo del desarrollo propio no está en el promedio, está en la cola. El proyecto típico se pasa un poco. El proyecto que te tumba el año se pasa tres veces. Comprar un SaaS es, entre otras cosas, comprar la eliminación de esa cola.
El contexto mexicano
El Censo Económico 2024 del INEGI midió, con datos de 2023, qué tecnología digital usan las unidades económicas del país. Los resultados están en Tecnologías digitales de información y comunicación, resultados oportunos:
| Tecnología digital | Unidades económicas que la usan |
|---|---|
| Buscadores en línea | 83.8% |
| Repositorios digitales | 57.7% |
| Tiendas en línea | 42.6% |
| Dispositivos controlados a distancia | 40.3% |
| Servicios informáticos en la nube | 28.6% |
| Software para analizar datos masivos | 23.3% |
| Otras (3D, inteligencia artificial, robótica avanzada) | 5.5% |
Y el tamaño del universo, según los resultados definitivos del Censo Económico 2024: 5,468,180 unidades económicas en el sector privado, de las cuales 95.4% son microempresas de diez personas o menos.
Ese 28.6% de adopción de nube es el dato que más pesa en esta decisión. Significa que siete de cada diez empresas mexicanas todavía tienen disponible la ganancia barata: la que se obtiene contratando una herramienta que ya existe. Si su empresa lleva el inventario en Excel y la cobranza en WhatsApp, el retorno de suscribirse a un SaaS decente supera por amplio margen al de mandar construir algo. Esa etapa no se salta.
Los cinco criterios
Un SaaS es la respuesta correcta salvo que se cumplan varias de estas condiciones. No una: varias.
1. El proceso es la ventaja competitiva, no el soporte. Si su forma particular de cotizar, rutear o programar producción es por lo que los clientes lo prefieren, meterla a la fuerza en un producto genérico la erosiona. Si el proceso es nómina, facturación o contabilidad, cómprelo. Nadie gana un mercado teniendo una nómina distinta.
2. Ya probó el SaaS y tocó un muro concreto. No un muro imaginado. Un muro con nombre: el sistema no maneja unidades de medida dobles, o no permite el flujo de aprobación que exige el cliente, o cobra por usuario cuando usted necesita cien lectores ocasionales. Construir antes de haber usado la alternativa es construir a ciegas.
3. El costo de la suscripción se volvió absurdo respecto al uso. El modelo por asiento castiga a las empresas con mucha gente que consulta poco. Cuando la renta anual de tres herramientas empieza a acercarse al costo de construir una que haga lo específico que usted necesita, la aritmética cambia. Antes de eso, no.
4. La integración entre sistemas ya es el problema principal. Este es el criterio que más subestiman los directores. Cada suscripción nueva resuelve un problema y crea uno: un lugar más donde vive un dato que no coincide con los demás. Sobre la magnitud del fenómeno existen cifras de proveedores (MuleSoft, propiedad de Salesforce, que vende justamente integración) hablando de miles de aplicaciones por organización y decenas de por ciento sin integrar. Las mencionamos con su sesgo declarado: son datos de quien vende la solución al problema que describen. Zylo, que vende gestión de suscripciones, reporta en su índice 2026 un 36% de licencias sin uso y que 61% de los líderes de TI encuestados tuvieron que recortar proyectos por alzas no previstas en costos de SaaS. Mismo sesgo, misma advertencia. La versión sin fuente que sí puede verificar usted mismo: sume cuántas herramientas paga hoy y cuántas veces al mes alguien de su equipo copia datos de una a otra a mano. Ese número es su costo de integración y no aparece en ninguna factura.
5. La operación depende de que el software siga existiendo dentro de diez años. Un proveedor puede subir precios, ser adquirido, cambiar de rumbo o cerrar. Si su empresa puede migrar en tres meses sin dolor, el riesgo es tolerable. Si el sistema es el centro nervioso de la operación, la propiedad del código y de los datos deja de ser un detalle técnico y se vuelve una decisión de continuidad del negocio.
Cuándo comprar, sin dudarlo
| Situación | Decisión |
|---|---|
| Contabilidad, nómina, CFDI, correo, firma electrónica | SaaS. Siempre. Es terreno regulado y comoditizado. |
| Necesita algo funcionando este trimestre | SaaS. El desarrollo no compite en velocidad de arranque. |
| No hay quien pueda dedicar horas a definir el proceso | SaaS. El software a la medida exige un dueño interno del proyecto. |
| Presupuesto único, sin capacidad de sostener mantenimiento | SaaS. Construir y abandonar es la peor de las tres opciones. |
| El proceso todavía está cambiando cada mes | SaaS. Congelar en código un proceso inestable sale caro. |
La opción intermedia que casi nadie considera
Entre "pagar una suscripción" y "mandar construir un sistema completo" hay un espacio que resuelve la mayoría de los casos difíciles: conservar el SaaS y construir solo la pieza que falta. Un tablero que consolide lo que hoy vive en tres herramientas. Un conector que evite la captura doble. Una capa de operación específica de su industria montada sobre el sistema comercial que ya usa.
Es más barato, se entrega en semanas y no obliga a apostar la operación completa a un proyecto nuevo. En desarrollo de software a la medida la mayor parte de lo que entregamos tiene esa forma: piezas acotadas con un dueño claro, no reemplazos totales. Y cuando el problema sí exige un sistema propio, suele ser porque el proceso central de la empresa no cabe en ninguna caja comercial, como pasa con frecuencia en sistemas de inventario donde las unidades, mermas y flujos de una industria específica no coinciden con lo que asume el producto genérico.
Cómo se ve la decisión el lunes
No es una decisión filosófica, es un inventario. Haga tres columnas antes de pedir cotizaciones a nadie.
Primero, liste todas las suscripciones de software que paga hoy, con su costo anual. Segundo, marque en qué puntos alguien captura a mano un dato que ya existe en otro sistema, y estime cuántas horas al mes son. Tercero, señale qué procesos son los que sus clientes le compran, y cuáles son puro soporte administrativo.
Si el gasto está disperso pero cada herramienta hace bien su trabajo y la captura doble es marginal, no tiene un problema de software: tiene un problema de consolidación de proveedores, y se resuelve renegociando o cancelando. Si la captura manual consume días-persona al mes y ocurre justamente en el proceso que le da ventaja competitiva, ahí sí hay un caso para construir, y el alcance ya está definido por el ejercicio, no por una junta de intenciones.
La pregunta correcta nunca fue "comprar o construir". Fue: qué parte de su operación es genérica, y qué parte es suya. La primera se renta. La segunda, cuando ya duele y no antes, se construye.
¿Prefieres que lo hagamos nosotros?
Las pruebas de arriba las puedes correr tú, y vale la pena hacerlo. Si prefieres el diagnóstico completo, lo hacemos por ti y te entregamos los hallazgos priorizados por lo que más cuesta dejarlos así.