Cuánto tarda desarrollar un software a medida: plazos reales y qué los alarga

Respuesta corta: ¿cuánto se tarda en desarrollar un software a medida?

Depende del tamaño del problema, pero hay rangos bastante estables. Una integración o automatización concreta entre dos sistemas suele estar lista en dos a seis semanas. Una herramienta interna de gestión para un equipo pequeño, la que sustituye a la hoja de cálculo de clientes, pedidos o partes de trabajo, necesita entre seis y doce semanas. Un portal para clientes o una aplicación con reglas propias del negocio se mueven entre tres y seis meses, y lo razonable es tener una primera versión en uso mucho antes, a las seis u ocho semanas. Lo que casi nadie cuenta es que el calendario depende más de las decisiones que de la programación. Un proyecto pequeño puede durar el doble si cada respuesta tarda una semana en llegar, y uno mediano puede ir muy rápido si el proceso está claro y alguien con capacidad de decisión revisa las entregas a tiempo. Aquí hablamos solo del plazo; lo que cuesta cada tipo de proyecto se explica en cuánto cuesta un software a medida.

Un software a medida para una pyme ya no es un proyecto de un año. Con un alcance acotado, se mide en semanas. Lo que convierte las semanas en meses casi nunca es el código.

Plazos orientativos por tipo de proyecto

Estos rangos corresponden a un proyecto con un alcance definido por escrito, ejecutado por un estudio pequeño y con una persona del cliente disponible para resolver dudas. Cuentan desde que empieza el análisis hasta que el sistema está en uso, sin incluir el periodo de estabilización posterior, que se explica más abajo. Son orientativos: sirven para saber si un calendario que te proponen es razonable, no para sustituirlo. Si aún no tienes claro si necesitas construir algo, software a medida o estándar: cómo decidir te ayuda a resolverlo antes de hablar de plazos.

Si te prometen un plazo muy por debajo de estos rangos sin haber analizado tu proceso, o muy por encima para algo acotado, pregunta qué incluye exactamente. La diferencia suele estar en el alcance, no en la velocidad.

• Integración o automatización concreta, de dos a seis semanas: conectar la tienda online con el programa de facturación, volcar los formularios de la web en tu herramienta de gestión o generar automáticamente un informe semanal. El plazo se alarga sobre todo si uno de los sistemas no tiene una forma documentada de conectarse.
• Herramienta interna de gestión, de seis a doce semanas: clientes, presupuestos, pedidos o partes de trabajo, con varios usuarios, permisos básicos e informes sencillos. La parte más impredecible suele ser traer los datos desde las hojas de cálculo actuales.
• Portal o área privada para clientes, de dos a cuatro meses: añade la parte que ve el cliente, con acceso seguro, seguimiento de expedientes o pedidos, documentos y avisos. Exige más pruebas, porque lo van a usar personas a las que no puedes formar una por una.
• Aplicación web con lógica de negocio propia, de tres a cinco meses: cálculo de tarifas, planificación de turnos o rutas, flujos de aprobación. Lo sensato es dividirla en fases y tener la primera en uso a las seis u ocho semanas.
• Plataforma con varios perfiles, pagos o muchos usuarios, de cuatro a ocho meses: casi siempre se construye por fases, y el calendario lo marca el orden en que se activan las partes, no la fecha de una entrega final.
• Aplicación móvil para iOS y Android, de tres a seis meses: además del desarrollo hay que contar con la revisión de las tiendas de aplicaciones antes de publicar. Antes de comprometer ese plazo, comprueba si una aplicación web adaptada al móvil cubre lo que necesitas; app móvil o aplicación web explica cómo decidirlo.

Las fases de un desarrollo y cuánto dura cada una

Cualquier desarrollo serio pasa por las mismas fases, aunque cada proveedor las llame de una forma. Conocerlas te permite entender en qué punto está tu proyecto y en cuáles tu participación es imprescindible. Las duraciones son las de una herramienta interna de tamaño medio.

Las fases se solapan, pero no se pueden eliminar. Un plazo que no reserva tiempo para el análisis o para las pruebas no es más rápido: aplaza el problema hasta después de la entrega.

• Análisis del proceso, de una a dos semanas: entender cómo se trabaja hoy, qué datos se manejan, qué excepciones existen y qué sistemas hay que conectar. Termina con el alcance por escrito. Es la fase que más se intenta saltar y la que más tiempo ahorra después.
• Diseño de pantallas y flujos, de una a tres semanas: cómo se verá y en qué orden se harán las cosas. Se revisa con las personas que van a usar el sistema, no solo con quien lo encarga, porque son ellas las que detectan los pasos que sobran.
• Desarrollo por entregas, la mayor parte del calendario: se construye en bloques de una o dos semanas, y cada bloque termina con algo que puedes probar. Es preferible a esperar al final para verlo todo, porque los malentendidos aparecen en la primera entrega y no en la última.
• Migración de datos, en paralelo al desarrollo: limpiar, unificar y cargar la información que hoy está en hojas de cálculo, correos o programas antiguos. Empezarla tarde es una de las causas más habituales de retraso. Migrar de Excel a un software a medida explica los pasos.
• Pruebas con usuarios reales, de una a tres semanas: personas del equipo usan el sistema con casos de verdad. Aquí aparecen las situaciones que nadie mencionó en el análisis.
• Puesta en marcha y formación, de una a dos semanas: activar el sistema, formar al equipo y decidir cuándo se deja de usar la herramienta anterior.

Por qué 90 horas de trabajo no son dos semanas de calendario

En cuánto cuesta un software a medida usamos el ejemplo de una herramienta interna con tres perfiles de usuario, avisos por correo e informes básicos: unas 90 horas de trabajo entre análisis, diseño, desarrollo, pruebas y puesta en marcha. Si alguien trabajara solo en eso a jornada completa, serían algo más de dos semanas. En la práctica, ese proyecto suele durar entre seis y ocho semanas de calendario, y no porque nadie esté perdiendo el tiempo. La diferencia entre el esfuerzo y el calendario está en las esperas. Cada fase termina con algo que el cliente tiene que revisar, y la revisión depende de la agenda de personas que siguen atendiendo su trabajo habitual. El diseño necesita una reunión con el equipo. Los datos de ejemplo tardan en llegar. Una integración espera a que el proveedor del otro sistema facilite un acceso. Entender esto tiene una consecuencia útil: la forma más eficaz de acortar un proyecto no es presionar a quien programa, sino reducir las esperas. Un cliente que responde en dos días en lugar de en una semana puede ahorrar casi tanto calendario como el que se ganaría duplicando el equipo de desarrollo, sin coste adicional.

Las horas miden el esfuerzo y las semanas miden las esperas. Cuando un proyecto se alarga, casi siempre crecen las segundas, no las primeras.

Lo que más retrasa un proyecto (y casi nunca es la programación)

Cuando se revisa a posteriori por qué un proyecto tardó más de lo previsto, las causas se repiten bastante. Casi todas se pueden prevenir si se conocen desde el principio.

La mayoría de los retrasos de un software a medida se deciden en la primera semana: si hay una persona con tiempo y autoridad para decidir, los datos están localizados y el alcance está por escrito, el calendario suele cumplirse.

• Decisiones que nadie toma: qué hacer con los clientes duplicados, quién aprueba un presupuesto, qué pasa cuando un pedido se cancela a medias. Si la persona que sabe la respuesta no tiene tiempo o no tiene autoridad para darla, el proyecto se detiene en ese punto.
• Datos desordenados: tres hojas de cálculo con formatos distintos, campos que cada persona rellena a su manera e información que solo existe en correos. Ordenarlos lleva más tiempo que programar la pantalla que los muestra.
• Integraciones que dependen de terceros: el programa de facturación que no ofrece una forma documentada de conectarse, el proveedor que tarda semanas en dar un acceso o la herramienta que cambia sus condiciones a mitad del proyecto.
• Cambios de alcance a mitad de camino: cada función nueva que se añade sin quitar otra desplaza la fecha final. No es malo cambiar de idea cuando se ve el sistema funcionando; lo es no ajustar el calendario cuando se hace.
• Una sola persona que conoce el proceso: si quien sabe cómo funciona todo está de vacaciones, de baja o en plena temporada alta, nadie puede resolver las dudas y las pruebas se aplazan.
• Pruebas que se posponen: el sistema está listo para probar, pero el equipo no encuentra el momento. Es el retraso más frecuente al final de un proyecto y el más difícil de recuperar.

Qué parte del calendario depende de ti

Un proveedor puede comprometer su parte del trabajo, pero no la tuya. Por eso conviene saber desde el principio qué se espera del cliente y reservarlo en la agenda igual que se reserva cualquier otra tarea importante. Estas son las aportaciones que más influyen en el plazo.

Un buen proveedor te dirá desde el primer día qué necesita de ti y cuándo. Si nadie te lo pregunta, el retraso ya está en el calendario aunque todavía no se vea.

• Una persona de referencia con capacidad de decisión: no hace falta que sea quien encarga el proyecto, pero sí que pueda resolver dudas sin consultar cada respuesta. Lo habitual es que necesite entre dos y cuatro horas a la semana.
• Datos reales desde la primera semana: ejemplos de presupuestos, pedidos o expedientes, con sus casos raros incluidos. Con datos inventados, el sistema funciona en las pruebas y falla el primer día de uso.
• Accesos y permisos a tiempo: cuentas de los programas que hay que conectar, contacto con sus proveedores y autorización para usarlos. Pedirlos el primer día evita esperas a mitad del proyecto.
• Revisión de cada entrega en dos o tres días: es el compromiso que más acorta el calendario. Si una entrega espera una semana a ser revisada, todo lo que viene después se desplaza una semana.
• Tiempo del equipo para las pruebas y la formación: las personas que van a usar el sistema tienen que probarlo antes de que se active. Conviene fijar esas fechas al principio y evitar que coincidan con la temporada alta.

Cómo acortar el plazo sin recortar calidad

Acortar un proyecto no consiste en pedir que se programe más deprisa. Consiste en reducir lo que hay que construir antes de la primera fecha importante y en eliminar esperas. Estas decisiones son las que más calendario ahorran.

Pocas cosas acortan tanto un proyecto como decidir qué no va a estar en la primera versión. Cada función que se mueve a una fase posterior adelanta la fecha en que empiezas a ahorrar tiempo.

• Separa la primera versión del resto: decide qué tiene que funcionar el primer día y qué puede llegar después. Una primera versión que resuelve bien un solo proceso puede estar en uso en la mitad de tiempo que el sistema completo, y lo que aprendas usándola mejora las fases siguientes. Es la lógica de validar antes de desarrollar todo.
• Fija un ritmo de revisión: una reunión corta a la misma hora cada semana, con decisiones apuntadas, evita que las dudas se acumulen.
• Congela el alcance de cada fase: las ideas nuevas que surgen a mitad se apuntan para la fase siguiente en lugar de añadirse a la actual. Así la fecha comprometida se mantiene y las ideas no se pierden.
• Empieza a ordenar los datos antes de que empiece el desarrollo: localizar los archivos, decidir cuál es la versión buena de cada dato y eliminar duplicados es trabajo que puede hacer tu equipo mientras se analiza el proceso.
• Activa el sistema por partes: primero un equipo o una sede, después el resto. Los problemas aparecen con menos usuarios y se corrigen antes de que afecten a todo el negocio.

Un calendario real, semana a semana

Para ver cómo encajan las fases, este es el calendario de un caso habitual con cifras ilustrativas: una empresa de mantenimiento con ocho técnicos que gestiona los partes de trabajo en una hoja de cálculo compartida y quiere sustituirla por una herramienta propia, con acceso desde el móvil para los técnicos, un panel para la oficina y un informe mensual por cliente.

En este ejemplo hay nueve semanas hasta la puesta en marcha y doce hasta que el sistema funciona sin acompañamiento. Si la revisión del diseño hubiera esperado dos semanas, todo lo demás se habría desplazado dos semanas.

• Semanas 1 y 2: análisis. Dos reuniones con la oficina y una con dos técnicos, revisión de la hoja de cálculo y de los partes en papel que siguen existiendo, y alcance por escrito. El cliente envía ejemplos reales de partes de los últimos tres meses.
• Semana 3: diseño. Pantallas del parte en el móvil y del panel de la oficina, revisadas con los técnicos. Se decide que la firma del cliente en el móvil queda para la segunda fase.
• Semanas 4 a 7: desarrollo en dos entregas. La primera permite crear y cerrar partes; la segunda añade el panel, los filtros y el informe. Mientras tanto, la oficina limpia la lista de clientes y elimina duplicados.
• Semana 8: pruebas. Tres técnicos usan la herramienta en paralelo con la hoja de cálculo durante cinco días laborables. Aparecen dos casos no previstos que se corrigen esa misma semana.
• Semana 9: puesta en marcha. Formación de una hora para el equipo, carga final de datos y la hoja de cálculo pasa a ser solo de consulta.
• Semanas 10 a 12: estabilización. Ajustes menores, dudas de uso y el primer informe mensual generado por el sistema.

Si tienes una fecha límite: cómo planificar hacia atrás

Muchos proyectos empiezan con una fecha que no se puede mover: el inicio de la temporada alta, la apertura de un nuevo local, la incorporación de personal o un cambio de normativa. En esos casos la pregunta no es cuánto se tarda, sino cuándo hay que empezar. La forma correcta de responderla es contar hacia atrás desde la fecha en que el sistema tiene que estar funcionando, no desde la fecha de entrega. Un ejemplo con la herramienta del apartado anterior: si tiene que estar plenamente en uso el 1 de marzo, conviene reservar tres semanas de estabilización antes, lo que sitúa la puesta en marcha a principios de febrero. Con nueve semanas de proyecto, el análisis debería empezar a primeros de diciembre. Si en medio hay dos semanas de vacaciones de Navidad en las que nadie revisará nada, la decisión de contratar tendría que estar tomada a mediados de noviembre. Calculado así, empezar a pensarlo en noviembre para una fecha de marzo no es ir sobrado: es ir justo. Con las fechas legales ocurre lo mismo. Quien emite facturas con un programa propio o adaptado tiene que cumplir Verifactu, cuya obligación empieza el 1 de enero de 2027 para las sociedades y el 1 de julio de 2027 para los autónomos, según el calendario vigente. Adaptar un sistema existente requiere primero un diagnóstico y luego varias semanas de trabajo y pruebas. Para una sociedad que todavía no lo ha resuelto, el margen hasta enero ya es corto; para un autónomo, el momento razonable de empezar es ahora y no la primavera.

Si al contar hacia atrás la fecha de inicio ya ha pasado, todavía hay opciones: reducir la primera versión a lo imprescindible para esa fecha y dejar el resto para después. Lo que no funciona es mantener todo el alcance y esperar que el calendario se comprima solo.

• Pon la fecha en que el sistema tiene que funcionar, no la de entrega.
• Resta de dos a cuatro semanas de estabilización y pruebas reales.
• Resta la duración del proyecto según su tipo, con su análisis incluido.
• Resta las semanas en las que tu equipo no estará disponible: vacaciones, cierres contables, temporada alta.
• Resta el tiempo que necesitas para elegir proveedor y firmar. El resultado es la fecha en la que tienes que empezar a moverte.

Cómo leer el calendario de una propuesta

Un presupuesto serio incluye un calendario ligado a hitos, como se explica en la lista de comprobación de qué debería incluir un presupuesto de software a medida. Pero no todos los calendarios dicen lo mismo, y conviene leerlo con la misma atención que la cifra. Un calendario útil tiene fases con duración, un entregable al final de cada una, la fecha de puesta en marcha separada de la de entrega y, sobre todo, una lista de lo que se espera de ti y cuándo. Estas son las señales que deberían hacerte preguntar.

El calendario más fiable no es el más corto, sino el que explica de qué depende cada fecha. Así, cuando algo se retrasa, sabes por qué y qué hacer para recuperarlo.

• Hay una fecha sin haber analizado tu proceso: un plazo dado en la primera llamada es una suposición. Pregunta qué tendría que pasar para que se cumpla.
• Todo se entrega al final: si no hay entregas intermedias que puedas probar, los malentendidos se descubrirán cuando ya no queda calendario para corregirlos.
• No aparece ninguna dependencia del cliente: un proyecto en el que tú no tienes que hacer nada no existe. Si no figura, el retraso que provoquen tus esperas acabará atribuyéndose al proveedor o a ti, según quién discuta mejor.
• No hay tiempo para pruebas ni para la puesta en marcha: el calendario termina el día en que se acaba de programar. Ese día el sistema no está listo para usarse.
• La fecha es fija y el alcance no está cerrado: si cualquiera de los dos puede cambiar, el otro también tendrá que moverse. Un calendario serio dice qué pasa con la fecha cuando cambia el alcance.

Después de la entrega: el periodo que no suele aparecer en el plazo

El día que el sistema se activa no termina el proyecto. Durante las primeras semanas el equipo descubre situaciones que no aparecieron en las pruebas, pide pequeños ajustes y todavía consulta la herramienta anterior por costumbre. Es normal, y conviene contar con ello: de dos a cuatro semanas de estabilización en una herramienta interna, y algo más en un portal que usan los clientes. En ese periodo importan tres cosas. La primera, que esté claro quién resuelve las dudas y en cuánto tiempo, porque una duda sin respuesta es un motivo para volver a la hoja de cálculo. La segunda, fijar una fecha a partir de la cual la herramienta anterior deja de usarse, porque mantener dos sistemas a la vez duplica el trabajo y los errores. La tercera, distinguir entre corregir errores, que debería estar cubierto por la garantía, y pedir funciones nuevas, que pertenecen a la siguiente fase. A partir de ahí empieza el mantenimiento, cuyos costes se detallan en el artículo sobre el precio del software a medida.

Un software está terminado cuando el equipo trabaja con él sin acompañamiento y nadie abre la herramienta anterior. Esa fecha, no la de entrega, es la que conviene planificar.

Preguntas frecuentes sobre los plazos de un software a medida

Estas son las dudas que más se repiten cuando una pyme empieza a planificar un desarrollo.

• ¿Se puede tener un software a medida en un mes? Sí, si el alcance es pequeño: una automatización concreta o una primera versión de una herramienta interna que resuelve un solo proceso. Lo que no cabe en un mes es un sistema completo con varios perfiles, integraciones y datos que migrar.
• ¿Si pongo más programadores, termina antes? No necesariamente. En proyectos pequeños, añadir personas obliga a repartir el trabajo y a coordinarse, y eso consume parte del tiempo que se quería ganar. Fred Brooks lo resumió hace décadas en una idea muy citada: añadir personas a un proyecto de software que va con retraso lo retrasa todavía más.
• ¿Una agencia lo hace más rápido que un estudio pequeño? Una agencia tiene más personas, pero también más coordinación y más capas entre quien decide y quien programa. En proyectos de pyme, la velocidad depende más de lo bien que se entienda el proceso y de lo rápido que se tomen las decisiones. La comparación completa está en freelance o agencia para tu proyecto IT.
• ¿La inteligencia artificial ha acortado los plazos? Ha acortado la parte de programación, sobre todo la más repetitiva. No ha acortado el análisis, las decisiones del cliente, la migración de datos ni las pruebas con usuarios, que son las fases que más calendario consumen.
• ¿Puedo seguir trabajando con Excel mientras se desarrolla? Sí, y es lo habitual. Lo que conviene evitar es que la hoja de cálculo siga cambiando de estructura durante el proyecto, porque complica la migración de los datos.
• ¿Qué pasa si el proyecto se retrasa? Depende de lo que diga el contrato y de quién provoque el retraso. Por eso es útil que el calendario recoja las dependencias de cada parte y que los pagos estén ligados a entregas y no solo a fechas.
• ¿Cuándo debería empezar si todavía no sé exactamente qué necesito? Cuanto antes, pero por el análisis y no por el desarrollo. Si todavía estás decidiendo entre una herramienta estándar y una propia, este análisis de las opciones cuando Excel no es suficiente es un buen punto de partida.

Por dónde empezar si tienes prisa

Si tienes una fecha en mente, el primer paso es hacer la cuenta hacia atrás de este artículo con tus propias fechas y comprobar cuánto margen queda de verdad. El segundo es preparar lo que más calendario ahorra y que no depende de ningún proveedor: localizar los datos que tendrá que usar el sistema, elegir a la persona que va a decidir y apuntar las situaciones raras del proceso que hoy se resuelven de memoria. Con eso, cualquier análisis será más corto y cualquier calendario, más fiable. En Mizura Studio empezamos siempre por entender el proceso antes de comprometer una fecha, y te decimos con claridad qué puede estar funcionando en tu fecha límite y qué tendría que esperar a una segunda fase. Si quieres saber cuánto tardaría tu caso concreto, cuéntanos qué necesitas y lo revisamos contigo.

La forma más rápida de tener un software funcionando no es empezar a programar cuanto antes. Es decidir pronto qué tiene que estar listo primero y quitar del camino todo lo que obliga a esperar.