Crear una app desde cero con IA: de la idea al código sin perder el control

El error típico al crear una app con IA es empezar con «hazme una app para organizar tareas». La IA rellena por su cuenta todo lo que no has decidido (para quién es, qué hace, qué datos guarda) y acabas con algo que no es lo que tenías en la cabeza. Esta guía hace lo contrario: primero se define el producto, después se escribe, después se planifica y solo entonces se programa, por fases y con pruebas. Usamos Claude Code, pero el método sirve con cualquier agente.

1. Idea
2. Preguntas
3. Decisiones
4. Mínimo viable
5. PROJECT_SPEC.md
6. Plan
7. Fases
8. Pruebas

La regla de oro: no dejes que la IA decida en silencio cosas del producto que tú todavía no has decidido.

Prepara tu equipo

Claude Code pide 4 GB de RAM o más, un procesador x64 o ARM64 y conexión a Internet. Instálalo según tu sistema:

Windows (10 versión 1809 o posterior): en PowerShell, el instalador oficial; o con WinGet.

irm https://claude.ai/install.ps1 | iex

winget install Anthropic.ClaudeCode

Instala también Git para Windows (winget install --id Git.Git -e): Claude Code lo usa para trabajar mejor. Si tu proyecto vive en Linux, usa WSL 2 e instálalo dentro, con el instalador de Linux; no mezcles un mismo proyecto entre Windows y WSL.

macOS (13 o posterior): con el instalador oficial, leyéndolo antes, o con Homebrew.

curl -fsSL https://claude.ai/install.sh -o /tmp/claude-install.sh
            less /tmp/claude-install.sh
            bash /tmp/claude-install.sh

brew install --cask claude-code

CachyOS: desde el repositorio oficial, junto con Git.

sudo pacman -S --needed claude-code git

Ubuntu, Debian y otras: el instalador oficial de Linux (el mismo de macOS) o los repositorios firmados de Anthropic que describe su guía de instalación.

Comprueba que funciona y entra por primera vez, que te pedirá iniciar sesión en el navegador:

claude --version
            claude doctor
            claude

Desde el móvil (Android, iPhone o iPad) no se instala Claude Code: se usa desde la app oficial de Claude o desde claude.ai/code, de dos formas:

• En la nube: trabaja sobre un repositorio de GitHub en un entorno remoto, sin que tu ordenador esté encendido.
• Control remoto: manejas desde el móvil una sesión de Claude Code que sigue funcionando en tu ordenador, con tus archivos.

Descarga la app de Claude solo desde Google Play o la App Store. Nada de APK, perfiles ni certificados de terceros que prometan «activar Claude Code».

Crea la carpeta del proyecto

mkdir -p ~/Proyectos/mi-primera-app
            cd ~/Proyectos/mi-primera-app
            touch PROJECT_SPEC.md
            git init

En PowerShell, lo mismo es New-Item -ItemType Directory -Force "$HOME\Proyectos\mi-primera-app", Set-Location a esa carpeta y New-Item PROJECT_SPEC.md. En el móvil, crea un repositorio en GitHub con un PROJECT_SPEC.md.

Antes de arrancar Claude Code, comprueba con pwd (o Get-Location) que estás en la carpeta del proyecto y no en tu carpeta personal entera.

Escribe la idea sin tecnología

Empieza por el problema, no por las herramientas:

Quiero una aplicación que me diga qué debería hacer ahora mismo,
            porque tengo muchas tareas y pierdo tiempo eligiendo la siguiente.

Evita «quiero React + Next + Supabase + Redis…» si todavía no hay un motivo real para cada cosa. Tienes que poder explicar la idea en una o dos frases.

Que la IA te entreviste

Quiero crear una aplicación desde cero. Mi idea inicial es:
            [TU IDEA]

            No programes todavía. Actúa primero como responsable de producto.
            Convierte esta idea vaga en una especificación clara: hazme preguntas
            por bloques y espera mis respuestas antes de seguir. Aclaremos como mínimo:
            problema, usuario, resultado que obtiene, plataforma, función principal,
            funciones secundarias, versión mínima, modelo de negocio si lo hay,
            diseño, datos, cuentas, privacidad, integraciones, restricciones,
            recursos y objetivo real.
            No decidas por mí nada importante. Si algo es ambiguo, repregunta.
            No propongas tecnología salvo que haga falta para aclarar un requisito.

Lo que tienes que dejar claro:

• Qué es y para quién. Una fórmula útil: «Ayudamos a [usuario] a [resultado] mediante [mecanismo]». «Todo el mundo» no es un usuario.
• El resultado. Por ejemplo: «abro la app y en menos de 10 segundos sé qué hacer».
• La plataforma: web, móvil o escritorio. No multipliques plataformas al principio.
• La función principal, la que justifica que la app exista, y solo las secundarias que la apoyen.
• Lo que NO se va a hacer en la primera versión: chat, equipos, pagos, app nativa…
• Modelo de negocio: gratis, suscripción, pago único… o «pendiente». No inventes precios para rellenar.
• Diseño: sensación, densidad, accesibilidad y qué evitar.
• Cuentas: ¿de verdad hace falta iniciar sesión en la primera versión?
• Datos: qué se guarda (por ejemplo, una tarea: título, descripción, fecha, prioridad, estado).
• Privacidad: datos personales, dónde se guardan y cómo se borran.
• Restricciones, recursos y objetivo real: aprender, validar la idea, usarla tú, conseguir usuarios…

Nunca pongas contraseñas, tokens ni claves en la especificación.

Define la versión mínima

La versión mínima (el famoso MVP) es la más pequeña que demuestra que la idea funciona, no una versión cutre. De todo lo imaginado (tareas, calendario, equipos, IA, avisos, apps, estadísticas…), quizá basta con:

1. Crear una tarea.
2. Ver las tareas.
3. Recomendar la siguiente.
4. Marcarla como hecha.

La pregunta filtro: si quito esta función, ¿sigo pudiendo demostrar la idea principal? Si la respuesta es sí, sobra en la primera versión.

Escribe PROJECT_SPEC.md

Con todo lo que hemos decidido, crea la especificación final del producto
            en Markdown, en PROJECT_SPEC.md. No inventes decisiones nuevas: lo que
            falte, márcalo como PENDIENTE DE DECIDIR. Tiene que servir para que un
            agente que no ha leído esta conversación entienda qué construimos,
            para quién, por qué, qué incluye y qué no, cómo debe comportarse,
            el diseño, los datos, las restricciones y los criterios de aceptación.
            No escribas código.

Una plantilla que funciona:

# PROJECT_SPEC
            ## 1. Nombre
            ## 2. Resumen en una frase
            ## 3. Problema
            ## 4. Usuario
            ## 5. Resultado esperado
            ## 6. Plataforma
            ## 7. Función principal
            ## 8. Versión mínima (incluye / no incluye)
            ## 9. Recorrido principal del usuario
            ## 10. Funciones (imprescindibles / después / futuras)
            ## 11. Modelo de negocio
            ## 12. Diseño (sensación, referencias, evitar)
            ## 13. Cuentas
            ## 14. Datos
            ## 15. Privacidad y seguridad
            ## 16. Integraciones
            ## 17. Restricciones
            ## 18. Recursos
            ## 19. Objetivo real
            ## 20. Criterios de aceptación
            ## 21. Decisiones pendientes
            ## 22. Fuera de alcance

Léela antes de programar

No se la pases al agente sin leerla. Busca contradicciones, frases vagas, funciones sin decidir, tecnología metida sin motivo, lo que falta, un alcance demasiado grande, secretos y criterios que no se pueden comprobar.

La pregunta de control: ¿otra persona leería esto y me describiría la misma app que tengo en la cabeza? Si no, todavía no se programa.

Que el agente la entienda

Abre Claude Code en la carpeta del proyecto y empieza así:

Lee PROJECT_SPEC.md entero. No modifiques archivos todavía.
            Dime qué producto entiendes que construimos, quién es el usuario,
            cuál es la función principal, qué incluye la versión mínima,
            qué queda fuera, qué está pendiente y qué riesgos o contradicciones ves.
            No rellenes huecos por tu cuenta.

No sigas hasta que su resumen coincida con lo que quieres.

Seguridad antes de dejarle tocar

• Trabaja siempre desde la carpeta del proyecto.
• Lee el aviso de confianza de la carpeta y los comandos antes de aprobarlos. No aceptes lo que no entiendas.
• No le des secretos ni acceso a carpetas que no son del proyecto.
• Mientras aprendes, usa permisos prudentes. El modo de planificación le deja explorar sin editar.

No uses los modos que se saltan las confirmaciones en tu equipo de siempre: Anthropic los reserva para entornos aislados, como contenedores o máquinas virtuales.

Un plan, y después una fase cada vez

Crea un plan de implementación por fases de la versión mínima.
            No modifiques archivos todavía. Fases pequeñas y comprobables.
            En cada una: objetivo, archivos que prevés tocar, qué debe quedar
            funcionando, pruebas, dependencias, riesgos y cuándo está terminada.
            No añadas nada que no esté en PROJECT_SPEC.md.

Revisa el plan y después, nunca «hazlo todo»:

Implementa solo la fase [N]. Antes, comprueba el estado actual,
            explica qué vas a tocar y avisa de los riesgos. Después, ejecuta
            las pruebas, dime qué archivos cambiaste, resume el cambio y señala
            lo que se aparte de PROJECT_SPEC.md. No empieces la fase siguiente.

Pruebas: sin ellas no hay fase terminada

«El código parece correcto» no cuenta. Tiene que haber pruebas: que compila, un test que pasa, un recorrido hecho a mano, una respuesta del servidor, una captura, una prueba en el navegador o en el móvil.

No des la fase por terminada hasta comprobarla. Dime qué has probado,
            el resultado, qué no has podido comprobar y qué riesgo queda.

Que no se te llene de ideas

Durante el desarrollo saldrán ideas nuevas. No se implementan sobre la marcha:

No implementes esta idea ahora. Añádela a BACKLOG.md con una frase
            de por qué podría ser útil. No cambies el alcance de la versión mínima.

Y ten la documentación separada: PROJECT_SPEC.md (qué construimos), HANDOFF.md (dónde estamos; tienes la guía de HANDOFF), README.md (cómo se ejecuta), DECISIONS.md y BACKLOG.md.

Qué decide la IA y qué decides tú

La IA ayuda a descubrir preguntas, ordenar requisitos, detectar contradicciones, proponer y comparar opciones, redactar, planificar, programar y probar.

Tú decides qué problema resolver y para quién, la experiencia, los datos, cuánto gastar, qué entra en la versión mínima y qué no, qué riesgos aceptas y cuándo una prueba es suficiente.

Errores frecuentes

• Programar antes de definir el producto.
• Contestar «lo que tú veas» a decisiones importantes.
• Una versión mínima gigante, o sin escribir qué queda fuera.
• Cambiar el producto sin actualizar PROJECT_SPEC.md.
• Fiarlo todo a una conversación.
• Confundir una pantalla bonita con un producto que funciona.
• Aceptar comandos sin leerlos o dar acceso a secretos.
• Dar una fase por buena sin pruebas.
• Meter herramientas porque el agente las conoce, no porque el proyecto las necesite.

¿Listo para empezar?

Si puedes responder con claridad a estas seis preguntas, sí: qué construyes, para quién, qué problema resuelve, cuál es la función principal, qué forma la versión mínima y qué queda fuera.

Si algo falla

• claude no se reconoce: cierra y abre el terminal. En Windows, comprueba con Get-Command claude; en macOS y Linux, con command -v claude. Y usa el instalador de tu terminal: el de PowerShell en PowerShell y el de Linux en WSL, nunca al revés.
• En CachyOS, algo deja de funcionar tras actualizar el sistema: comprueba con claude --version y claude doctor, y mira los avisos de CachyOS antes de tocar nada.
• En el móvil no aparece Code: cuenta correcta, acceso a Claude Code y app actualizada. Si no ves tus repositorios, revisa los permisos de la app de Claude en GitHub.
• El control remoto sale desconectado: la sesión tiene que seguir abierta en el ordenador y con red.

Para desinstalar, borra el programa, no tu configuración: la carpeta ~/.claude guarda tus ajustes, permisos e historial. Bórrala solo si quieres empezar de cero del todo.

Documentación oficial: primeros pasos, seguridad y permisos.