Cómo se desarrolla un software a la medida: etapas y tiempos

Un software a la medida se desarrolla en etapas: descubrimiento del negocio, requerimientos e historias de usuario, prototipo UX/UI, arquitectura, desarrollo por sprints con pruebas automatizadas, despliegue con CI/CD, capacitación y soporte. Un sistema pequeño puede estar en producción en 6 a 10 semanas, uno mediano en 3 a 6 meses y un ERP con integraciones en 6 a 12 meses o más, normalmente liberado por fases. Lo que más alarga un proyecto no es programar, sino decidir tarde o validar poco.

Este artículo explica qué ocurre en cada etapa, qué te toca preparar como cliente y qué deberías recibir al final. Es la guía que nos habría gustado darle a muchos clientes que llegaron después de una mala experiencia con otro proveedor.

¿Qué etapas tiene el desarrollo de un software a la medida?

Etapa	Qué se hace	Entregable principal	Tu participación
1. Descubrimiento	Entender el negocio, el problema y las restricciones	Documento de alcance y prioridades	Alta
2. Requerimientos	Historias de usuario y criterios de aceptación	Backlog priorizado	Alta
3. UX/UI y prototipo	Flujos y pantallas navegables	Prototipo validado	Alta
4. Arquitectura	Stack, modelo de datos, integraciones, seguridad	Documento técnico y plan de entregas	Baja
5. Desarrollo por sprints	Construir y probar en ciclos cortos	Incrementos funcionales en ambiente de pruebas	Media
6. QA y pruebas	Pruebas automatizadas, manuales y de aceptación	Reporte de pruebas y aprobación	Media
7. Despliegue	Puesta en producción con CI/CD y migración de datos	Sistema en producción	Media
8. Capacitación	Formación por rol y materiales de apoyo	Usuarios operando	Alta
9. Soporte y evolución	Corrección, monitoreo, mejoras	Póliza de soporte y roadmap	Media

Las etapas 5 y 6 no ocurren una tras otra: se repiten en cada sprint. Y en proyectos medianos o grandes, las etapas 2 a 8 se repiten por fase.

1. Descubrimiento: entender antes de cotizar en firme

El descubrimiento es una serie de sesiones para entender cómo opera tu negocio hoy, qué duele, qué se quiere lograr y qué restricciones existen (presupuesto, fechas fiscales, temporadas altas, sistemas que no se pueden tocar). Se revisan documentos reales: facturas, órdenes de compra, reportes en Excel, capturas del sistema actual.

El resultado es un alcance escrito y priorizado. La pregunta clave en esta etapa no es “qué quieres que haga el sistema”, sino “qué decisión o tarea quieres que deje de costarte tiempo o dinero”. De ahí sale el producto mínimo viable: la primera versión útil, no la versión con todo.

2. Requerimientos e historias de usuario

Los requerimientos se escriben como historias de usuario: frases cortas con el formato “como [rol], quiero [acción] para [beneficio]”. Por ejemplo: “Como vendedor, quiero ver el saldo vencido del cliente al cotizar, para no ofrecer crédito a quien ya debe”.

Cada historia lleva criterios de aceptación, que son las condiciones verificables para darla por terminada: qué pasa si el saldo es cero, qué pasa si el cliente no tiene crédito, quién puede autorizar una excepción. Estos criterios son la base de las pruebas posteriores y evitan la discusión de “eso no es lo que pedí”.

3. Diseño UX/UI y prototipo navegable

Antes de programar se diseña un prototipo navegable: pantallas que se pueden recorrer como si fueran el sistema real, aunque no guarden datos. Tus usuarios lo prueban y opinan. Cambiar una pantalla en el prototipo toma minutos; cambiarla cuando ya está programada y conectada a la base de datos toma días.

En esta etapa se define también cómo se verá en celular, si habrá una app nativa para iOS y Android o basta con una aplicación web adaptable. Si el proyecto incluye app, revisa nuestro servicio de desarrollo de apps iOS y Android.

4. Arquitectura: las decisiones que no se ven pero se pagan

La arquitectura define cómo está construido el sistema por dentro: lenguaje y framework, base de datos, cómo se organizan los módulos, cómo se conecta con otros sistemas, cómo se autentica a los usuarios y dónde se aloja. Son decisiones que el usuario no ve, pero que determinan cuánto costará mantener y crecer el sistema.

Algunos criterios que aplicamos:

• Tecnología mantenible, no la más nueva. Un stack con comunidad amplia y talento disponible en México, como Laravel, .NET, Node.js o Python con PostgreSQL o SQL Server. Explicamos cómo elegir en stack tecnológico para desarrollo de software.
• Monolito modular antes que microservicios para la mayoría de las empresas medianas: más simple de operar y suficiente para crecer bastante.
• API desde el inicio, para que después puedas conectar tienda, CRM, bancos o el SAT. Lo detallamos en integración de sistemas por API.
• Seguridad por diseño: roles y permisos, cifrado en tránsito, bitácora de cambios, secretos fuera del código.
• Ambientes separados de desarrollo, pruebas y producción.

5. Desarrollo por sprints

El desarrollo se organiza en sprints, ciclos de una a dos semanas. Al inicio de cada sprint se eligen las historias de mayor prioridad; al final se presenta funcionalidad terminada en el ambiente de pruebas para que tú la revises.

Lo que hace que este esquema funcione:

• Demostraciones frecuentes: ves avances reales, no porcentajes en un reporte.
• Prioridades ajustables: si a mitad del proyecto cambia algo en el negocio, se reordena el backlog sin rehacer todo.
• Revisión de código entre ingenieros antes de integrar cada cambio.
• Control de versiones en un repositorio Git con historial completo de quién cambió qué y por qué.

6. QA y pruebas automatizadas

La calidad no se agrega al final; se construye en cada sprint. Un proyecto serio combina varios tipos de prueba:

• Pruebas unitarias: verifican reglas de negocio aisladas, como el cálculo de un descuento o un impuesto.
• Pruebas de integración: verifican que los módulos y servicios externos (PAC, pasarelas de pago, paqueterías) respondan como se espera, incluidos los errores.
• Pruebas de extremo a extremo: simulan a un usuario recorriendo un flujo completo, desde capturar un pedido hasta facturarlo.
• Pruebas de aceptación: las hace tu equipo con casos reales, contra los criterios de aceptación de cada historia.
• Revisión de seguridad y rendimiento antes de salir a producción.

Las pruebas automatizadas se ejecutan solas en cada cambio. Su valor real aparece meses después, cuando alguien modifica una regla y la prueba avisa que rompió otra cosa antes de que llegue a tus usuarios.

7. CI/CD y despliegue

CI/CD (integración y entrega continuas) es el proceso automático que, cada vez que se aprueba un cambio, compila el sistema, ejecuta las pruebas y lo publica en el ambiente correspondiente. Elimina el clásico “en mi computadora sí funcionaba” y hace que publicar una corrección sea rutina, no un evento riesgoso.

El despliegue a producción incluye infraestructura en la nube (AWS, Google Cloud o Azure, entre otras), respaldos automáticos, certificados, monitoreo de errores y, si existe un sistema previo, la migración de datos con conciliación. Si vienes de un sistema antiguo, revisa cómo modernizar un sistema legado sin detener tu operación.

8. Capacitación

Un sistema que nadie usa bien no sirve. La capacitación se da por rol: el almacenista no necesita aprender los reportes de dirección. Se complementa con manuales breves, videos cortos de los flujos principales y un periodo de acompañamiento en los primeros días de operación.

9. Soporte y evolución

Después del lanzamiento empieza la vida real del sistema: errores que solo aparecen con datos reales, ajustes de uso, actualizaciones de seguridad, cambios fiscales y nuevas funciones. Lo recomendable es una póliza de soporte con tiempos de respuesta por severidad y un canal claro para reportar incidencias.

¿Cuánto tarda según el tamaño del proyecto?

Tamaño	Ejemplos	Tiempo orientativo	Cómo se suele entregar
Pequeño	Portal de clientes, módulo de cotizaciones, sistema interno de un proceso	6 a 10 semanas	Una sola entrega
Mediano	Sistema administrativo con varios módulos, app móvil con panel web	3 a 6 meses	2 o 3 entregas
Grande	ERP a la medida, plataforma con múltiples integraciones y apps	6 a 12 meses o más	Por fases y módulos

Estos tiempos son rangos orientativos. Los factores que más los mueven son el número de integraciones, la calidad de los datos a migrar y la velocidad con la que se toman decisiones del lado del cliente. Para costos, consulta cuánto cuesta un software a la medida.

¿Qué debe preparar el cliente?

Tu participación es lo que más influye en el resultado. Antes de arrancar conviene tener:

1. Un responsable del proyecto con autoridad para decidir y tiempo para validar, idealmente unas horas por semana.
2. Usuarios clave de cada área que conozcan el proceso real, no solo el ideal.
3. Ejemplos reales: documentos, reportes, archivos de Excel, capturas del sistema actual, casos especiales.
4. Acceso a la información que se migrará y a los sistemas con los que habrá integración (credenciales de prueba, documentación de APIs, contacto con proveedores).
5. Datos fiscales y cuentas a nombre de la empresa: dominio, nube, PAC, pasarelas de pago, cuentas de desarrollador de Apple y Google si hay app.
6. Disponibilidad en las demostraciones de cada sprint.

¿Qué entregables debes recibir al final?

Este es el punto que más se descuida al contratar. Al cerrar el proyecto deberías tener:

• Código fuente completo en un repositorio a nombre de tu empresa, con historial de cambios.
• Documentación técnica: arquitectura, modelo de datos, cómo instalar y desplegar, variables de configuración.
• Documentación funcional: manuales de usuario por rol.
• Accesos y credenciales de servidores, nube, base de datos, dominio y servicios de terceros, bajo cuentas de tu propiedad.
• Pipeline de CI/CD y pruebas automatizadas funcionando.
• Propiedad intelectual por escrito: cesión de derechos patrimoniales sobre el código desarrollado específicamente para ti, establecida en el contrato.

Si un proveedor no puede comprometerse a esto, estás comprando dependencia, no software.

Cómo te ayuda Tecsolt

En Tecsolt desarrollamos software a la medida desde junio de 2017, con más de 100 proyectos finalizados para empresas de todo México, y seguimos este proceso con consultoría, prototipo, desarrollo por entregas cortas, pruebas y lanzamiento con soporte. Trabajamos con demostraciones frecuentes, repositorio, pruebas automatizadas y CI/CD desde el inicio, y el código, la documentación y los accesos quedan a nombre de tu empresa. Un ejemplo es LAPCIC Análisis Clínicos, donde un sistema a la medida y un chatbot redujeron 70% el tiempo de respuesta a sus clientes. Conoce nuestro servicio de software y ERP a la medida o agenda una reunión para revisar tu proyecto.

Preguntas frecuentes

¿Cuánto tiempo tarda en desarrollarse un software a la medida?

Como referencia, un sistema pequeño con pocos módulos puede estar listo en 6 a 10 semanas, uno mediano en 3 a 6 meses y un ERP o plataforma con varias integraciones en 6 a 12 meses o más, normalmente en fases. El tiempo real depende del alcance, las integraciones y la rapidez con la que el cliente valida avances.

¿Cuáles son las etapas del desarrollo de software?

Las etapas habituales son descubrimiento, definición de requerimientos e historias de usuario, diseño UX/UI con prototipo, arquitectura, desarrollo por sprints, pruebas y QA, despliegue, capacitación y soporte. En un proyecto ágil varias de estas etapas se repiten en ciclos cortos en lugar de ocurrir una sola vez.

¿Qué necesito tener listo antes de contratar el desarrollo de un software?

Conviene tener claro el problema que quieres resolver, quién usará el sistema, ejemplos reales de tus documentos y reportes, y una persona de tu empresa con autoridad para tomar decisiones y validar avances. No necesitas un documento técnico; eso se construye en la etapa de descubrimiento.

¿El código fuente de un software a la medida es mío?

Debería serlo, y conviene dejarlo por escrito en el contrato. Lo recomendable es que el repositorio, los accesos a la infraestructura, los dominios y las cuentas de servicios queden a nombre de tu empresa, junto con la cesión de derechos patrimoniales sobre el código desarrollado para ti.

¿Qué es un sprint en desarrollo de software?

Un sprint es un ciclo corto de trabajo, normalmente de una a dos semanas, al final del cual el equipo entrega funcionalidad terminada y probada que el cliente puede revisar. Permite detectar malentendidos pronto y ajustar prioridades sin esperar al final del proyecto.

¿Qué pasa después de entregar el software?

Empieza la etapa de soporte y evolución: corrección de errores, actualizaciones de seguridad, monitoreo, respaldos y nuevas funciones según las necesidades del negocio. Lo habitual es acordar una póliza de soporte con tiempos de respuesta definidos y un canal claro para reportar incidencias.

• #software a la medida
• #proceso de desarrollo
• #metodología ágil
• #pruebas automatizadas
• #ci/cd