Cuánto se tarda en desarrollar un software
El plazo de un software depende del alcance de la primera fase, las integraciones, los datos que migrar, la rapidez de las decisiones y las pruebas. Una cifra dada antes del análisis es una estimación; lo que conviene exigir es ver avances desde la primera semana.
Cuánto tiempo se tarda en desarrollar un software depende de seis cosas: el alcance de la primera fase, las integraciones, los datos que hay que migrar, la rapidez con la que se decide y se valida en tu empresa, el nivel de pruebas exigido y los requisitos legales. Por eso el plazo fiable sale del análisis de tu caso, no de una tabla.
No damos semanas genéricas: el plazo con el que se puede trabajar llega en la propuesta, después de analizar tu caso. Lo útil es otra cosa: saber qué alarga un calendario, qué lo acorta, cómo se compone el plazo de una primera fase y cómo leer el calendario de una propuesta para que no te sorprenda.
De qué depende el plazo
El tiempo de un desarrollo es la suma de dos cosas: el trabajo técnico y las esperas. El primero depende del tamaño del sistema; las segundas, de cómo se organiza el proyecto. Estos son los seis factores que más pesan:
- Alcance de la primera fase. Cuántos procesos, pantallas y perfiles con permisos distintos entran. Un sistema que lleva un presupuesto hasta la factura no se parece a otro que además gestiona almacén, taller y un portal para clientes.
- Integraciones. Cada conexión con otro programa (pasarela de pago, correo, contabilidad, portales del sector) depende de que exista una forma documentada de conectarse y de que el otro lado dé acceso. A veces conseguir ese acceso tarda más que programar la conexión.
- Datos que migrar. No es lo mismo empezar de cero que traer años de histórico repartido en hojas de cálculo, con duplicados y formatos distintos. Hay que limpiar, ensayar la migración y comprobar que los totales cuadran.
- Decisiones del cliente. Quién aprueba el prototipo, quién valida cada entrega y cuánto tarda en hacerlo. Una semana esperando una respuesta es una semana que el calendario no recupera.
- Pruebas. Pruebas automáticas en cada entrega, pruebas con datos reales y, si varias empresas o sedes comparten el sistema, pruebas de que nadie ve datos ajenos. No es tiempo perdido: es el que evita rehacer.
- Requisitos legales. Facturación, protección de datos o normas del sector. Conviene identificarlos en el análisis y no al final; si una norma fija una fecha, el calendario se planifica hacia atrás desde ella.
Por qué nadie puede darte una cifra fiable el primer día
La consultora de ingeniería de software Construx lo explica con el llamado cono de incertidumbre. Al principio de un proyecto, cuando solo existe la idea, las estimaciones que hacen personas expertas pueden quedarse cuatro veces por encima o cuatro veces por debajo de lo que al final cuesta el proyecto, sea en esfuerzo o en calendario: entre la estimación más alta y la más baja hay un rango de 16 veces.
Lo interesante es cómo se reduce ese margen. Según la misma fuente, dedicar más días a estimar no lo estrecha. Lo estrechan las decisiones: definir qué se va a hacer (y qué no), cerrar los requisitos y diseñar las pantallas. Si el producto se redefine a mitad de camino, el cono vuelve a abrirse.
Traducido a tu proyecto: un plazo dado antes de analizar tu proceso y de ver un prototipo es una estimación, y conviene tratarlo como tal. El plazo con el que se puede trabajar llega después, con el alcance de la primera fase cerrado por escrito.
Qué retrasa un proyecto y qué lo acelera
Muchos retrasos nacen en los mismos sitios. Esta tabla resume dónde se pierde el tiempo y qué lo evita:
| Factor | Lo que alarga el plazo | Lo que lo acorta |
|---|---|---|
| Alcance | Añadir funciones a mitad de fase porque «ya que estamos» | Primera fase con el proceso que más duele; el resto, a una lista de mejoras |
| Decisiones | Nadie con autoridad para aprobar; validaciones que esperan semanas | Una persona que decide y un día fijo para revisar entregas |
| Datos | El estado real del histórico se descubre al migrar | Una muestra de datos reales desde el análisis y alguien que se encarga de limpiarlos |
| Integraciones | Depender de un tercero sin documentación ni entorno de pruebas | Pedir accesos de prueba el primer día y conectar primero lo que hoy se copia a mano |
| Equipo | Cambiar de interlocutor o sumar gente cuando el proyecto ya va tarde | El mismo equipo de principio a fin |
| Pruebas | Probarlo todo al final, cuando corregir cuesta más | Pruebas automáticas en cada entrega |
| Cambios | Cambios pedidos de palabra, sin precio ni plazo | Cambios por escrito, con su efecto en el calendario antes de aprobarlos |
Sobre el equipo, una advertencia: sumar personas a un proyecto que va tarde rara vez lo acelera en proporción. Quien llega tiene que aprender el sistema, y el resto dedica más tiempo a coordinarse. Suele funcionar mejor ajustar el alcance de la fase que inflar el equipo.
Entregas por fases: avances desde la primera semana
Más que el plazo total, importa cada cuánto vas a ver algo funcionando. Un proyecto que solo enseña resultados al final acumula el riesgo de descubrir tarde lo que no encaja, cuando corregirlo ya cuesta semanas.
Una referencia clásica es el Manifiesto Ágil, de 2001, que entre sus principios propone entregar software funcional con frecuencia, «entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible». La Guía de Scrum, en su versión de noviembre de 2020, organiza el trabajo en ciclos de duración fija de un mes o menos, los llamados sprints.
Nosotros trabajamos por fases: tras el análisis, una propuesta cerrada; antes de programar, un prototipo navegable; durante el desarrollo, entregas con avances desde la primera semana y pruebas automáticas en cada una. Qué recibes al cerrar cada fase lo explicamos en fases de un proyecto de software. Y si lo primero es validar una idea, la primera fase puede ser un producto mínimo viable, que empieza a usarse antes.
Ejemplo: cómo se compone el plazo de una primera fase
Pongamos una primera fase que lleva el presupuesto hasta la factura en una empresa que hoy lo hace con hojas de cálculo. Sin semanas inventadas, su calendario se compone de estas etapas, y en cada una hay trabajo técnico y esperas:
| Etapa | Qué se hace | Qué la alarga | Qué necesita de ti |
|---|---|---|---|
| Análisis | Entrevistas, muestra de datos reales y propuesta cerrada de la fase | Que nadie tenga clara la forma actual de trabajar | Una persona que conozca el proceso y los datos de ejemplo |
| Prototipo | Pantallas navegables y rondas de cambios | Validaciones que esperan o que cambian el alcance | Revisar el prototipo con quien lo va a usar |
| Entregas de desarrollo | Presupuestos, clientes y facturas, en entregas que puedes probar | Cambios pedidos a mitad de una entrega | Probar cada entrega y responder en el día fijado |
| Integración y migración | Conexión con contabilidad o correo, ensayo de migración y comprobación de totales | Accesos de terceros que tardan o datos sucios | Accesos de prueba y alguien que valide los totales |
| Puesta en marcha | Migración definitiva, formación y soporte los primeros días | Mantener el sistema anterior a medias | Fecha de cambio y personas disponibles para formarse |
El plazo total es la suma de esas etapas, y una parte depende de tu lado de la mesa. Por eso un buen calendario pone fecha a los hitos y también a lo que se necesita de ti.
Cómo leer el calendario de una propuesta
Un calendario serio no es una fecha final: es una secuencia de hitos con sus dependencias. Antes de aceptarlo, comprueba que tiene esto:
- Hitos con entregable. Cada fecha dice qué podrás usar o revisar, no un porcentaje de avance.
- Lo que se necesita de ti. Datos, accesos y validaciones, y para cuándo. Un calendario que no dice nada de tu parte está incompleto, y los retrasos acabarán cayendo de tu lado.
- Supuestos por escrito. Por ejemplo, en qué formato llegan los datos o cuántos días hay para validar una entrega.
- Margen para lo desconocido. Sobre todo en integraciones con terceros, que no dependen del equipo de desarrollo.
- Cómo afecta un cambio. Quién lo valora y cómo se refleja en las fechas.
- La puesta en marcha, aparte. Terminar de programar no es lanzar: faltan la migración definitiva, la formación y el soporte de los primeros días.
- Una fecha para dejar el sistema anterior. Mantener los dos a medias alarga todo.
Si además estás comparando ofertas, en presupuesto de desarrollo de software explicamos qué debe traer el resto del documento y cómo ponerlas una al lado de otra.
Cómo acortar el plazo sin recortar calidad
La tentación es recortar pruebas. Es un mal atajo: el error que no se caza en una prueba lo encuentra tu equipo trabajando, y corregirlo entonces lleva más tiempo. Lo que sí funciona:
- Reducir el alcance, no la calidad. Una primera fase pequeña que funciona bien se usa antes que una grande a medias.
- Preparar los datos desde el principio. Una muestra real en el análisis evita sorpresas al migrar.
- Reservar tiempo de quien decide y de quien prueba. Un día fijo a la semana basta para que las entregas no esperen.
- Validar con prototipo. Corregir una pantalla dibujada es mucho más rápido que corregirla programada.
- Usar servicios que ya existen para pagos, correo o almacenamiento, en lugar de construirlos.
- Automatizar las comprobaciones. En nuestra plataforma, antes de publicar un cambio pasan más de mil comprobaciones automáticas. Es lo que permite entregar a menudo sin miedo a romper lo que ya funciona.
Si además del plazo estás valorando el coste, lee de qué depende el coste de un software a medida: los factores que mueven el precio son, en buena parte, los mismos que mueven el calendario. Y puedes ver cómo trabajamos en desarrollo de software a medida.
Fuentes consultadas
Comprobadas el 26 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- The Cone of Uncertainty. Construx.
- Principios del Manifiesto Ágil (versión en español). Manifiesto Ágil.
- Manifiesto por el Desarrollo Ágil de Software (versión en español). Manifiesto Ágil.
- The 2020 Scrum Guide. Scrum Guides.
Preguntas frecuentes
¿Cuánto se tarda en hacer una aplicación?
Depende de los mismos factores que cualquier software: alcance, integraciones, datos y rapidez en las decisiones. Hay uno más: si se hacen aplicaciones nativas para cada sistema, cada una se desarrolla y se publica en su tienda, con sus propios pasos de revisión. Una aplicación web instalable (PWA) evita esa duplicación.
¿Se puede fijar una fecha de entrega cerrada?
Sí, para una fase con el alcance cerrado por escrito, después del análisis y del prototipo. Antes de eso, cualquier fecha es una estimación con mucho margen de error. Lo razonable es cerrar la fecha fase a fase, no la del sistema completo desde el primer día.
¿Qué pasa si el proyecto se retrasa?
Primero hay que saber por qué: si el retraso viene del proveedor, de un cambio de alcance o de una espera por parte de tu empresa. Por eso conviene que el calendario diga qué necesita de ti y que cada cambio se apruebe con su efecto en las fechas. Las consecuencias concretas se pactan en el contrato.
¿La inteligencia artificial acorta el tiempo de desarrollo?
Puede acelerar partes de la programación, pero no las decisiones, las integraciones con terceros, la limpieza de datos ni las pruebas con tu equipo, que son las que más pesan en el calendario. Desconfía de plazos que solo se justifican por usar IA.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.