Saltar al contenido
Condictor Studio
Aplicaciones
Aplicaciones

Cómo crear una aplicación desde cero, etapa por etapa

Siete etapas desde la idea a una aplicación en producción: discovery, alcance, arquitectura, desarrollo, despliegue y mantenimiento. Con plazos orientativos.

Aprox. 6 min de lecturapor
Una tarjeta de concepto vacía, un marco metálico y una secuencia de módulos negros conectados por un cable verde menta conducen a un objeto terminado

El desarrollo de una aplicación puede dividirse en siete áreas: discovery, alcance, diseño y arquitectura, construcción iterativa, pruebas, despliegue y mantenimiento. No siempre transcurren de forma lineal, pero omitir el objetivo, los límites del alcance y los criterios de aceptación aumenta el riesgo de cambios costosos durante el desarrollo.

Este artículo describe el orden que aplicamos, junto con duraciones orientativas de las etapas y los riesgos de omitirlas.

Etapa 1. Discovery: para qué y para quién

Objetivo: establecer qué problema resolvemos y quién va a usarlo. No «qué funciones queremos», sino «qué resultado debe producirse».

Entregables: lista de objetivos de negocio, descripción de los usuarios y sus tareas, limitaciones (legales, de integración y de presupuesto) y un mapa del proceso en su versión actual y deseada.

Duración: desde un taller hasta dos semanas, según la complejidad.

Riesgo de omitirla: el equipo puede construir funciones que no resuelven la tarea principal de la persona usuaria y descubrir la discrepancia solo en la aceptación o tras el despliegue. Si los supuestos no están claros, empieza por el diseño y la planificación.

Etapa 2. Alcance: qué entra en la primera versión y qué no

Objetivo: separar «debe estar para que funcione» de «sería deseable». Sin esta distinción, la primera versión crece fácilmente y el coste puede superar el presupuesto disponible antes de cerrar el recorrido esencial.

Entregables: alcance de la primera versión con una justificación para cada elemento, lista de aspectos aplazados deliberadamente y criterios de «hecho».

Duración: varios días, aunque requiere decisiones, y las decisiones suelen ser el cuello de botella.

Riesgo de omitirla: un proyecto sin límite de alcance puede crecer hasta agotar el tiempo o el presupuesto. En lugar de una versión funcional y acotada queda un conjunto de funciones sin terminar. Describimos el alcance de un producto de entrada en la oferta MVP en 4–6 semanas.

Etapa 3. Diseño y arquitectura

Dos aspectos en paralelo:

  • Diseño de interfaz: pantallas y flujos. La capa visual debe ayudar a comprender, establecer jerarquías y realizar la tarea; no es solo decoración.
  • Arquitectura: modelo de datos, límites del sistema, integraciones, método de autenticación y plan de despliegue. Cambiar relaciones fundamentales una vez acumulados los datos suele exigir una migración y es más arriesgado que corregir una única pantalla.

Duración: 1–3 semanas.

Riesgo de omitirla: añadir funciones puede exigir atajos, migraciones de datos y cambios en muchos lugares dependientes. No toda corrección lleva a reescribir el sistema, pero la ausencia de límites explícitos de arquitectura eleva el coste y el riesgo de los cambios posteriores.

Etapa 4. Construcción: de forma iterativa, no «hasta que esté listo»

Objetivo: obtener lo antes posible una versión funcional, aunque sea limitada, capaz de comprobar el supuesto clave, y ampliarla después según el resultado.

Cómo lo hacemos: llevamos el proyecto por el flujo discovery → brief → plan → implementación → verificación, y escribimos código con asistentes de IA (Claude Code, Codex) dentro de un flujo de trabajo dedicado, con revisión cruzada y pruebas. La IA acelera parte de las tareas, pero el resultado sigue pasando por revisión, pruebas y aceptación según los criterios acordados. Consulta el proceso y la descripción técnica de cómo trabajamos con asistentes de IA.

Adaptamos el ritmo al alcance; normalmente planificamos hitos cada 1–2 semanas. Cada uno debe terminar con un elemento que se pueda ver, ejecutar o verificar mediante un criterio acordado.

Riesgo de omitir las iteraciones: la diferencia en la comprensión del alcance aparece solo después de construir muchos elementos dependientes. Las aceptaciones breves permiten corregir el rumbo cuando el coste del cambio aún es limitado.

Etapa 5. Pruebas, y no solo «hacer clic»

Tres capas de pruebas, cuyo alcance se ajusta al riesgo del proyecto:

  • Pruebas automatizadas para la lógica de la que depende el dinero (cálculos, permisos e integraciones).
  • Prueba con datos y volumen representativos. La muestra debe incluir formatos, casos límite y carga parecida al uso previsto; unos pocos registros cómodos no revelan los problemas de escala ni de calidad de datos.
  • Prueba con una persona usuaria. Alguien que no participó en el proyecto debe realizar la tarea sin indicaciones.

Duración: se intercala con la construcción; no es una fase independiente al final.

Etapa 6. Despliegue en producción

Un despliegue en producción es más que «subir archivos». Incluye, entre otros:

  • servidor y configuración (en nuestro caso, un VPS con despliegue automático desde el repositorio);
  • copias de seguridad y una restauración comprobada: sin prueba no se sabe si se puede confiar en la copia dentro del plazo requerido;
  • monitorización y alertas que aumentan la probabilidad de detectar una incidencia antes de que la comunique un usuario;
  • dominio, certificados, credenciales y documentación.

Duración: unos días con un buen plan; semanas sin él.

Etapa 7. Mantenimiento y evolución

Una aplicación en producción necesita atención durante todo su uso: actualizaciones de dependencias, monitorización, copias, respuesta a incidentes y adaptación a cambios de proceso. En agosto de 2026, nuestro retainer es de 1 500–6 000 PLN netos/mes, según el alcance y el tiempo de respuesta.

Riesgo de omitirlo: crece el retraso en las actualizaciones y desplegar el siguiente cambio exige primero resolver problemas de seguridad o compatibilidad de dependencias. Conviene acordar el alcance del mantenimiento y la responsabilidad de las partes antes de empezar en producción.

Siete etapas numeradas desde discovery hasta mantenimiento, con un bucle entre construcción y pruebas y una flecha desde mantenimiento hasta alcance
Las etapas ordenan las decisiones, pero no forman una línea rígida: la construcción se alterna con las pruebas y la operación aporta información para los siguientes cambios de alcance.

Cuánto tarda y cuesta todo esto

Nuestros intervalos, para tener una base de conversación:

AlcanceTiempo orientativoIntervalo neto (agosto de 2026)
MVP / aplicación inicial4–6 semanas con un recorrido clave y un número limitado de integraciones15 000 – 35 000 PLN
Aplicación media con integraciones2–4 meses35 000 – 90 000 PLN
Sistema personalizado ampliodesde 4 meses90 000 – 250 000 PLN
Mantenimientocontinuo1 500 – 6 000 PLN/mes

Qué desplaza el presupuesto: número de integraciones, requisitos de seguridad, número de roles y permisos, escala de los datos y necesidad de migrar desde un sistema anterior. Confirmamos los intervalos después de documentar el alcance y las dependencias.

Cuándo no crear una aplicación

  • Cuando una herramienta ya existente cubre los requisitos principales. Compara el coste de la licencia y de adaptar el proceso con el coste de desarrollar y mantener una solución propia.
  • Cuando aún no sabes si el problema es real. Primero valida, aunque sea de forma manual; después, código.
  • Cuando el producto es contenido, no una función. Entonces la elección adecuada puede ser un sitio web; lo comparamos en Next.js o WordPress.
  • Cuando nadie de tu parte tiene tiempo para el proyecto. Una aplicación a medida requiere decisiones del cliente. Sin ellas, se creará una aplicación a medida de nuestras suposiciones.

Preguntas frecuentes

¿El código nos pertenece?

Entregamos el repositorio y los derechos sobre el código creado para el cliente en el alcance descrito en el contrato. Las bibliotecas open source, los servicios externos, las fuentes y otras dependencias conservan sus propias licencias, por eso la lista de componentes y cuentas debe formar parte de la entrega.

¿Se puede construir una aplicación sin tener una idea cerrada de todo?

Sí. Para eso existen discovery y el trabajo por etapas: empezamos por la versión mínima capaz de comprobar un supuesto importante y decidimos los siguientes pasos según el resultado y la información de los usuarios.

¿Cómo comprobar si un proveedor puede manejar producción?

Pregunta qué mantiene hoy en producción, cómo detecta caídas, restaura datos y transfiere la responsabilidad. El portfolio por sí solo no responde a estas preguntas; pide un procedimiento, el alcance de la monitorización y un plan de entrega de ejemplo.


Creamos aplicaciones desde cero y las llevamos a producción. Un ejemplo de sistema que mantenemos junto con colectores que trabajan de forma continua es la plataforma analítica basada en TimescaleDB. Consulta las aplicaciones creadas desde cero o descríbenos tu proceso.

Maciej Szukalski

Autor

Maciej Szukalski

Fundador de Condictor · arquitecto de sistemas · investigación y desarrollo

Diseña y desarrolla productos digitales desde 2014. Se especializa en arquitectura, investigación y aplicaciones con capas de automatización e inteligencia.

¿Tienes un problema que resolver?

Veamos cuál es el mejor primer paso

Describe tu situación en unas frases. Volveremos con preguntas o una propuesta concreta para el siguiente paso.

Describe tu tema

Ver también

Todos los artículos