Desarrollo de software a medida: el proceso paso a paso, del análisis a producción

El desarrollo de software a medida se hace en seis fases encadenadas: análisis funcional, arquitectura y modelo de datos, desarrollo por sprints con demos, pruebas, puesta en producción y traspaso con documentación. Cada una existe por una razón concreta, y saltarse cualquiera es la forma más habitual de que un proyecto salga caro, tarde o roto. Aquí te cuento el proceso entero, paso a paso, para que sepas qué pasa desde que me escribes hasta que el sistema está funcionando en producción y es tuyo del todo.

No es un método que me haya inventado para el marketing. Es lo que hago en cada proyecto porque es lo que separa una entrega que aguanta cinco años de un parche que se cae al primer cambio. Llevo más de veinte años escribiendo código y trabajo solo, así que hablas conmigo en todas las fases: no hay un comercial que promete y un junior que ejecuta lo que puede.

Fase 1: análisis funcional, y por qué no te lo cobro

Antes de escribir una línea de código, hay que entender qué tiene que hacer el software y por qué. El análisis funcional es esa fase: sentarnos, mirar tu proceso real, identificar dónde está la lógica de negocio que te da o te cuesta dinero, y traducirlo a requisitos concretos. Qué entra, qué sale, qué reglas hay por medio, qué casos raros existen aunque pasen una vez al mes.

Esta parte no te la cobro, y no es un gancho. Es que sin ella no puedo darte un presupuesto honesto. Un precio dado sin analizar el problema es un número inventado que luego se corrige al alza con "esto no estaba contemplado". Prefiero invertir esas horas en entender el alcance de verdad y darte una cifra que se sostenga.

Del análisis salen tres cosas:

• Un alcance escrito. Qué se hace y, tan importante como eso, qué no se hace en esta fase. El scope claro es lo que evita el goteo de "ya que estamos".
• Los criterios de aceptación. Cómo sabremos que cada parte funciona. No "que quede bien", sino condiciones comprobables.
• Un presupuesto por rangos. Con el alcance medido puedo darte una horquilla realista. El detalle de cómo calculo precios y los rangos orientativos está en tarifas.

Si te saltas esta fase, todo lo que viene después se construye sobre suposiciones. Y las suposiciones se pagan al final, cuando cambiarlas cuesta diez veces más.

Fase 2: arquitectura y modelo de datos

Con el qué claro, toca decidir el cómo. La arquitectura es la estructura del sistema: cómo se separan las partes, dónde vive la lógica de negocio, cómo se comunican los módulos, qué stack encaja mejor con tu caso. Trabajo con criterio senior aquí, arquitectura hexagonal y separación de responsabilidades cuando el proyecto lo pide, porque una estructura limpia es lo que hace que un cambio dentro de dos años sea una tarde de trabajo y no una reescritura.

El modelo de datos es la otra mitad de esta fase, y suele ser la más determinante. Cómo se guardan las cosas, qué relaciones hay, qué restricciones garantizan que el dato nunca quede en un estado imposible. Un modelo de datos mal pensado es una herida que sangra durante toda la vida del proyecto: cada consulta se complica, cada funcionalidad nueva pelea contra la estructura, y arreglarlo más tarde implica migraciones delicadas con datos ya en producción.

Aquí también elijo el stack. Trabajo principalmente con Laravel, Node y Python, y la elección depende del problema, no de la moda. Si te interesa el detalle de con qué construyo cada área, lo tienes en conocimientos. Lo importante es que esta decisión se toma con la cabeza fría al principio, no improvisando a mitad de camino.

Fase 3: desarrollo por sprints, con demos que ves

El desarrollo no es una caja negra de la que sales de vez en cuando con noticias. Trabajo por sprints, bloques cortos de trabajo con un objetivo cerrado cada uno, y al final de cada bloque ves funcionando lo que se ha construido. No un informe de que va bien: la cosa real, ejecutándose, para que la toques.

Esto cambia el proyecto por completo, y en tu favor:

• Detectas desviaciones pronto. Si algo no es lo que tenías en la cabeza, se corrige en el sprint siguiente, cuando todavía es barato, no al final cuando ya está todo montado encima.
• Ves avance real. Sabes en cada momento por dónde va el dinero y el tiempo. Nada de esperar tres meses a ciegas.
• Priorizamos juntos. Si a mitad de camino resulta que una parte importa más que otra, se reordena. El plan es una guía, no una cárcel.

Cada funcionalidad con lógica se acompaña de tests automáticos durante el propio desarrollo, no como un añadido posterior. El test es lo que me deja tocar código con la seguridad de que no rompo lo que ya funcionaba. Puedes ver el proceso completo, explicado desde tu lado, en cómo trabajo un proyecto.

Fase 4: pruebas

Cuando la funcionalidad está, empieza la fase de pruebas en serio. No es solo comprobar que lo normal funciona; es buscar activamente dónde se rompe. Los casos límite, los datos mal formados, el usuario que hace las cosas en el orden que no esperabas, la integración externa que un día responde tarde o no responde.

Esta fase cubre varios frentes a la vez:

• Funcional: cada criterio de aceptación de la fase 1 se verifica uno a uno. Lo que dijimos que haría, lo hace.
• Seguridad: reviso los puntos que importan, validación de todo lo que entra, control de acceso, que ningún dato sensible se filtre, protección ante abuso. La seguridad no es una capa que se pinta al final, se verifica sobre lo construido.
• Rendimiento: si el sistema va a mover volumen, se comprueba que aguanta antes de abrirlo, no cuando ya hay usuarios sufriendo.

Saltarse las pruebas es la tentación clásica cuando el plazo aprieta. Es también la decisión que convierte un lanzamiento en una semana de apagar fuegos. Un fallo encontrado aquí cuesta una tarde; el mismo fallo encontrado por tu cliente en producción cuesta eso más tu reputación.

Fase 5: puesta en producción

Aquí es donde muchos proyectos a medida se quedan a medias, y por eso lo trato como una fase con entidad propia. Poner en producción no es "subir los archivos". Es dejar el sistema funcionando en un entorno real, estable y preparado para que le pase la vida.

Lo que implica una puesta en producción hecha con cabeza:

• Entorno configurado con sus variables, sus secretos fuera del código, sus copias de seguridad.
• Despliegue controlado, idealmente automatizado, para que futuras actualizaciones no sean una operación a corazón abierto.
• Migración de datos si vienes de un sistema anterior, con las redirecciones y la continuidad que hagan falta para no perder por el camino lo que ya tenías.
• Verificación en caliente: compruebo que funciona en el entorno real, no solo que funcionaba en mi máquina.

Entregar a producción es parte del trabajo, no un extra. El desarrollo de software a medida que no llega a producción es un prototipo caro, y un prototipo no te resuelve nada.

Fase 6: traspaso con documentación

El proyecto no termina cuando funciona; termina cuando es tuyo de verdad y no dependes de mí para respirar. La última fase es el traspaso: te entrego el código, la documentación de cómo está montado, cómo se despliega, cómo se toca lo que se pueda tocar, y las claves de todo. Sin ataduras artificiales.

Esto es lo contrario de la trampa habitual, la del proveedor que se guarda el conocimiento para que no puedas irte. A mí me interesa lo opuesto: que puedas mantenerlo con quien quieras, incluido tu equipo interno, y que si vuelves a llamarme sea porque quieres, no porque estás atrapado. Un sistema bien documentado y bien estructurado se lee, y eso es lo que te da libertad.

Si trabajas en una agencia, esta misma fase encaja en el modelo de marca blanca: entrego el proyecto documentado para que lo presentes como tuyo. El detalle de cómo funciona esa colaboración lo tienes en desarrollo web en marca blanca para agencias.

Por qué el orden importa

Cada fase alimenta a la siguiente. El análisis define la arquitectura; la arquitectura hace posible un desarrollo limpio; el desarrollo por sprints hace baratas las correcciones; las pruebas protegen la puesta en producción; la producción bien hecha hace posible un traspaso limpio. Rompe un eslabón y el coste no desaparece, se traslada al final, multiplicado.

Si quieres ver el resultado de este proceso en proyectos reales, con su alcance medido y sin adornos, lo tienes en el portfolio. Y si tienes un problema concreto que resolver, escríbeme y empezamos por la primera fase, el análisis, que es gratis precisamente porque es la que decide si el resto merece la pena. En contacto te cuento con criterio de qué lado estás y qué haría yo en tu caso.