Cuánto tiempo tarda en construirse una app a medida: plazos realistas por alcance

Has pedido presupuesto para tu desarrollo a medida en un par de sitios, y junto al precio te han dado un plazo. Uno dice seis semanas. Otro, cuatro meses. Para lo que en tu cabeza es más o menos lo mismo. No sabes si el rápido va a cumplir, si el lento se está cubriendo las espaldas, o si simplemente uno te está diciendo lo que quieres oír para que firmes ya.

Es una duda razonable, y casi nadie te explica antes de pedir presupuesto qué es lo que mueve ese número. El plazo de un desarrollo a medida no sale de una tabla ni de una fórmula: sale de cuánto hay que construir y de cuánto dependéis los dos de que el otro responda a tiempo.

¿Por qué dos proveedores dan plazos tan distintos para lo mismo?

Rara vez es porque uno curre más rápido. En desarrollo a medida, la velocidad de trabajo entre proveedores serios no varía tanto como para explicar diferencias de meses. Lo que varía es qué ha entendido cada uno que hay que construir, y cuánto tiempo han contado de más allá del propio código.

Un proveedor mete en su plazo el tiempo de que tú revises y apruebes cada fase, las pruebas con datos parecidos a los reales, y un margen para lo que casi siempre aparece por el camino. Otro solo cuenta el tiempo de escribir el código de la funcionalidad principal, sin pensar en nada de lo anterior, y te da un número que suena bien pero que no incluye medio proyecto.

Si un plazo no viene acompañado de qué incluye cada fase y cuánto dura cada una, no tienes forma de comparar dos plazos como si fueran lo mismo. Estás comparando una cifra optimista con una realista, y las dos te las dan con la misma seguridad.

¿Qué es lo que de verdad mueve el plazo?

Como con el precio, no es la tecnología. Un desarrollo con React o con lo que sea puede ir rápido o lento según lo que haya alrededor del código, no según el nombre de la herramienta.

Fíjate en la cuarta fila: buena parte del tiempo que se pierde en un proyecto no es tiempo de construir, es tiempo de esperar respuestas. Si tienes dudas sobre si tu proyecto encaja en desarrollo a medida o le basta con configurar algo ya hecho, eso también cambia el plazo, y conviene resolverlo antes de fijar fechas.

Plazos orientativos según tu caso

Con eso claro, aquí van rangos amplios para que te hagas una idea antes de pedir presupuesto:

• Si necesitas automatizar un proceso concreto o conectar dos herramientas que ya usas → entre 3 y 6 semanas.
• Si necesitas una herramienta de gestión interna con varias partes conectadas (por ejemplo, pedidos + stock + facturación básica) → entre 2 y 4 meses.
• Si necesitas una plataforma completa con usuarios externos, pagos e integraciones múltiples → de 4 meses en adelante, casi siempre entregada por fases que ya funcionan antes de terminar el resto.
• Si lo que tienes es una idea sin acotar todavía → el primer paso no es un plazo, es una conversación para definir el alcance. Cualquier fecha que te den antes de eso es una suposición con forma de compromiso.

Son rangos para orientarte, no una promesa. Un proyecto pequeño con una integración complicada puede tardar más que uno grande sin ninguna.

¿Por qué una fecha cerrada en la primera llamada es mala señal?

Porque un plazo real necesita saber qué hay que construir, y eso no se sabe en la primera conversación. Si alguien te da "seis semanas" sin haberte preguntado apenas nada sobre tu proceso, tus datos actuales o quién tiene que aprobar qué, esa fecha no viene de un cálculo. Viene de lo que cree que quieres escuchar.

No significa mala fe necesariamente. A veces es optimismo genuino de alguien que no ha visto todavía las partes feas del problema. Pero el resultado es el mismo: una fecha que se incumple, y que tú habías dado por buena para organizar tu propio negocio alrededor de ella. Un plazo serio suele venir con un "esto es orientativo hasta que veamos X" delante, no con una promesa cerrada de entrada.

Un caso con números

Un negocio con 15 personas necesita una herramienta para gestionar los turnos del equipo, algo que hoy se coordina por WhatsApp y una hoja compartida que se pisa cada semana. Pide dos presupuestos.

El primero llega con una fecha: "en cinco semanas lo tenéis". Nadie preguntó cuántos turnos distintos hay, si hay festivos o bajas que cambian el patrón, ni quién tiene que dar el visto bueno cada semana a los cuadrantes.

El segundo llega así: "primera fase, la asignación básica de turnos funcionando, cuatro semanas; una vez la probéis con una semana real, vemos si hacen falta las excepciones de festivos y bajas, que suelen añadir dos o tres semanas más". Aquí el plazo viene con lo que todavía no se sabe, en lugar de escondido detrás de una cifra que suena bien.

Son cifras de ejemplo, no una tarifa: el tuyo depende de tu proceso real. Lo que no cambia es que el segundo proveedor te ha dado información para decidir, y el primero te ha dado una cifra para que dejes de preguntar.

¿Cómo evito que el plazo se alargue sin darme cuenta?

Casi nunca se alarga porque el equipo vaya lento. Se alarga porque el alcance creció por el camino sin que nadie lo tratara como tal: una funcionalidad que se añadió "ya que estamos", una aprobación tuya que se quedó una semana sin respuesta, una integración que resultó tener más casos raros de los previstos.

La forma de que esto no te pase es tratar cualquier cosa que no estuviera en la fase original como una fase nueva, con su propio plazo, en vez de como un añadido que debería caber en el calendario ya fijado. Y por tu parte, dejar claro desde el principio quién en tu equipo aprueba cada entrega y en cuánto tiempo, porque ese tiempo de espera cuenta tanto como el de construir.

Esta misma lógica, aplicada al precio en vez de al calendario, la tienes en la guía de cuánto cuesta una app a medida. Y si todavía estás en la fase de pedir presupuestos y quieres saber qué más preguntar antes de firmar, aquí tienes las preguntas que te protegen de firmar a ciegas.

Si tienes un proyecto en la cabeza y quieres un plazo real, no una cifra para tranquilizarte, escríbenos a contact@easybyte.es. Te lo damos después de entender tu caso, con las fases separadas, no antes.