¿Cuánto tiempo lleva desarrollar una app? Una respuesta real

Los rangos honestos, los cuatro factores que de verdad mueven el número y cómo un founder no técnico puede leer la estimación de un desarrollador sin que lo engañen.

Una founder con la que trabajamos el año pasado ya le había dicho a su inversor principal que la app estaría lista en ocho semanas. Sacó el número de un freelancer que miró por encima una descripción de un párrafo y dijo “sí, un par de meses”. Cuatro meses después seguía en desarrollo, el inversor hacía preguntas incómodas en cada llamada, y ella estaba convencida de que el equipo era lento. El equipo no era lento. La estimación era ficción, y ella se la había repetido a la única persona con la que más necesitaba mantener la confianza.

Entonces: ¿cuánto tiempo lleva desarrollar una app? Para la mayoría de los productos en etapa temprana, una primera versión confiable lleva de tres a seis meses, desde un alcance claro hasta algo que un cliente que paga pueda usar. Una herramienta interna pequeña se entrega en cuatro a ocho semanas. Un producto transaccional o regulado (pagos, datos de salud, cualquier cosa con compliance) lleva seis a nueve meses o más. Esos rangos suponen un equipo enfocado, un alcance definido y un founder que decide rápido. Cambia cualquiera de esas variables y el número se mueve, a veces mucho.

Esa es la respuesta. El resto de este artículo trata de por qué los rangos son tan amplios y cómo saber si el número concreto que te acaban de dar es real.

“Cuánto tiempo” es la primera pregunta equivocada

Cuando un founder pregunta cuánto tiempo lleva una app, normalmente se refiere a una de tres cosas distintas, y la respuesta cambia para cada una.

Está el demo: algo que puedes poner en una pantalla durante un pitch, recorrer y usar para contar una historia. Está la primera versión real: algo que un cliente que paga usa de verdad, con datos reales, casos límite reales y las partes aburridas que hacen que el software sea confiable (autenticación, manejo de errores, una forma de arreglarlo cuando se rompe). Y está la visión completa: el producto tal como lo describiste en la pizarra, con todas las funcionalidades.

No son el mismo proyecto y no están en el mismo plazo. El demo puede llevar dos semanas. La primera versión real es el número de tres a seis meses de arriba. La visión completa suele llevar un año o más, y casi nunca quieres construirla de una sola vez, porque el mercado te va a enseñar que la mitad está equivocada.

El error más caro que vemos es que el founder le cite a su directorio el plazo del demo mientras espera que aparezca la primera versión real. Así que, antes de preguntar cuánto tiempo, decide cuál de las tres estás intentando entregar en realidad, para cuándo y por qué importa esa fecha. “Cuánto tiempo hasta qué” es la pregunta que te da una respuesta útil.

Qué mueve de verdad el número

Dos apps que suenan idénticas en una frase pueden estar a tres meses de distancia en la práctica. Cuatro factores explican la mayor parte de esa diferencia.

Claridad del alcance. La mayor variable no es el tamaño de la app. Es qué tan claramente está definida. Un producto bien acotado, con un documento de requisitos del que un estudio pueda cotizar, se construye más rápido que un vago “como Airbnb pero para X”, porque el equipo no rehace la misma pantalla tres veces mientras tú descubres qué querías decir. La ambigüedad no aparece como una línea del presupuesto. Aparece como semanas.

Integraciones. Cada vez que tu app tiene que hablar con algo que no controlas (una pasarela de pago, un banco, un ERP, una API del gobierno, un servicio de terceros inestable), agregaste un riesgo que no puedes estimar bien de antemano. Una integración está bien. Cinco integraciones, cada una con su propia calidad de documentación y sus límites de peticiones, es donde los plazos se duplican en silencio. Hemos visto una funcionalidad de dos semanas convertirse en seis porque una API externa se comportó de forma totalmente distinta a lo que prometía su documentación.

Datos y compliance. Una app que guarda nombres y correos es una cosa. Una app que maneja dinero, historias clínicas o cualquier cosa que le importe a un regulador es otra. El trabajo de compliance es ingeniería de verdad, no papeleo que agregas al final, y no se comprime. Si estás en fintech o healthtech, mete los meses extra en tu plan desde el primer día.

Forma del equipo. Un equipo enfocado que ya construyó sistemas parecidos avanza más rápido que un equipo más grande que se está armando por primera vez. Más gente no significa más velocidad. Pasado un número pequeño, el costo de coordinación se come la ganancia. Por eso un socio capaz que ya entregó el mismo patrón antes muchas veces le gana a contratar cuatro ingenieros que luego pasan los dos primeros meses aprendiendo a trabajar juntos.

Las tres cosas que revientan los plazos en silencio

Los founders esperan que los plazos se atrasen por “complejidad técnica”. En la práctica, lo que destruye las estimaciones rara vez es técnico. Son decisiones.

La primera es un alcance indefinido disfrazado de spec terminada. Un documento que dice “el usuario puede gestionar su perfil” parece completo hasta que empieza el desarrollo y el equipo descubre que nadie decidió qué es editable, qué pasa con los datos viejos o si un admin también puede hacerlo. Cada una de esas es una pregunta, y cada pregunta que espera respuesta es una tarea detenida. Una fase de discovery de verdad adelanta esas preguntas para que no aparezcan a mitad del desarrollo.

La segunda es ruleta de integración. No puedes saber cuánto lleva integrar con un sistema hasta que estás dentro de él. Los buenos equipos reducen ese riesgo tocando cada dependencia externa en las dos primeras semanas, no en las dos últimas. Si tu equipo ni siquiera miró la API de la que depende para la tercera semana, tu plazo ya está en riesgo y nadie te lo ha dicho todavía.

La tercera, y la que los propios founders causan, es el impuesto de la lentitud para decidir. El software se construye a la velocidad de la persona más lenta para decidir, y en un proyecto pequeño esa persona sueles ser tú. Cada “déjame pensarlo” en una elección de diseño, cada mensaje de Slack sin responder sobre cómo debería ir un flujo, es alguien parado o, peor, construyendo lo que no era. Hemos visto un proyecto de tres meses estirarse a cuatro porque la founder estaba de viaje y las preguntas se acumularon. El código nunca fue el cuello de botella.

Un rango realista por tipo de proyecto

Este es el mapa aproximado que les damos a los founders antes de cualquier scoping detallado. Trátalo como un ancla de partida, no como una promesa. La estimación detallada sale del alcance.

Fíjate: lo más barato de subestimar es el medio aburrido, la primera versión real. El founder le pone precio mental al demo y luego se sorprende cuando el trabajo de calidad de producción cuesta más. Cuesta más porque “funciona en el demo” y “funciona cuando un cliente real entra a las 11 de la noche con un dato malo” son problemas de ingeniería distintos. Para el lado del dinero de la misma decisión, mira cuánto cuesta construir la misma app, porque tiempo y dinero van juntos, pero no en sincronía perfecta.

Cómo leer una estimación que te entregaron

Cuando alguien te da un plazo, no estás evaluando si es inteligente. Estás evaluando si el número se apoya en algo. Tres pruebas rápidas.

Pregunta en qué se basa. Una estimación confiable hace referencia a un alcance: “dadas estas pantallas y esta integración, seis a ocho semanas”. Una poco confiable no hace referencia a nada: “un par de meses”. Steve McConnell, que ha escrito más sobre estimación de software que casi cualquiera, describe la incertidumbre inicial como un cono que se estrecha solo a medida que el alcance se define. Al principio, una estimación seria puede equivocarse por un factor de cuatro hacia arriba o hacia abajo, y solo se aprieta cuando el trabajo se vuelve concreto. Un número dado antes de que exista el alcance es una adivinanza de traje.

Pide un rango, no una fecha. Las estimaciones reales tienen margen de error al inicio, y se aprieta a medida que el trabajo se define. Un equipo que te da una sola fecha confiada para un proyecto indefinido o es inexperto o te está gestionando. “Seis a ocho semanas, y sabremos cuál después de las dos primeras” es la forma de una respuesta honesta.

Pregunta qué lo haría más largo. La respuesta te dice si de verdad pensaron en tu proyecto. Un buen equipo te devolverá tus riesgos específicos: “la integración con el banco es la incógnita; si su sandbox es lento, suma dos semanas”. Un equipo que dice “nada, lo tenemos resuelto” no miró lo suficientemente a fondo. Que hayas estructurado el contrato como precio cerrado o tiempo y materiales cambia quién carga ese riesgo, pero nunca hace que el riesgo desaparezca.

Qué puedes hacer esta semana para entregar más rápido

Tienes más control sobre el plazo del que crees, y casi nada de eso es técnico.

Recorta la primera versión con más valentía de la que se siente cómoda. La mayor parte de lo que está en tu pizarra no hace falta para poner el producto frente a un cliente que paga, y cada funcionalidad que pospones es tiempo que recuperas ahora. La disciplina de entregar menos es la velocidad más barata a tu alcance.

Deja el alcance concreto antes de que empiece el desarrollo, no durante. Una tarde decidiendo los casos ambiguos al inicio te ahorra semanas de paradas a mitad de camino. Escribe qué está dentro y, más importante, qué está fuera.

Después protege la velocidad del equipo estando disponible. Decide rápido, responde las preguntas el mismo día y no desaparezcas una semana esperando que el plazo aguante. El software se construye a la velocidad de tus decisiones. Si tratas el desarrollo como algo que ocurre sin ti, va a llevar exactamente lo que dure tu semana más lenta, multiplicado por todo el proyecto.

Nada de esto exige que leas código. Exige que trates el plazo como algo que copropietas con el equipo, no un número que les extraes y luego cruzas los dedos. Los founders que entregan a tiempo no son los que encontraron desarrolladores más rápidos. Son los que preguntaron “cuánto tiempo hasta qué”, acotaron con honestidad y se quitaron del camino del desarrollo.

Preguntas frecuentes

¿Cuánto tiempo suele llevar desarrollar una app?
Para una primera versión real que un cliente que paga pueda usar, de tres a seis meses, con un equipo enfocado y un alcance claro. Una herramienta interna pequeña puede llevar de cuatro a ocho semanas. Un producto transaccional o regulado suele llevar seis a nueve meses o más.

¿Cuál es el plazo promedio de desarrollo de una app?
No hay un promedio que valga la pena citar, porque “una app” va de un demo de una semana a una plataforma de un año. Las anclas útiles son por tipo de proyecto: herramienta interna (4–8 semanas), primera versión real del producto (3–6 meses), marketplace (5–8 meses), producto regulado (6–9+ meses).

¿Cuáles son las siete etapas del desarrollo de una app?
Las etapas que la gente lista (discovery, diseño, desarrollo, integración, pruebas, lanzamiento, mantenimiento) importan menos que saber cuáles consumen el tiempo. En la mayoría de los proyectos, discovery e integración se comen mucho más del calendario de lo que el founder espera, y las pruebas son la etapa que se recorta bajo presión y causa el atraso más adelante.

¿Qué tan rápido se puede desarrollar una app?
Un demo clicable puede estar listo en una o dos semanas. Pero “rápido” suele significar recortar las partes que hacen confiable al software, así que la velocidad comprada antes de definir el alcance casi siempre es deuda contra un atraso futuro. Los desarrollos rápidos de verdad vienen de recortar alcance, no de recortar atajos.