¿Cuánto tarda desarrollar un software a medida?
Primera versión en 3 semanas aprox. en Altura, con alcance y accesos acordados. Qué incluye cada semana y qué puede cambiar la fecha.
Resumen
Ideas clave
- Planificamos la primera versión en aproximadamente 3 semanas desde el inicio acordado, con alcance, contenidos y accesos disponibles.
- Una fecha útil necesita alcance, capacidad del equipo, dependencias y criterios de aceptación.
- Horas de trabajo y semanas de calendario no son lo mismo: aprobaciones y accesos también condicionan la entrega.
- El plazo debe incluir definición, diseño, pruebas y puesta en marcha, además del código.
- Una primera versión más pequeña puede llegar antes si resuelve un proceso completo.
Primera versión en aproximadamente 3 semanas
Planificamos la primera versión en aproximadamente 3 semanas desde el inicio acordado, con alcance, contenidos y accesos disponibles.
Trabajamos con la misma referencia inicial para webs, tiendas, automatizaciones, sistemas y aplicaciones. Lo que cambia es el alcance de la primera entrega: un producto con varios módulos, un SaaS completo o una migración grande se divide en etapas y no se presenta como terminado en ese plazo.
El alcance y la fecha se confirman en la propuesta. Nuevas funciones, migraciones extensas o dependencias externas se evalúan por separado.
Para responder cuánto tarda desarrollar software en un caso concreto, primero hay que definir qué debe funcionar en la primera versión y con qué equipo se cuenta. Un plazo sin usuarios, funciones, integraciones y pruebas acordadas describe una intención, no un cronograma que se pueda evaluar.
Tiempo de desarrollo de software a medida por tipo de proyecto
El plazo orientativo incluye diseño, construcción, validación y puesta en marcha del alcance inicial. El inicio se acuerda con el alcance definido, los accesos y contenidos disponibles y una persona del negocio que pueda revisar avances. La tabla delimita qué se puede planificar como primera entrega.
| Proyecto | Alcance inicial | Plazo orientativo |
|---|---|---|
| Web de empresa | Hasta cinco páginas de presentación, servicios y contacto, con diseño adaptable y SEO técnico inicial; sin paneles operativos ni migraciones extensas. | 3 semanas aprox. |
| Tienda online inicial | Un catálogo inicial preparado por el cliente, compra, pago y envío habituales sobre una plataforma o base existente; sin ERP, reglas B2B ni migraciones extensas. | 3 semanas aprox. |
| Automatización puntual | Un flujo entre herramientas con accesos disponibles, reglas definidas, validaciones y registro de errores. | 3 semanas aprox. |
| Sistema de gestión inicial | Un proceso interno con carga y consulta de datos, estados y permisos básicos; importación inicial acotada y sin integraciones complejas. | 3 semanas aprox. |
| Software a medida: primera versión | Un recorrido operativo con reglas propias, usuarios y datos definidos, construido sobre componentes disponibles; funciones adicionales por etapas. | 3 semanas aprox. |
| Aplicación web / MVP | Un recorrido principal para usuarios, acceso, permisos básicos y un panel acotado; un SaaS completo, marketplace o múltiples integraciones requieren otras etapas. | 3 semanas aprox. |
La referencia de tres semanas sirve para planificar el alcance inicial que podamos cerrar por escrito. Si aparecen reglas nuevas, integraciones no previstas o datos que deben depurarse, revisamos el alcance y la fecha antes de continuar. No implica que cualquier plataforma completa pueda desarrollarse en tres semanas.
La fecha de inicio importa tanto como la duración. Pedí distinguir disponibilidad del proveedor, comienzo del relevamiento, primera entrega de prueba y puesta en producción. Tampoco se deben confundir una demostración y un sistema listo para operar.
Factores que modifican los tiempos
Dos sistemas con la misma cantidad de pantallas pueden requerir trabajos muy distintos. Para estimar el tiempo de desarrollo de software conviene mirar las reglas que hay detrás, las dependencias y el esfuerzo de comprobar que todo funciona.
- Definición: una regla pendiente puede bloquear diseño, construcción y pruebas al mismo tiempo.
- Integraciones: permisos, ambientes de prueba, documentación y respuestas del proveedor externo.
- Datos: registros duplicados, formatos diferentes y necesidad de conservar historial.
- Validación: disponibilidad de personas que conocen el proceso y pueden aprobar decisiones.
- Capacidad: dedicación del equipo, especialidades necesarias y otras tareas que compiten por su tiempo.
- Calidad y operación: seguridad, rendimiento, recuperación y condiciones para usar el sistema.
- Cambios: incorporar una función nueva puede modificar también permisos, datos y pruebas existentes.
Cómo distribuimos las tres semanas de desarrollo
Este es el esquema inicial de trabajo una vez acordado el alcance y confirmados los accesos. Las pruebas acompañan la construcción desde el principio. La distribución se ajusta al proyecto y se confirma en la propuesta.
| Semana | Trabajo principal | Resultado a revisar |
|---|---|---|
| Semana 1 | Validar recorridos y diseño; preparar la base y empezar a construir. | Pantallas principales, criterios de aceptación y primer avance revisable. |
| Semana 2 | Completar el flujo principal y las conexiones incluidas, con pruebas continuas. | Una versión funcional para revisar con situaciones del negocio. |
| Semana 3 | Resolver ajustes del alcance, probar permisos y excepciones, documentar y publicar. | Primera versión acordada en funcionamiento, accesos y entrega al equipo. |
IBM describe el desarrollo como un ciclo que incluye planificación, diseño, construcción, pruebas, despliegue y mantenimiento. La distribución de ese trabajo depende del alcance; asignar un porcentaje fijo a cada fase no reemplaza estimar las tareas reales.
Por qué las horas de trabajo no equivalen al plazo de entrega
El esfuerzo suma trabajo; el calendario también incorpora esperas y tareas que dependen unas de otras. Si una integración requiere credenciales que llegan la semana siguiente, sumar otro desarrollador no resuelve necesariamente esa espera.
Atlassian explica que la estimación ágil considera complejidad, esfuerzo e incertidumbre, y se calibra con lo que el equipo va entregando. Los puntos de historia son una medida relativa; no equivalen automáticamente a horas o días ni sirven para comparar la velocidad de equipos diferentes.
Cómo estimamos un proyecto de software en Altura
Partimos de un proceso real y de la primera versión que necesita tu empresa. Definimos usuarios, funciones, datos e integraciones antes de acordar etapas. La estimación de tiempos de desarrollo de software debe dejar visibles las decisiones que todavía faltan y las responsabilidades de cada parte.
Ordenamos las entregas para que puedas revisar el funcionamiento con tu equipo. Si aparece una necesidad fuera del alcance, se evalúan su impacto y su prioridad antes de incorporarla. Eso permite discutir una modificación de plazo con información concreta.
- Definir qué recorrido debe poder completarse y con qué criterios se aprueba.
- Dividir el alcance en entregables que se puedan demostrar y revisar.
- Identificar dependencias, datos pendientes y disponibilidad para validar.
- Acordar etapas, supuestos y tratamiento de cambios en la propuesta.
- Revisar lo entregado y actualizar la planificación cuando cambie el alcance.
Cómo llegar antes a una primera versión útil
Si hay una fecha importante, empezá por separar lo imprescindible de lo que puede esperar. Un flujo completo para un grupo de usuarios suele ser más fácil de validar que varias funciones incompletas para toda la organización.
Prepará ejemplos de datos, confirmá los accesos y asigná una persona que pueda resolver dudas. También conviene evaluar componentes existentes para necesidades comunes. Recortar permisos o saltear pruebas puede trasladar el trabajo al momento en que el sistema ya está en uso.
En el caso publicado de CitaPlus se puede ver cómo reserva, seña y recordatorio forman un recorrido conectado. Sirve para entender qué significa delimitar un flujo; no usamos ese caso como prueba de una duración, porque no publicamos un cronograma verificable del proyecto.
Nota editorial
La referencia de tres semanas corresponde a la planificación comercial de una primera versión en Altura; no es un promedio de la industria ni un plazo histórico atribuido a nuestros casos. Las fuentes externas respaldan conceptos de desarrollo y estimación. El alcance y la fecha se confirman en la propuesta. Nuevas funciones, migraciones extensas o dependencias externas se evalúan por separado.
Siguiente paso