Software a la Medida para Empresas en México: La Guía Completa antes de Firmar con Nadie

Llega el momento en toda empresa que crece: el Excel ya no da, el sistema actual se queda corto y alguien suelta la frase: "necesitamos un sistema". Ahí empieza el camino que a muchas empresas mexicanas les ha costado entre trescientos mil y dos millones de pesos y les ha dejado un sistema que nadie usa. No por mala suerte: por tomar en el orden equivocado unas pocas decisiones que sí se pueden tomar bien.

Esta guía está escrita para quien va a firmar un desarrollo de software y quiere entender qué está comprando. Cubre cuándo conviene construir y cuándo comprar, por qué fracasan los proyectos a la medida, cómo se ve un proceso que sí termina y qué preguntarle a cualquier proveedor, incluidos nosotros, antes de dar el primer anticipo.

Resumen ejecutivo

• Se compra lo estándar (contabilidad, nómina, correo) y se construye lo diferencial: el proceso que te hace ganar clientes y que ningún sistema enlatado cubre sin obligarte a cambiar cómo trabajas.
• La mayoría de las empresas necesita las dos cosas y una integración entre ellas, no un sistema que lo haga todo.
• Los proyectos fracasan por alcance definido por el proveedor y no por el usuario, por entregas a seis meses sin nada funcional en medio y por código que solo entiende quien lo escribió.
• Un proceso sano tiene discovery antes de cotizar, sprints de dos semanas con demo que valida el usuario real y código en un repositorio que es tuyo desde el primer día.
• Antes de un piloto de inteligencia artificial, ordena los datos: la mayoría de los pilotos se queda en demo por eso, no por el modelo.

¿Cuándo conviene software a la medida y cuándo no?

Conviene cuando el proceso que quieres automatizar es el que te diferencia y ningún sistema enlatado lo cubre sin obligarte a cambiar cómo trabajas. No conviene para contabilidad, nómina, correo o facturación: ahí se compra, porque el proceso es estándar y el proveedor lo mantiene por ti. La mayoría de las empresas necesita las dos cosas y una integración entre ellas.

La trampa está en los extremos, y la desarrollamos en "¿Comprar o construir?": el dueño que ama el control quiere construir todo y termina manteniendo su propia contabilidad; el que le teme al gasto compra lo más barato y termina con seis personas copiando datos entre sistemas. Ninguno de los dos está mirando lo que importa: dónde está tu ventaja y cuánto te cuesta cada captura doble.

Proceso	Comprar	Construir
Contabilidad, nómina, facturación electrónica	Siempre	Nunca
Correo, videollamadas, documentos	Siempre	Nunca
CRM genérico, mesa de ayuda	Casi siempre	Solo si el proceso comercial es tu diferencial
Operación propia: rutas, producción, cotización compleja, validación de documentos	Solo si existe algo que calce sin cambiar tu proceso	Cuando ese proceso es el que te hace ganar
Integración entre todo lo anterior	No existe en caja	Sí: es donde más valor hay por peso invertido

Por qué fracasan los proyectos a la medida en México

Pagaste por un sistema "a la medida". Tardó el doble de lo prometido. Cuando lo entregaron no hacía la mitad de lo que pediste, y cuando el desarrollador se fue nadie pudo mantenerlo. No estás solo. Las causas que vemos, en orden de frecuencia:

1. El alcance lo definió el proveedor, no quien va a usar el sistema. Se cotizó a partir de una lista de deseos de dirección y nadie habló con la persona que captura pedidos.
2. Entregas a seis meses. Sin nada funcional en medio, los errores de entendimiento se descubren al final, cuando corregirlos cuesta el proyecto entero.
3. Código que solo entiende quien lo escribió. Sin documentación ni repositorio del cliente, el sistema es una dependencia con fecha de caducidad.
4. Migrar sin mapear. Se compró o construyó un sistema sin documentar cómo fluye hoy la información, y el equipo volvió al Excel porque "no se adapta a cómo trabajamos".

El último punto merece su propio caso. Un distribuidor de materiales eléctricos en León nos contactó en febrero de 2025 con 47 hojas de Excel: inventario, precios, pedidos, cartera, rutas, comisiones. Seis personas pasaban tres horas diarias copiando datos de un archivo a otro. Ya habían intentado migrar: compraron un ERP enlatado en 2023, lo usaron cuatro meses y lo abandonaron. El problema no era el ERP. Era que nadie había mapeado el proceso real antes de comprar.

Cómo se ve un proyecto que sí termina

Mi postura, después de años de entregar sistemas y de heredar los que otros dejaron a medias: el proceso importa más que la tecnología. Estas son las cuatro cosas que separan los proyectos que terminan de los que no.

1. Discovery antes de cotizar

Una o dos sesiones con quien opera el proceso, no solo con quien lo dirige. De ahí sale un documento de alcance con lo que entra, lo que no entra y lo que se decide después. Cotizar sin discovery es cotizar una suposición; por eso no publicamos precios y por eso la primera sesión no cuesta.

2. Sprints de dos semanas con demo

Cada dos semanas hay algo que tu equipo puede tocar. No una presentación: el sistema, con datos reales, operado por la persona que lo va a usar. Si a las cuatro semanas no hay nada que tocar, algo va mal y se corrige ahí, no al final.

3. Migración por módulos, con el Excel en paralelo

Inventario primero, luego pedidos, luego lo demás. El Excel sigue corriendo hasta que el equipo confía en el sistema. En León fue así: el segundo intento se hizo al revés del primero, documentando primero cómo fluía la información y decidiendo qué se compraba y qué se construía.

4. El código es tuyo desde el primer día

Repositorio a nombre de tu empresa, documentación, diagrama de arquitectura, manual de despliegue y credenciales tuyas. Es la pregunta que más deberías hacerle a cualquier proveedor: ¿qué pasa si ustedes se van? Si la respuesta no es "nada, todo es tuyo", no firmes.

De qué depende el costo (y por qué no te vamos a dar un número aquí)

Dos sistemas que suenan igual, "un sistema para pedidos", pueden costar cinco veces distinto. Lo que mueve el costo, en orden de peso:

1. Las integraciones. Conectar con un ERP que expone API es un trabajo; conectar con uno que solo permite entrar por base de datos, o con un banco, es otro muy distinto.
2. El alcance funcional real. No la lista de deseos: los flujos que de verdad se usan cada día, con sus excepciones. Las excepciones son donde vive el costo.
3. Los usuarios y las sedes. Cinco usuarios en una oficina y doscientos en ocho sucursales exigen arquitecturas distintas, aunque las pantallas se parezcan.
4. La migración. Cuántos datos históricos, en qué estado y desde cuántas fuentes.
5. Lo que ya existe. Reusar un sistema en producción cuesta menos que reescribirlo; a veces conviene y a veces no, y hay que decirlo con el código a la vista.

Por eso no publicamos precios: cualquier cifra sin discovery sería una adivinanza, y una adivinanza baja es la forma más común de que un proyecto termine costando el doble. Lo que sí se puede prometer es que la propuesta separa análisis, desarrollo, integración y migración, y que el precio no cambia si el alcance no cambia.

Cómo se ve un alcance bien escrito

Un documento de alcance útil cabe en pocas páginas y tiene cinco partes: los flujos que entran, descritos como los cuenta quien los opera; lo que explícitamente no entra; las integraciones con nombre y dirección de los datos; los datos que se migran y desde dónde; y los criterios con los que el usuario dirá "esto ya sirve". Si un alcance no tiene la lista de lo que no entra, no es un alcance: es una promesa abierta que alguien va a cobrar después.

Integrar lo que ya tienes: el proyecto con mejor retorno

Es 2026 y todavía hay empresas donde ventas captura el pedido en el CRM, alguien lo pasa a mano al ERP, otro lo teclea en el sistema de almacén, y cuando el cliente pregunta "¿ya se envió?" nadie sabe sin hacer tres llamadas. No es culpa de nadie: los sistemas se compraron en momentos distintos y ninguno fue diseñado para hablar con el otro.

Una API entre tu CRM, tu ERP y tu almacén elimina la captura doble y la reconciliación en Excel cuando los números no cuadran. Lo que determina el esfuerzo: si el sistema expone una API o hay que entrar por base de datos, cuántas entidades se sincronizan (clientes, productos, pedidos, facturas) y en qué dirección. Trabajamos con SAP, Microsoft Dynamics, Odoo, Bind, CONTPAQi y sistemas propios; el distribuidor nacional que pasó de tres días a cuatro horas en su cierre mensual no cambió de ERP: lo conectó.

Inteligencia artificial: antes del piloto, los datos

Casi todos los directores con los que hablamos quieren "meter IA" y casi todos los pilotos que vemos se quedan en demo. La razón rara vez es el modelo: es que los datos que necesita están en 47 archivos de Excel, sin un identificador común, y nadie definió qué decisión se va a tomar con la respuesta. La IA amplifica lo que hay; si lo que hay es desorden, amplifica el desorden.

El orden correcto es el mismo de esta guía: primero el sistema de registro (dónde viven los datos), luego la integración (que los datos fluyan), y al final la IA encima. Cuando ese orden se respeta, el resultado sí llega: en un proyecto de validación documental con IA para una empresa de manufactura y logística, el proceso pasó de semanas a minutos porque los documentos ya llegaban ordenados a la API. Y como somos partner de Google en Google Cloud, Workspace y Maps, la mayoría de estas soluciones se construyen sobre esa plataforma; lo decimos como hecho, no como aval.

Qué pasa después de la entrega

Un sistema a la medida no se termina: se estabiliza y luego evoluciona. Las primeras semanas en producción sacan a la luz los casos que nadie mencionó en discovery, y eso es normal; lo que no es normal es que no haya quien los atienda. Antes de firmar, deja acordado quién da soporte después de la entrega, con qué tiempo de respuesta y cómo se cotizan los cambios pequeños, para que el sistema no se congele el día que el proyecto se cierra. Un mantenimiento mensual modesto, con horas incluidas, suele costar menos que un solo "proyecto de ajustes" seis meses después.

Diez preguntas para cualquier proveedor (incluidos nosotros)

1. ¿Quién va a hablar con la persona que opera el proceso, y cuándo?
2. ¿Cada cuánto veré algo funcionando, con mis datos?
3. ¿De quién es el código y dónde vive?
4. ¿Qué pasa si el desarrollador asignado se va a mitad del proyecto?
5. ¿Cómo se migra desde el Excel o el sistema actual, y qué corre en paralelo?
6. ¿Qué sistemas actuales se conectan y cómo?
7. ¿Qué queda fuera del alcance, por escrito?
8. ¿Cómo se decide un cambio de alcance a medio camino?
9. ¿Quién da soporte después de la entrega y con qué tiempo de respuesta?
10. ¿Puedo hablar con un cliente que haya terminado un proyecto con ustedes?

Si un proveedor se incomoda con alguna, ya tienes tu respuesta. La sesión de discovery con nosotros no cuesta, y sale con un alcance escrito aunque decidas no seguir.