Aprender a crear aplicaciones: la ruta real del PRD a producción

Si buscas aprender a crear aplicaciones, vas a encontrar mil tutoriales de cómo montar una pantalla de login y casi ninguno de lo que realmente separa una demo de un sistema que una empresa usa cada mañana. Este artículo es esa parte que falta: la ruta completa, en el orden en que se recorre, con lo que hay que producir en cada paso.

Sirve tanto si quieres construirlo tú como si vas a contratarlo y quieres saber qué exigir.

El error de empezar por el código

La tentación es abrir el editor y empezar. Es el camino más corto a reescribirlo todo dos meses después. Las aplicaciones no fracasan por elegir mal el framework: fracasan porque resuelven un problema que nadie tenía, o porque el alcance creció hasta hacerse infinito.

El orden que funciona es este: entender → definir → diseñar → construir → desplegar. Cada fase produce un artefacto concreto. Si una fase no produce nada que se pueda leer, no se ha hecho.

Paso 1 — Mapa de procesos: entender antes de definir

Antes de decidir qué construir, hay que ver cómo funciona hoy. No cómo debería funcionar según el organigrama: cómo funciona de verdad.

Qué hacer: sentarte con quien ejecuta la tarea y recorrerla paso a paso. Preguntar quién toca qué, cuántas veces al día, cuánto tarda y dónde se atasca. Cronometrar, no estimar.

Qué produce: un mapa conceptual del proceso actual con tiempos reales, y un número: las horas al mes que se pueden recuperar. Ese número decide si el proyecto sigue.

Error típico: preguntar solo a la dirección. Quien describe el proceso desde arriba omite justo los apaños que consumen el tiempo.

Paso 2 — PRD: definir qué se construye y qué no

El PRD (Product Requirements Document) es el documento donde se cierra el alcance. Es el artefacto más barato de escribir y el que más dinero ahorra.

Debe contener:

• Problema. Qué duele, con números.
• Usuario objetivo. Quién lo va a usar y en qué contexto (¿de pie, en una obra, sin cobertura?).
• Historias de usuario. “Como técnico, cierro el parte desde el móvil con la firma del cliente.”
• Criterios de aceptación. Comprobables: o se cumplen o no. “El parte se guarda sin conexión y se sincroniza al recuperarla” es un criterio; “la app debe ser rápida” no lo es.
• Prioridades. P0 son las que si faltan no hay producto. P1 y P2 son deseables.
• Fuera de alcance. La sección más importante y la que casi nadie escribe. Lista explícita de lo que no entra en la versión 1.

Sin esa última sección, cualquier proyecto de ocho semanas acaba en ocho meses.

Paso 3 — Arquitectura: la decisión que se paga durante años

Aquí se define cómo encajan las piezas. Es donde se separa escalar de reescribir.

Modelo de datos. Las entidades reales del negocio y sus relaciones. Si el modelo no refleja cómo piensa la empresa, cada función nueva será una pelea.

Capas. Canales de entrada (web, portal, WhatsApp), núcleo de producto (interfaz, API, reglas, permisos), automatización (colas, trabajos en segundo plano, IA) y datos e integraciones (base de datos, archivos, ERP, pasarela de pago).

Qué pasa cuando falla. Esta es la pregunta que distingue a un sistema profesional. ¿Cuántos reintentos? ¿Quién recibe la alerta? ¿Dónde queda el caso que no se pudo procesar? Una automatización sin plan de fallo es una bomba de relojería.

Elección de stack. Aburrida y a propósito. Para aplicaciones de negocio: TypeScript, un framework establecido, PostgreSQL y un proveedor de despliegue gestionado cubren el 95% de los casos. La tecnología novedosa se paga en mantenimiento.

Paso 4 — Construcción por sprints: entregar cada semana

La regla es simple: desde la semana 2 o 3 tiene que existir un entorno real donde el cliente pueda entrar y probar. No capturas, no vídeos: acceso.

Esto cambia el proyecto por completo. Los malentendidos aparecen en la semana 3, cuando corregirlos cuesta horas, en lugar de en la semana 12, cuando cuestan semanas.

Qué debe haber desde el principio:

• Control de versiones y despliegue automático. Cada cambio llega solo a un entorno de pruebas.
• Datos realistas. Probar con “Cliente 1, Cliente 2” oculta la mitad de los problemas.
• Pruebas donde duele. No hace falta cubrirlo todo: cubre los cálculos, los permisos y las integraciones.

Paso 5 — Producción: el proyecto no acaba al desplegar

Lanzar es el principio. Lo que hace falta el día del despliegue:

• Monitorización y alertas. Debes enterarte de un fallo antes que el cliente.
• Registro de errores con contexto. Saber qué usuario, con qué datos y en qué punto.
• Copias de seguridad probadas. Una copia que nunca se ha restaurado no es una copia.
• Formación del equipo. Media hora bien dada evita meses de resistencia al cambio.
• Medición del ahorro. Volver al número del paso 1 y comprobarlo. Es lo que justifica la siguiente fase.

Cuánto se tarda de verdad

Plazos realistas para alguien que ya sabe lo que hace:

Tipo	Plazo
Automatización acotada	2-3 semanas
Aplicación interna completa	6-12 semanas
Micro-SaaS con suscripción	10-16 semanas

Si estás aprendiendo, multiplica por tres y no te frustres: la primera aplicación real enseña más que veinte tutoriales.

Si quieres aprender construyendo

Un consejo que doy siempre: no empieces por una idea genial. Empieza por un proceso aburrido que conozcas bien —el control de un almacén, los partes de un taller, las reservas de una clínica— y recórrelo entero, incluidos el despliegue y el mantenimiento. Terminar algo pequeño y real enseña infinitamente más que dejar a medias algo ambicioso.

Y hazlo en este orden: mapa, PRD, arquitectura, construcción, producción. No porque sea bonito, sino porque cada paso evita un error caro del siguiente.

En proyectos puedes ver estos artefactos aplicados a casos concretos, y en SaaS a medida para empresas tienes el marco para decidir si un proyecto merece la pena antes de empezarlo.