Cuánto tarda desarrollar una app: tiempos reales por tipo de proyecto
Semanas, no trimestres. Qué decide el tiempo de un proyecto de software, cuánto suele tardar cada tipo de app y qué lo alarga sin que nadie lo note.
Benjamín Camarena6 min de lectura
"¿Y para cuándo estaría?" es la segunda pregunta de toda conversación sobre una app, justo después de cuánto cuesta. Y como con el costo, la respuesta útil no es un número sino entender de qué depende, porque el tiempo de un proyecto de software no lo decide la tecnología. Lo deciden el alcance, las decisiones y la forma de trabajar del equipo.
Este artículo pone rangos reales por tipo de proyecto, explica qué los alarga y qué los acorta, y sobre todo desmonta la idea de que un producto serio necesita medio año para existir. Con las herramientas de hoy y un equipo que sabe recortar, la mayoría de los proyectos se miden en semanas.
Lo que de verdad decide el tiempo
Cuatro cosas, en este orden:
El alcance. Igual que con el costo, es la palanca más grande. Cada función es diseño, desarrollo y pruebas, y las funciones se multiplican entre sí. Un proyecto de diez funciones no tarda el doble que uno de cinco: tarda más, porque cada una tiene que convivir con las otras nueve.
La velocidad de las decisiones. Un proyecto se detiene cada vez que espera una respuesta: qué campos lleva el formulario, cuál de las dos propuestas de pantalla se queda, qué pasa cuando el pago falla. Si esas respuestas tardan una semana cada una, el proyecto tarda semanas más, sin que nadie haya trabajado más lento.
El tamaño del equipo y cómo se coordina. Más gente no es más rápido. Un equipo grande necesita juntas, documentos y traspasos entre áreas; un equipo chico donde las mismas personas diseñan y construyen decide en minutos. Escribimos sobre esto en por qué ya no necesitas un equipo de quince personas.
Las dependencias externas. La aprobación de la App Store, una integración con un sistema de terceros, el acceso a datos que alguien más tiene que dar. No están bajo el control del equipo y conviene identificarlas desde el inicio.
El tiempo no lo decide la tecnología. Lo deciden el alcance, la velocidad de las decisiones y cómo se coordina el equipo.
Rangos por tipo de proyecto
Estos tiempos suponen un equipo chico y senior, con estrategia, diseño y desarrollo en las mismas manos, y un alcance recortado antes de empezar. Con una agencia grande o un alcance sin disciplina, multiplica por dos o tres.
| Tipo de proyecto | Tiempo habitual | Qué lo mueve |
|---|---|---|
| Landing page o sitio de presentación | 1 a 3 semanas | Cantidad de secciones, contenido listo o no |
| MVP de app o de sistema web | 4 a 10 semanas | Un flujo principal completo; cobros y notificaciones suman |
| App con varias funciones e integraciones | 2 a 4 meses | Cada integración externa y cada plataforma extra |
| Sistema a la medida para una empresa | Primer módulo en 4 a 8 semanas; el resto por etapas | Cuántos procesos, cuántos roles, con qué se conecta |
| Tienda en línea a la medida | 6 a 12 semanas | Catálogo, pagos, envíos, facturación |
La fila importante es la del MVP. Si te cotizan seis meses para una primera versión, casi siempre significa una de dos cosas: que el alcance no es mínimo, o que el equipo tiene una estructura que hay que alimentar. Lo explicamos en qué es un MVP y cómo hacer uno que sí sirva.
Cómo se reparte el tiempo
Un proyecto bien llevado no es "diseño, luego desarrollo, luego pruebas" en bloques separados. Es un ciclo corto que se repite. Pero a grandes rasgos, el tiempo se va así:
- Entender y recortar (una semana o menos). Qué problema se resuelve, para quién, qué entra y qué no. Es la semana que más tiempo ahorra de todo el proyecto.
- Diseñar el flujo principal (una a dos semanas). Pantallas reales, con textos reales, que se pueden tocar antes de programar nada. Aquí se toman las decisiones baratas de cambiar.
- Construir por etapas (el grueso). Cada etapa entrega algo que se puede usar. No hay un "gran día de integración" al final donde todo se junta y nada funciona.
- Probar con gente real y ajustar (una a dos semanas). No pruebas de laboratorio: el producto en manos de usuarios de verdad, y los ajustes que salen de ahí.
- Publicar. En web es inmediato. En la App Store, la revisión de Apple suele tomar entre uno y varios días, y conviene contarla desde el inicio.
Lo que alarga un proyecto sin que nadie lo note
Casi nunca es "el programador es lento". Son estas cosas:
- Cambiar el alcance a la mitad. Cada función nueva a medio camino no solo suma su tiempo: obliga a revisar lo que ya estaba hecho.
- Decidir por comité. Si cada pantalla necesita la aprobación de cinco personas, el proyecto avanza al ritmo de la agenda de la más ocupada.
- Contenido que no llega. Textos, fotos, catálogos, precios. El producto puede estar listo y no poder lanzarse porque faltan los datos reales.
- Accesos que no se dan. Cuentas de la tienda, del dominio, del sistema con el que hay que integrarse. Pedirlos en la semana uno, no en la ocho.
- Perfeccionar lo que nadie ha usado. Pulir una pantalla durante dos semanas antes de que un usuario real la vea es tiempo que casi siempre se tira.
Cómo acortar sin sacrificar calidad
La calidad no es lo que se recorta. Lo que se recorta es esto:
- Una plataforma primero. iOS o web, la que tenga a tus usuarios. La otra después, con lo aprendido.
- Un flujo completo antes que cinco a medias. Un usuario que puede hacer una cosa de principio a fin vale más que uno que puede empezar cinco.
- Piezas probadas para lo que no te distingue. Pagos, inicio de sesión, correos, notificaciones: se ensamblan, no se inventan. El tiempo del equipo va a lo que hace único a tu producto.
- Una sola persona que decide. De tu lado, alguien con autoridad para responder en el día. Es el acelerador más barato que existe.
- Entregas que se pueden usar cada una o dos semanas. Así los problemas aparecen cuando son chicos.
Preguntas frecuentes
¿Se puede hacer una app en dos semanas?
Una landing page o una app muy acotada, sí. Un MVP con registro, un flujo principal y cobro, en dos semanas es difícil hacerlo con calidad. En cuatro a seis, con el alcance bien recortado, es lo normal.
¿Qué tanto retrasa la App Store?
La revisión de Apple suele tomar de uno a varios días. Lo que sí retrasa es que rechacen la app por algo evitable: permisos mal explicados, capturas que no corresponden, textos legales que faltan. Un equipo que ha publicado varias veces lo prepara desde antes.
¿Es más rápido si contrato más gente?
Casi nunca. Sumar gente a un proyecto en marcha lo frena mientras se ponen al día, y después lo hace más lento por coordinación. Es más rápido recortar alcance que agrandar equipo.
¿Qué hago si el proyecto ya va tarde?
Recortar. Buscar qué se puede dejar para después de lanzar y lanzar con lo que sí está. Un producto en manos de usuarios con tres funciones enseña más que uno perfecto que sigue sin salir.
En tēo studio trabajamos en semanas, no en trimestres, porque recortamos antes de construir y decidimos en el día. Si quieres saber cuánto tardaría tu proyecto, cuéntanos qué quieres construir y te devolvemos un plan por etapas con fechas realistas.
SOBRE EL AUTOR
Benjamín Camarena · Fundador y diseñador de producto de tēo studio
Benjamín Camarena es diseñador de producto y fundador de tēo studio, un estudio de software en Tepatitlán, Jalisco, que diseña y construye apps y sistemas a la medida para empresas de México, Estados Unidos, Canadá y el resto del mundo. Antes de fundar el estudio diseñó productos para empresas como PGA TOUR, Samsung, UFC y Hy-Vee.