Una PWA o herramienta interna sencilla suele estar lista en 4 a 8 semanas; una primera versión (MVP) híbrida publicada en App Store y Google Play, en 3 a 5 meses; y una app con pagos, tiempo real e integraciones complejas, de 6 a 12 meses. El plazo lo define el alcance de la primera versión, la claridad de las decisiones del cliente y las revisiones de las tiendas.
- El alcance de la primera versión pesa más en el plazo que la tecnología elegida.
- Descubrimiento y diseño suelen tomar entre una cuarta y una tercera parte del proyecto.
- Google Play pide a las cuentas personales nuevas una prueba cerrada de 14 días con al menos 12 testers.
- La revisión de Apple suele resolverse en uno o pocos días, pero un rechazo reinicia el ciclo.
- Las decisiones lentas del cliente retrasan más que cualquier problema técnico.
- Lanzar una versión pequeña y medir es más rápido que intentar acertar todo desde el inicio.
Plazos típicos según el tipo de app
Estos rangos salen de proyectos reales y suponen un equipo pequeño y dedicado (diseño, desarrollo y pruebas) y un cliente que responde en días, no en semanas.
| Tipo de proyecto | Ejemplos | Plazo típico |
|---|---|---|
| Microapp o PWA sencilla | Checador, inventario, menú digital, cotizador | 2 a 6 semanas si parte de una base existente |
| PWA o herramienta interna a la medida | Portal de clientes, captura en campo, panel de pedidos | 4 a 8 semanas |
| MVP híbrido en tiendas | App de reservas, lealtad, pedidos con pago | 3 a 5 meses |
| App con backend complejo | Marketplace, logística con rastreo, pagos recurrentes, varios roles | 6 a 12 meses |
Si tu idea encaja en una de nuestras microapps, el plazo se reduce mucho porque la base ya existe y solo se configura con tu marca y tus reglas. Si es algo nuevo, el punto de partida es el servicio de apps móviles.
Las fases de un proyecto y cuánto dura cada una
- Descubrimiento (1 a 3 semanas). Entrevistas con quienes usarán la app, mapa del proceso actual, lista de funciones priorizada y riesgos técnicos. Sale un documento de alcance que todos firman.
- Diseño UX/UI (2 a 5 semanas). Primero flujos y bocetos de baja fidelidad; después pantallas finales y un prototipo navegable. Probarlo con tres o cuatro usuarios reales detecta problemas que en código costarían el triple.
- Desarrollo (4 a 20 semanas). Se trabaja en ciclos de una o dos semanas con entregas que puedes probar en tu teléfono. Backend, base de datos, interfaz e integraciones avanzan en paralelo.
- Pruebas y ajustes (2 a 4 semanas). Pruebas en varios teléfonos, conexiones lentas, casos raros y una prueba piloto con un grupo pequeño.
- Publicación (1 a 3 semanas). Fichas de tienda, capturas, política de privacidad, revisión de Apple y Google.
- Mantenimiento (continuo). Corrección de errores, actualizaciones del sistema operativo y nuevas funciones según el uso real.
Explicamos cómo trabajamos estas etapas en nuestro proceso. La clave es que ninguna fase se salte: un descubrimiento apresurado se paga después con semanas de retrabajo. Algunas fases pueden traslaparse, por ejemplo, el backend puede empezar mientras se terminan las últimas pantallas, pero solo cuando el alcance ya está firmado y las reglas del negocio están claras.
Tiendas de apps: el tiempo que no depende de ti
Muchos calendarios fallan porque olvidan que publicar no es instantáneo. Esto es lo que hay que prever en 2026:
- Cuentas de desarrollador. Apple cobra una membresía anual y Google un pago único. Si la cuenta es de empresa, Apple y Google piden verificar la organización, normalmente con un número D-U-N-S, y ese trámite puede tardar varios días o más. Empiézalo en la primera semana.
- Prueba cerrada de Google Play. Las cuentas personales creadas desde finales de 2023 deben correr una prueba cerrada con al menos 12 testers durante 14 días continuos antes de publicar en producción. Las cuentas de organización no tienen esta exigencia, otra razón para abrir la cuenta a nombre de la empresa.
- Revisión de Apple. La mayoría de las revisiones se resuelve en uno o pocos días, pero si rechazan la app hay que corregir y volver a enviar. Los motivos más comunes: información de inicio de sesión de prueba incompleta, funciones que no sirven, falta de opción para borrar la cuenta o una app que es solo un sitio web empaquetado.
- Políticas de privacidad. Ambas tiendas piden declarar qué datos recolectas. Prepáralo junto con tu aviso de privacidad conforme a la ley mexicana de datos personales.
Una PWA se salta todo esto: se publica en tu dominio el mismo día. Por eso en nuestra guía de app nativa vs. PWA recomendamos validar con una PWA cuando el proyecto lo permite.
Lo que más alarga un proyecto
En nuestra experiencia, los retrasos casi nunca son técnicos. Estos son los culpables más frecuentes:
- Alcance que crece a mitad del camino. "Ya que estamos, agreguemos chat, cupones y un programa de puntos." Cada función nueva toca diseño, backend, pruebas y tiendas.
- Decisiones que tardan. Si aprobar una pantalla toma dos semanas porque el dueño está de viaje, el equipo se detiene o avanza sobre supuestos.
- Integraciones con sistemas viejos. Conectar con un punto de venta, un ERP o un sistema contable sin API documentada puede tomar más que la app misma.
- Contenido que no llega. Textos, fotos, catálogo de productos, precios, términos y condiciones.
- Requisitos legales tardíos. Facturación CFDI, aviso de privacidad, consentimiento para datos biométricos o de salud.
Una buena práctica es usar la matriz de Eisenhower para separar lo urgente de lo importante en la lista de funciones: lo que no es importante para el lanzamiento se va a la versión 2.
Cómo acortar el plazo sin sacrificar calidad
- Define una sola tarea principal. Si la app de tu restaurante sirve para pedir, que pedir sea perfecto. Las reseñas, la lealtad y las promociones pueden esperar.
- Reutiliza lo que ya existe. Inicio de sesión con Supabase, pagos con Mercado Pago o Stripe, mensajes por WhatsApp Business API. No hay que reinventar cada pieza.
- Un solo código para ambas plataformas. Con Capacitor o una PWA no duplicas el trabajo de iOS y Android.
- Nombra a un responsable con autoridad. Una persona del lado del cliente que pueda aprobar en 48 horas.
- Prueba con usuarios reales desde el prototipo. Corregir un flujo en diseño toma horas; en código, días.
- Abre las cuentas de tienda el primer día. Así la verificación corre en paralelo con el desarrollo.
Ejemplo: app de lealtad para una cafetería en Torreón
Una cafetería con tres sucursales en Torreón quería "una app como la de las grandes cadenas" con pedidos, pagos, puntos, cupones y notificaciones. El primer cálculo apuntaba a más de seis meses.
Partimos el proyecto en dos:
- Fase 1, en 5 semanas: tarjeta de lealtad digital en el celular, sin descarga, y pedidos para recoger con aviso por WhatsApp. Se apoyó en la base de MonkeyLealtad.
- Fase 2, cuatro meses después: con datos de uso reales, se construyó la app híbrida en tiendas con pago dentro de la app y notificaciones nativas, solo con las funciones que los clientes sí usaban.
El resultado: la cafetería empezó a juntar clientes recurrentes en el segundo mes, no en el séptimo, y la fase 2 costó menos porque se eliminaron dos funciones que nadie pedía. Para cuidar la operación, conviene que una app así se conecte con tu inventario y tu CRM; lo explicamos en la guía de CRM para pymes en México.
Señales de que un plazo es irreal
Una cotización que promete demasiado rápido suele salir más cara al final. Desconfía cuando veas alguna de estas señales:
- Fecha de entrega sin fase de descubrimiento. Si el proveedor no ha preguntado cómo trabaja hoy tu equipo, está adivinando el alcance.
- "Dos apps nativas en seis semanas" con muchas funciones. Es posible para algo muy pequeño; para un sistema con pagos, roles y panel administrativo, no.
- No mencionan las tiendas. Si nadie habla de cuentas de desarrollador, prueba cerrada ni revisión de Apple, el calendario termina el día que acaba el código, no el día que tus clientes descargan la app.
- Sin tiempo para pruebas. Un proyecto donde las pruebas son "la última semana" casi siempre se lanza con errores visibles.
- Sin plan para después del lanzamiento. Las primeras semanas con usuarios reales siempre revelan ajustes. Si no están contemplados, terminan cobrándose aparte.
Un plazo realista no es el más corto: es el que incluye todas las fases y deja margen para las decisiones que todavía no tomas. Pide que te expliquen cada semana del cronograma; si no pueden, el número no está bien fundamentado.
Qué pedirle a tu proveedor antes de empezar
- Un cronograma por fases con entregables que puedas probar, no solo una fecha final.
- Qué está fuera del alcance, por escrito.
- Quién es dueño del código, el dominio, el servidor y las cuentas de tienda (debe ser tu empresa).
- Cómo se manejan los cambios de alcance y cómo afectan el plazo.
- Plan de mantenimiento después del lanzamiento y tiempos de respuesta ante fallas.
- Dónde se guardan los datos y cómo se respaldan; lo tratamos en la guía de respaldos para negocios.
Si quieres una estimación aterrizada a tu caso, revisa cómo cotizamos o escríbenos con la lista de funciones que tienes en mente. Te decimos qué entra en una primera versión y qué puede esperar.
