¿Cuánto tarda hacer un sistema o una app? (y qué parte depende de ti)

Lo que publican los proveedores

No hay un estudio independiente que mida cuánto tarda un sistema para una pyme en México. Lo que hay son los plazos que publican los propios proveedores. Sirven de referencia, no como dato del mercado.

MVP es la primera versión mínima que ya se puede usar. MeepLab atribuye sus plazos de apps a otras dos agencias, Magokoro y 7kai.

Varios dicen lo mismo sobre qué alarga el plazo. Alcodea menciona la velocidad de aprobación del cliente; Hemia, la disponibilidad de los responsables; Fuera de la Caja, las reglas del negocio que nadie había documentado.

Por qué nadie te puede dar una fecha exacta al inicio

Construx, la firma de Steve McConnell, lo llama el cono de incertidumbre. Con solo la idea, una estimación puede quedar entre la cuarta parte y cuatro veces lo real. Esto vale para el precio y para el plazo.

El cono no se cierra con el tiempo: se cierra cuando se toman decisiones. Según Construx, un compromiso firme solo es posible hacia el 30% del proyecto.

Por eso desconfía de una fecha final exacta dada en la primera llamada. Pide fechas por etapa: la primera en firme y las siguientes como rango que se ajusta con cada entrega.

Cómo se ve un proyecto bien llevado

El manual de 18F, la oficina de tecnología del gobierno de Estados Unidos que cerró en 2025, propone reglas que sirven igual para una pyme:

• Ciclos de dos semanas, cada uno con software funcionando al final, sin excepción.
• Que los usuarios reciban algo de valor a más tardar seis meses después de firmar.
• "Demos, no memos": ver y probar el software, no leer reportes de avance.

En una pyme, el primer proceso debería estar en uso en semanas. Si en dos meses no has visto nada funcionando, pregunta por qué.

Lo que depende de ti

El mismo manual dice que la persona clave de un proyecto está del lado del cliente: quien prioriza, revisa cada entrega y decide con autoridad. En una pyme no tiene que ser un puesto de tiempo completo, pero sí alguien con tiempo cada semana y permiso para decidir.

Estas son las seis cosas que más mueven el plazo y que no hace el proveedor:

1. Dar accesos. Dominio, correo, cuentas de nube, WhatsApp, facturación y tiendas de apps, a nombre de tu negocio. Sin ellas no se puede publicar ni conectar nada.
2. Explicar el proceso real. Con quienes lo hacen todos los días, además de quien lo dirige. Las reglas que viven en la cabeza de alguien son las que más alargan.
3. Revisar cada entrega. Probar con tus casos reales y contestar en dos o tres días, no en dos semanas.
4. Decidir. Cada pregunta abierta detiene una parte del trabajo. Una persona con autoridad evita que todo espere al dueño.
5. Limpiar los datos. Quitar duplicados y dar un solo formato a lo que se va a migrar. Nadie lo puede hacer por ti sin preguntarte. Los pasos están en cómo pasar de Excel a un sistema.
6. Capacitar y fijar la fecha de corte. Que tu equipo practique en el sistema real y que el Excel deje de usarse ese día.

Ejemplo ilustrativo. Si cada una de tres entregas espera una semana tu revisión en lugar de dos días, el proyecto se alarga casi dos semanas sin que nadie programe más lento.

Un calendario semana por semana

Ejemplo ilustrativo de un primer módulo web de seis semanas, como un control de pedidos e inventario. Seis semanas es el extremo alto del plazo que publica Stonework para un primer módulo. El calendario es ilustrativo: las tareas son las de cualquier proyecto bien llevado, no el compromiso de un proveedor en particular.

Si tu proyecto lleva una conexión con la facturación del SAT, MeepLab publica que eso suma de 2 a 4 semanas.

Si es app: el tiempo de las tiendas

Una app para iPhone o Android no sale cuando se termina: sale cuando la tienda la aprueba.

• Apple revisa al menos 50% de los envíos en menos de 24 horas y 90% en menos de 48.
• Más de 40% de los problemas sin resolver en la revisión de Apple son por la guía 2.1: apps con fallas, contenido de relleno o información incompleta.
• Google avisa que, para algunas cuentas, la revisión puede tardar hasta siete días o más en casos excepcionales.

Un rechazo cuesta más que la revisión. En Stonework lo vivimos con EventQR: Apple rechazó la versión 1.0.0 por la guía 3.1.1, y desde entonces la app vende el plan con la compra dentro de la app de Apple. No anuncies una fecha de lanzamiento que dependa de que la primera revisión salga bien.

Si todavía no sabes si necesitas app, lee ¿necesito una app o una web?: una web no pasa por ninguna tienda.

Cuándo no tienes que esperar meses

Si un programa de suscripción ya hace tu proceso, el plazo es el de configurarlo y capacitar a tu equipo, no el de construir. Antes de pedir fechas, revisa si lo tuyo es un proceso estándar.

Si sí necesitas construir, el plazo empieza a bajar desde antes de la primera llamada: cómo pedir una cotización de software explica qué escribir para que el proveedor no tenga que adivinar.