Casi todas las respuestas que encontrará a la pregunta «¿cuánto tarda una app?» se quedan en un «entre tres y seis meses» que no sirve para planificar nada. Aquí preferimos darle la aritmética completa: cuántas semanas ocupa cada tamaño de aplicación, en qué se van esas semanas y, sobre todo, qué exigen Apple y Google antes de permitir que alguien descargue su app, porque esa segunda parte es la que hace que los lanzamientos se retrasen de verdad.
La respuesta corta, en semanas
Empecemos por los tres rangos honestos, sin rodeos. Una app pequeña, de 5 a 8 pantallas, con un único tipo de usuario y sin pagos, se construye en 5 a 8 semanas. Una app de negocio estándar, con cuentas, pagos, notificaciones y un panel de administración, ocupa de 12 a 16 semanas. Y una plataforma con varios roles, seguimiento en vivo, chat e integraciones con sistemas ajenos se mueve entre 6 y 9 meses.
Conviene entender de dónde sale ese número, porque lo fija el alcance y no el esfuerzo. Un equipo que echa más horas no acorta el calendario de forma apreciable, ya que el trabajo no es una tarea larga sino muchas tareas encadenadas que dependen unas de otras: nadie puede probar lo que todavía no está programado, ni programar lo que todavía no está decidido. Por eso la única palanca real para mover la fecha es mover lo que hay dentro de la app.
La mayoría de los clientes que llegan a Linkysoft diciendo «es una app sencilla» están describiendo, sin saberlo, el tramo del medio. Cuentas de usuario, pagos y notificaciones suenan a tres detalles, pero son tres piezas de trabajo independientes, cada una con su lógica, sus fallos posibles y sus propias pruebas, y sumadas empujan casi cualquier proyecto al rango de 12 a 16 semanas.
Hay una condición escondida dentro de esos rangos: dan por hecho que las decisiones llegan a tiempo. Es la suposición que falla con más frecuencia, así que el resto del artículo explica dónde falla y cuánto cuesta exactamente cuando falla.
Qué es una app pequeña, una estándar y una grande
Puede clasificar su propio proyecto sin saber nada de programación, con tres preguntas que cualquier gerente responde en un minuto. ¿Cuántas pantallas distintas verá el usuario? ¿Cuántos tipos de persona inician sesión con permisos diferentes? ¿Con cuántos sistemas de fuera hay que conectarse, como una pasarela de pago, una empresa de reparto o el programa de facturación que ya utiliza?
Un ejemplo que se repite mucho: una app de citas para una clínica, con el lado del paciente, la agenda del médico, recordatorios automáticos y pago en línea. Contada así suena pequeña, pero al dibujar las pantallas salen entre 18 y 22, y hay dos tipos de usuario con permisos distintos, de modo que es una app estándar y no una pequeña. Entre una cosa y otra hay unas siete semanas de calendario, y siempre es mejor descubrirlo en la primera reunión que en la novena.
Hay un detalle que casi nadie cuenta al principio: el panel donde su personal gestiona los contenidos, ve los pedidos o aprueba las reservas. Ese panel es un segundo producto escondido dentro del primero, con sus propias pantallas, sus permisos y sus pruebas, y normalmente añade de 2 a 3 semanas. Tampoco es un extra opcional, porque sin él alguien de su equipo tendría que pedirnos por correo cada cambio de precio. Cuando hablamos de un desarrollo de aplicaciones móviles completo nos referimos a las dos cosas juntas, la app que descarga el cliente y el panel desde el que usted la gobierna.
Las cinco etapas de un proyecto y lo que cuesta cada una en tiempo
Un proyecto estándar de 14 semanas se reparte así: 2 semanas de descubrimiento y especificación escrita, 3 semanas de diseño de interfaz, 6 semanas de programación, 2 semanas de pruebas y correcciones, y 1 semana de preparación y revisión en las tiendas. En la práctica las etapas se solapan un poco, pero el reparto se sostiene proyecto tras proyecto.
El descubrimiento no es una reunión de buenas intenciones, es el documento donde queda escrita cada pantalla y cada regla del negocio: qué ocurre si el cliente cancela con dos horas de antelación, quién puede cambiar un precio, qué ve un usuario que todavía no ha pagado. Redactar eso cuesta dos semanas y evita que alguien esté inventando decisiones en la semana nueve, cuando cambiar de idea cuesta unas cinco veces más que en la semana dos.
La otra regla que protege la fecha es terminar el diseño antes de que empiece la programación. Rehacer una pantalla que ya está construida cuesta alrededor del triple que cambiar un dibujo, porque no basta con volver a montarla: hay que revisar todo lo que la rodea y repetir las pruebas. Un dibujo se corrige en una tarde, mientras que una pantalla ya programada arrastra consigo a las demás.
Dónde se van las horas, y por qué programar es menos de la mitad del trabajo
Si desglosamos el esfuerzo total de ese mismo proyecto sale un reparto que sorprende a casi todo el mundo: en torno al 45 por ciento es programación, un 18 por ciento pruebas y corrección de fallos, un 15 por ciento diseño, un 12 por ciento conectar con sistemas de fuera como la pasarela de pago o la empresa de reparto, y un 10 por ciento el cumplimiento y el papeleo de las tiendas. Dicho de otro modo, más de la mitad de las horas se dedica a algo que no es escribir código.
Las pruebas son la partida peor entendida de todas. La misma app tiene que comportarse igual en un Android de hace cinco años con la pantalla rajada y en el iPhone que salió el mes pasado, y entre modelos, tamaños de pantalla y versiones del sistema operativo eso son decenas de combinaciones que alguien debe recorrer a mano, una por una, con el teléfono delante.
Por eso recortar las semanas de prueba es un ahorro falso. Si la app falla el día del lanzamiento, la factura llega en forma de reseñas de una estrella que se quedan ahí durante meses, devoluciones, llamadas a su equipo de atención y una segunda revisión de la tienda para poder publicar el arreglo. Las dos semanas que se ahorró se pagan tres veces en las dos siguientes.
Lo que Apple y Google exigen antes de publicar nada
Antes que nada están las cuentas. Apple cobra 99 dólares al año por el Apple Developer Program y Google cobra 25 dólares una sola vez por la cuenta de Google Play Console. Las dos deben abrirse a nombre de la empresa y nunca a nombre personal de un empleado, porque el día que esa persona se marche la app se queda dentro de una cuenta que usted no controla.
Una cuenta de empresa necesita un número D-U-N-S, que es un identificador internacional de identidad empresarial, y una comprobación de documentos que suele tardar entre 3 y 14 días. Es un trámite que no depende de nadie del equipo técnico, así que se puede poner en marcha el primer día del proyecto y así deja de estar en el camino crítico, es decir, en la cadena de tareas que marca la fecha final.
Después viene el papeleo que las dos tiendas exigen sin excepción: una política de privacidad publicada y accesible en su propia web, un cuestionario de datos y privacidad que debe coincidir con lo que la app recoge de verdad, una clasificación por edades y un contacto de soporte al que alguien responda. Nada de esto se improvisa la víspera del envío.
Hay tres reglas que pillan desprevenida a mucha gente. Si el usuario puede crearse una cuenta dentro de la app, las dos tiendas obligan a ofrecer también una forma de borrar esa cuenta desde la propia app. Si ofrece entrar con Google o con Facebook, normalmente tendrá que ofrecer también el inicio de sesión de Apple. Y en Europa hay que declarar y publicar los datos de contacto del comerciante, un requisito que no avisa de su ausencia: sin él, la app sencillamente deja de aparecer en las tiendas europeas.
El cuestionario de privacidad merece un aviso aparte, porque hay que responderlo con honestidad frente a lo que la app guarda realmente, no frente a lo que uno cree que guarda. Una herramienta de estadísticas añadida en la semana diez puede convertir una respuesta en falsa sin que nadie se dé cuenta, y ahí es donde una revisión de seguridad y protección de datos antes del envío ahorra un rechazo y varios días de calendario.
La ficha de la tienda, el trabajo que nadie presupuesta
La ficha es lo que ve una persona antes de decidir si descarga su app, y tiene una lista de materiales bastante concreta: un icono cuadrado de 1024 píxeles, capturas de pantalla para cada tamaño de teléfono y de tableta exigido, con hasta diez por tamaño, una imagen destacada de 1024 por 500 píxeles para Google Play, una descripción corta de unos 80 caracteres y una larga de hasta 4000, más la política de privacidad alojada en su propia web.
Escribir y preparar todo eso con cabeza son de 3 a 5 días de trabajo. Y hay una parte que no podemos hacer del todo por usted: las palabras que venden su app son las suyas, porque usted conoce a su cliente y sabe qué frase le convence. Dejarlo para el último viernes es la manera más segura de publicar una ficha mediocre después de cuatro meses de proyecto.
Un detalle pequeño que provoca rechazos grandes: si su app tiene inicio de sesión, debe entregar a Apple y a Google unas credenciales de prueba que funcionen. Una cuenta de revisor ausente, caducada o con la contraseña cambiada es una de las causas de rechazo más frecuentes que vemos, y de las más absurdas, porque el revisor abre la app, no consigue entrar y devuelve el envío sin llegar a mirar nada más.
La buena noticia es que los textos y las capturas se pueden editar después sin volver a pasar por una revisión completa, así que una buena ficha de lanzamiento no tiene que ser una ficha perfecta. Publique la mejor versión razonable y mejórela con lo que aprenda de los primeros usuarios.
Cuánto tarda la revisión y por qué se rechazan las apps
Los tiempos que vemos en la práctica son estos: la mayoría de los envíos a Apple vuelven en 24 a 48 horas, aunque una app nueva en una cuenta nueva suele tardar de 2 a 5 días. La primera publicación en Google Play desde una cuenta recién creada puede llegar a los 7 días, mientras que las actualizaciones posteriores se aprueban normalmente en horas.
Hay una regla de Google que descoloca a mucha gente. Una cuenta personal de Google Play recién abierta tiene que ejecutar antes una prueba cerrada con al menos 12 probadores inscritos de forma continua durante 14 días para poder publicar al público. Son dos semanas que ningún calendario de construcción contempla, y solo se esquivan planificándolo desde el principio o abriendo la cuenta directamente como empresa.
Seamos francos también con el otro dato: en nuestra experiencia, aproximadamente uno de cada tres primeros envíos vuelve con al menos una observación. No es un desastre ni significa que algo esté mal hecho, forma parte del proceso, y el ciclo de corregir y volver a enviar suele ocupar de 2 a 5 días. Lo sensato es reservar ese margen en el calendario en lugar de prometer una fecha que dependa de que todo salga perfecto a la primera.
Las observaciones se repiten casi siempre entre estas cinco:
- Un fallo o un cierre inesperado en el dispositivo concreto del revisor.
- Una cuenta de prueba ausente o caducada.
- Respuestas de privacidad que no coinciden con lo que la app hace de verdad.
- Ninguna forma de borrar la cuenta desde dentro de la app.
- Cobrar contenido digital por fuera del sistema de pago de la tienda.
Los retrasos que más vemos y lo que cuesta cada uno
El primero, y el más caro, es el alta de la pasarela de pago o de la cuenta de comercio, unos 14 días de media, porque depende de un banco o de un proveedor que revisa documentos a su propio ritmo. Después llegan las funciones añadidas a mitad del proyecto, unos 12 días, y la espera de fotos y textos del cliente, unos 10. La verificación de identidad de la cuenta de desarrollador suma alrededor de 9 días, y un rechazo con su correspondiente reenvío, unos 4.
Vale la pena hacer la cuenta en voz alta, porque así se entiende por qué insistimos tanto con las respuestas. Un equipo de tres personas parado una semana son quince jornadas pagadas que no producen absolutamente nada. Esa es la razón por la que una pregunta sin responder puede acabar siendo la partida más cara de todo el proyecto, bastante más cara que cualquier funcionalidad.
El efecto de las funciones añadidas también se acumula en silencio. Cada «detalle rápido» que entra a mitad de la construcción cuesta entre 1,5 y 3 jornadas una vez contados el diseño, la programación, las pruebas y la revisión de las pantallas de alrededor a las que afecta. Cinco añadidos rápidos son dos semanas de calendario, y nadie recuerda haberlas pedido.
Un solo código o dos, y qué le hace eso a su fecha
Multiplataforma significa, en palabras llanas, escribir un solo conjunto de código del que salen las dos apps, la de iPhone y la de Android. Frente a escribir cada una por separado, eso ahorra normalmente entre un 25 y un 35 por ciento de las semanas de programación, y sigue ahorrando después, porque cada corrección se hace una vez y no dos.
Lo nativo, es decir, escribir cada app en el lenguaje propio de su sistema, sigue mereciendo el tiempo extra en casos concretos: procesamiento intenso de cámara o de vídeo, localización continua en segundo plano, uso profundo del hardware del teléfono o un videojuego. Fuera de esos casos, el usuario no nota la diferencia por más que le expliquen la teoría.
Para la inmensa mayoría de las apps de reservas, pedidos, socios, reparto y gestión interna, multiplataforma es la respuesta correcta, y en Linkysoft lo decimos aunque suponga facturar menos semanas, porque un proyecto que sale antes y cuesta menos de mantener es mejor negocio para los dos. Conviene recordar, eso sí, que los requisitos de tienda de este artículo son idénticos con una tecnología o con la otra, de manera que la elección técnica nunca acorta el trabajo de cumplimiento.
Cuándo un lanzamiento más pequeño es de verdad la mejor decisión
Si lo que necesita es mostrar información y recoger una reserva, es posible que no necesite una app. Una web bien hecha para el móvil llega a todos los teléfonos en cuestión de días y no de meses, no pasa por ninguna aprobación y no obliga a nadie a descargar nada. Un buen diseño y desarrollo web resuelve más casos de los que la gente imagina, y se lo decimos aun cuando la app sea el encargo más grande sobre la mesa.
Cuando la app sí tiene sentido, casi siempre se puede recortar la primera versión. Hemos pasado proyectos de 22 pantallas a 9 y hemos publicado en 7 semanas en lugar de 15, dejando el resto para una segunda fase que se decide con datos y no con opiniones. Puede ver cómo han quedado varios de estos proyectos en nuestros casos de éxito.
La ventaja práctica de una primera fase corta no es solo el dinero que se aplaza. Es que empieza a recoger comportamiento real: qué pantallas usan sus clientes, cuáles ignoran, en qué paso abandonan el proceso. Construir la fase dos con esa información cuesta lo mismo y acierta mucho más que construirla a partir de suposiciones.
Lo que puede empezar hoy para proteger su fecha de lanzamiento
Hay tres cosas que puede hacer esta misma semana, antes incluso de firmar nada, y que se traducen en días ganados. Abra las dos cuentas de tienda a nombre de la empresa, publique en su web una política de privacidad y una página de soporte con un contacto real, y nombre a una sola persona con autoridad para tomar decisiones finales en menos de un día. Ese tercer punto es el que más veces marca la diferencia entre un proyecto puntual y uno que se estira sin que nadie sepa muy bien por qué.
Reúna el contenido pronto: fotos reales de su negocio, descripciones auténticas de sus productos o servicios y la redacción exacta de precios, condiciones y política de cancelación. El contenido llega casi siempre tarde porque parece la parte fácil, y sin embargo es la que deja al equipo esperando delante de pantallas con texto de relleno.
Arranque también en la semana uno los trámites del proveedor de pagos y del banco. Esa aprobación queda fuera del control de todos, suele llevar de 1 a 3 semanas y es el retraso más caro de la lista, así que cuanto antes empiece el reloj, menos probable será que su lanzamiento acabe dependiendo del correo de un departamento de riesgos.
Después del lanzamiento: los primeros noventa días y las fechas anuales
Cuente con 2 a 4 actualizaciones pequeñas durante el primer mes. No es la señal de que algo esté roto, sino de que la app está viva: los usuarios reales siempre encuentran cosas que ningún equipo de pruebas puede prever, porque usan el teléfono en el metro, con mala cobertura y con la batería al 3 por ciento.
Luego está el ritmo anual, que conviene tener marcado en el calendario. Cada otoño llegan las nuevas versiones del sistema operativo de los teléfonos, y cada año las dos tiendas suben la versión mínima del sistema con la que hay que preparar el archivo que se envía a la tienda. Una app que pasa un año entero sin tocarse puede llegar a un punto en el que ya no se puede actualizar sin rehacer partes, y ese es un gasto que aparece de golpe y sin aviso.
La regla de presupuesto que damos siempre es sencilla: reserve entre un 15 y un 20 por ciento del coste de construcción por año para mantenimiento, cuotas de las tiendas, alojamiento y pequeñas mejoras. Con eso la app se mantiene sana, sigue apareciendo en las búsquedas de las tiendas y usted no se lleva sustos.
Si quiere una fecha realista para su idea concreta, con las semanas contadas y los trámites de tienda ya colocados en el calendario, en Linkysoft lo hacemos en una primera conversación sin compromiso. Cuéntenos qué quiere construir desde nuestra página de contacto y le devolvemos el plan por escrito, con la fecha y con los supuestos de los que depende.
