Cómo funciona el desarrollo de software — de la idea al producto en vivo

Iniciar un proyecto de software para muchos clientes es como una caja negra. Sabe lo que quiere —una plataforma, una app, un sistema interno— pero no sabe exactamente cómo pasar de esa idea a un producto funcionando. Y qué debe ocurrir en medio.

Lo que sigue es un recorrido honesto por todo el proceso: qué ocurre en cada fase, cuánto tiempo lleva, qué debe aportar usted como cliente, y de dónde vienen la mayoría de las sorpresas.

Fase 1: Discovery y requisitos (2–4 semanas)

Antes de que se escriba una sola línea de código, debe quedar claro qué hay que construir exactamente —y por qué. Esto suena obvio, pero la mayoría de los proyectos que salen mal ya fallan aquí.

En la fase de discovery, la agencia investiga su contexto de negocio, sus usuarios, el entorno técnico (sistemas existentes, integraciones, estructuras de datos) y el alcance real del proyecto. El resultado es una especificación detallada: quiénes son los usuarios, qué flujos siguen, qué decisiones deben poder tomar en el sistema, y cómo es la arquitectura técnica.

Lo que usted hace en esta fase: estar disponible. Entrevistas con usted y sus miembros del equipo, a veces también con clientes o usuarios finales. Aportar documentos sobre su situación actual. Dar feedback sobre los alcances conceptuales. Esta no es una fase pasiva para el cliente.

Lo que obtiene de ella: una especificación que también sirve de base para el presupuesto. Las agencias que se saltan esta fase dan estimaciones basadas en suposiciones —y esas casi nunca se cumplen.

Fase 2: Diseño y UX (2–4 semanas, a veces en paralelo con el desarrollo)

Una vez que los requisitos están claros, el producto se diseña visualmente. Esto va más allá de colores y logos: una buena fase de UX determina cómo se mueven los usuarios por el sistema, qué información ven en qué momento, y cómo la interfaz hace comprensible la funcionalidad compleja.

En la práctica, un diseñador entrega wireframes —versiones esquemáticas de cada página o pantalla— y luego prototipos visuales. Herramientas modernas como Figma permiten hacer clic en un prototipo como si ya funcionara, mucho antes de que un desarrollador haya intervenido.

Lo que usted hace en esta fase: dar feedback sobre wireframes y prototipos. Este es el momento para decir lo que no entiende, lo que no encaja o lo que falta. Eso es gratis ahora; si hay que ajustarlo en la fase de construcción, cuesta tiempo y dinero.

Error frecuente: los clientes miran en esta fase el estilo visual en lugar de la lógica. "Los colores son bonitos" no dice nada sobre si el sistema funciona lógicamente. Céntrese en los flujos.

Fase 3: Desarrollo (8–24 semanas según el alcance)

La fase de construcción es la más larga, y para la mayoría de los clientes la más opaca. Los desarrolladores trabajan en el frontend (lo que ve el usuario), el backend (la lógica y los datos detrás) y las integraciones (conexiones con otros sistemas).

En un enfoque ágil —hoy en día el estándar en las agencias serias— los desarrolladores trabajan en sprints de una o dos semanas. Al final de cada sprint usted ve software funcionando. No un informe o una presentación: funcionalidad real y clicable.

Lo que usted hace en esta fase: asistir a las sprint reviews, responder preguntas cuando algo no está claro, y establecer prioridades cuando el alcance está bajo presión. No necesita conocimientos técnicos, pero sí debe estar disponible. Un cliente que no responde durante dos semanas bloquea a un equipo de cuatro desarrolladores.

Con lo que se encuentran los equipos: complejidad técnica imprevista (una integración que funciona diferente a lo documentado, una estructura de datos que requiere ajuste), ampliación del alcance que no cabe en la planificación original, y dependencias de terceros (proveedores de pago, APIs gubernamentales) que causan retrasos.

Fase 4: Pruebas y control de calidad (2–4 semanas)

Las pruebas no son una fase que se añade al final; empiezan con el primer sprint. Pero antes de que el software salga en vivo, llega un período de pruebas más intensivo.

Las agencias profesionales trabajan con pruebas automatizadas (código que prueba otro código), pruebas de aceptación manuales (un tester recorre todos los escenarios) y pruebas de usuario (usuarios reales o testers internos que prueban el producto). Los bugs se registran, se priorizan y se resuelven.

Lo que usted hace en esta fase: realizar pruebas de aceptación de usuario (UAT). Usted y su equipo prueban el sistema desde su propia realidad —con datos reales, en escenarios reales. Ustedes conocen los casos extremos que un tester externo nunca pensará.

Expectativa realista: siempre hay bugs. La pregunta no es si se encuentran bugs, sino qué tan rápido se resuelven y qué tan graves son. Un sistema nunca está cien por cien libre de errores; se trata de que los caminos críticos funcionen y el resto se priorice.

Fase 5: Despliegue y lanzamiento (1–2 semanas)

El software sale en vivo. Esto suena simple, pero hay varios pasos: configurar el entorno de producción, migrar datos (si hay datos legacy que trasladar), cargar gradualmente el sistema y monitorear si todo se mantiene estable.

Las buenas agencias hacen un "soft launch" o "staged rollout": el sistema sale en vivo para un pequeño grupo de usuarios antes de que la población más amplia pueda acceder. Así se detectan los problemas a escala pronto.

Lo que usted hace en esta fase: gestionar la comunicación hacia sus usuarios o empleados, poner a disposición formación o documentación, y estar presente cuando aparecen preguntas o problemas inmediatamente después del lanzamiento.

Error frecuente: los clientes esperan que el lanzamiento sea el punto final. No lo es. Las primeras semanas después del lanzamiento son intensivas: los usuarios descubren cosas que los testers nunca probaron, el pico de carga revela cuellos de botella, y el feedback fluye.

Fase 6: Mantenimiento y desarrollo continuo (ongoing)

El software no es un producto que se compra y se olvida. Necesita mantenimiento: actualizaciones de seguridad, actualizaciones de bibliotecas y frameworks, monitorización de disponibilidad y rendimiento, y ajustes cuando el negocio cambia.

Las buenas agencias ofrecen un contrato de mantenimiento o un acuerdo de retainer: una cantidad mensual fija para la gestión y una capacidad acordada para el desarrollo continuo. Esto evita tener que volver a presupuestar para cada pequeño ajuste.

Las tres preguntas que debe hacer de antemano:

¿Quién es propietario del código y la infraestructura?

¿Cuáles son los costes si quiere ampliar o cambiar de proveedor más adelante?

¿Cómo gestiona la agencia las vulnerabilidades de seguridad que se descubren a posteriori?

Plazos y presupuesto: expectativas realistas

Un proceso típico para un proyecto de software de mediana envergadura (una aplicación web con cuentas de usuario, gestión de datos y algunas integraciones) dura cuatro a ocho meses desde la primera conversación hasta el lanzamiento, y cuesta €60.000–€200.000 dependiendo del alcance.

Las apps sencillas o las herramientas internas son más rápidas y baratas. Las plataformas complejas con múltiples grupos de usuarios, funcionalidad en tiempo real y muchas integraciones llevan más tiempo y cuestan más.

Lo que los clientes a menudo no esperan: la inversión interna de tiempo de su propio equipo. De media, un cliente dedica dos a cuatro horas semanales activamente a un proyecto en curso —feedback, decisiones, contenido, datos de prueba. Calcúlelo.

Las tres sorpresas que casi todos los clientes primerizos encuentran

El alcance siempre crece. A medida que el producto se vuelve más concreto, se le ocurren más cosas que también quiere. Ágil hace esto manejable —se añade al backlog y se determina la prioridad— pero tiene implicaciones presupuestarias.

Las integraciones son impredecibles. Las conexiones con sistemas externos (proveedores de pago, software de contabilidad, sistemas gubernamentales) son a veces técnicamente más complejas de lo esperado. La documentación está desactualizada, las APIs se comportan diferente a lo descrito, o hay que construir soluciones intermedias.

Los usuarios lo usan diferente a lo esperado. Por mucho cuidado que haya puesto en la UX, los usuarios reales hacen cosas que nadie había previsto. Planifique presupuesto después del lanzamiento para una primera ronda de ajustes basados en el uso.

Un proyecto de software es una colaboración, no un pedido. Las agencias que mejores resultados entregan tratan al cliente como partner en el proceso —no como alguien que presenta una especificación y recoge un producto tres meses después. Y los clientes que mejores resultados logran entienden que su implicación es uno de los factores de éxito más importantes.