Los proyectos de apps rara vez se retrasan porque programar sea lento. Se retrasan porque alguien tarda tres semanas en dar un acceso, una API no hace lo que decía su documentación o el alcance creció un poquito cada viernes.
En Espacio Rojo, un proyecto típico se entrega en 60 a 90 días. Esa cifra vale para un alcance acotado, y lo importante es saber qué la mueve.
Las etapas
1. Alcance. Decidir qué hace la primera versión y, sobre todo, qué no. Es la etapa más corta y la que más tiempo ahorra después. Llega con un brief de una hoja y avanzará más rápido.
2. Diseño. Flujos y pantallas, incluidos los estados incómodos: sin datos, con error, sin permiso. Revisar aquí cuesta mucho menos que cambiar algo ya programado.
3. Desarrollo. Por entregas que puedes abrir en tu propio teléfono. Pide ver avances frecuentes: si la primera vez que tocas la app es al final, las sorpresas también llegan al final.
4. Pruebas. En teléfonos reales, con datos reales y con mala señal. El emulador no te va a enseñar qué pasa en un Android de gama media a media ruta.
5. Tiendas. Preparar fichas, formularios y enviar a revisión. Parece el trámite final, y es donde más proyectos tropiezan con una fecha.
Lo que más alarga un proyecto
| Causa | Por qué pasa | Cómo evitarlo |
|---|---|---|
| Accesos y datos que no llegan | Dependen de terceros o de otra área | Pedirlos en la primera semana |
| Integraciones | La documentación no coincide con la realidad | Probar la conexión antes de todo lo demás |
| Decisiones sin dueño | Nadie puede aprobar | Nombrar a una sola persona que decida |
| Alcance que crece | Cada idea buena parece pequeña | Lista aparte para la versión dos |
| Cuentas de las tiendas | El alta de una empresa puede tardar | Resolverlo desde el inicio |
El calendario de las tiendas
Hay dos plazos que no controlas y deberías incluir en tu calendario desde el primer día:
- Cuenta de empresa en Apple. Las organizaciones necesitan número D-U-N-S, y obtenerlo puede llevar tiempo si tu empresa no lo tiene. Publicar con la cuenta de un publisher evita esa espera.
- Cuenta personal nueva en Google Play. Exige una prueba cerrada con 12 personas durante 14 días seguidos antes de solicitar producción. Las cuentas de organización no tienen este requisito.
Y la revisión en sí. Suele resolverse en poco tiempo, pero un rechazo suma días, sobre todo en la primera versión. No programes tu lanzamiento para el día siguiente al envío.
Cómo proteger tu fecha
Si la fecha importa, por ejemplo por una feria o una temporada, trabaja hacia atrás:
- Envía a revisión con semanas de margen. Una app aprobada se puede dejar lista y liberar el día que elijas.
- Define qué se recorta si hay retraso. Decídelo antes. Con presión, todo parece indispensable.
- Resuelve primero lo incierto. Empieza por la integración difícil, no por las pantallas fáciles.
- Pide avances que puedas instalar. TestFlight en iPhone y las pruebas internas de Google Play permiten probar una versión real antes de publicarla.
Si te prometen demasiado poco tiempo
Una estimación muy corta no siempre es mala, pero pide que te la expliquen. ¿Incluye el backend? ¿Las pruebas? ¿La publicación? ¿Se basa en una plantilla? Las apps de plantilla pueden salir rápido, pero tienen sus propios problemas con Apple.
Si tienes una fecha en mente, cuéntanos cuál es y por qué. Te diremos con franqueza qué cabe y qué tendría que esperar.