Crear app sin programar: guía de tu primera semana

Publicado el 16 de octubre de 2026

Para crear una app sin programar con Claude Code en una semana, no empieces por la herramienta: empieza por un problema concreto y una sola función. Dedica dos días a definir y acotar, tres a construir en pasos pequeños y dos a probar y corregir. Al final tendrás una primera versión usable, no un producto terminado.

Soy Rupo y te lo planteo así por una opinión personal, no por un dato: creo que el error más fácil de cometer cuando no vienes del código es querer construir demasiado el primer día. Una app pequeña que funciona te enseña más que una grande que se queda a medias. Claude Code es un asistente de programación de Anthropic que trabaja sobre los archivos de tu proyecto y ejecuta tareas a partir de instrucciones en lenguaje natural (documentación oficial de Claude Code). Tú decides qué se construye y para quién. Él escribe y modifica el código.

Este es el plan de la semana de un vistazo:

Día	Qué haces	Qué tienes al terminar
1	Eliges el problema y preparas tu entorno	Una frase que describe el problema y para quién
2	Defines la versión mínima	Tres funciones como máximo y una lista de lo que dejas fuera
3	Escribes el encargo para Claude Code	Un documento de una página con el objetivo y los límites
4	Construyes el primer flujo	Una pantalla o un paso funcionando en tu ordenador
5	Añades la función central	La acción principal funciona de principio a fin
6	Pruebas y corriges	Una lista de fallos encontrados y arreglados
7	Se la enseñas a 2 o 3 personas	Comentarios reales anotados y una decisión sobre qué sigue

Si quieres una visión más general del tema antes de entrar en el calendario, tienes la guía para crear una app sin saber programar. Aquí vamos al plan día a día.

¿Qué necesitas antes de empezar a crear tu app sin programar?

Necesitas muy poco: un ordenador, acceso a Claude Code, una idea que se pueda decir en una frase y unas horas reservadas cada día. No necesitas saber programar, pero sí estar dispuesto a leer lo que Claude te explique y a decidir con criterio.

En corto: antes de empezar necesitas acceso a Claude Code, un problema concreto y tiempo protegido en tu agenda, nada más.

Sobre el acceso, revisa en la documentación oficial de Anthropic qué plan incluye Claude Code y cómo se instala en tu sistema, porque esos detalles cambian con el tiempo y no quiero darte un dato que mañana esté desfasado. Lo que sí depende de ti es lo siguiente:

• Una carpeta vacía en tu ordenador para el proyecto, con un nombre claro.
• Un documento de texto donde apuntarás decisiones, dudas y fallos.
• Una hora al día como mínimo, y mejor siempre a la misma hora.
• Una persona real a quien enseñarás el resultado el día siete. Ponle fecha ya.

El día uno termina cuando puedes escribir sin dudar: «Mi app ayuda a [tipo de persona] a [hacer una cosa concreta]». Si no te sale en una frase, la idea aún es demasiado grande.

¿Cómo defines una primera versión pequeña de tu app?

Defines una primera versión pequeña eligiendo una sola acción que el usuario pueda completar de principio a fin y dejando todo lo demás fuera por escrito. La versión mínima es la app con el menor número de funciones que ya resuelve el problema para una persona.

En corto: tu primera versión es la app con el menor número de funciones que ya resuelve un problema real para una persona.

Una técnica sencilla para el día dos: escribe todo lo que te gustaría que hiciera tu app, sin filtro. Después tacha hasta que queden tres cosas como máximo. Para decidir qué sobrevive, hazte una pregunta: ¿sin esto, el usuario puede completar la acción principal? Si la respuesta es sí, sale de la primera versión.

Qué dejar fuera sin remordimientos

Casi siempre se pueden aplazar el registro de usuarios con cuentas, los pagos, las notificaciones, los paneles de estadísticas y los diseños elaborados. No son malas ideas. Son ideas para la versión dos. Guárdalas en una sección de tu documento llamada «Después» y no las toques durante la semana.

Si necesitas inspiración sobre qué tamaño tiene una primera versión razonable, mira los proyectos del portafolio de alumnos de Rupgo y fíjate en lo concreto que es el problema de cada uno.

¿Cómo le explicas a Claude Code lo que quieres construir?

Le explicas lo que quieres construir con un encargo escrito en lenguaje normal que incluya el objetivo, quién lo usa, las funciones permitidas y lo que no debe hacer. Cuanto más claro el encargo, menos correcciones tendrás que pedir después.

En corto: un buen encargo a Claude Code dice qué construir, para quién, con qué límites y cómo sabrás que está bien.

Este es el esqueleto que te propongo para el día tres. Cópialo en tu documento y rellénalo con tus palabras:

1. Objetivo: una frase con el problema y la persona.
2. Funciones: las tres como máximo, numeradas.
3. Fuera de alcance: lo que no quieres que construya todavía.
4. Datos: qué información maneja la app y de dónde sale.
5. Criterio de éxito: qué debería poder hacer una persona al terminar.

Después no se lo pegues todo de golpe esperando que salga perfecto. Pídele primero que lea tu encargo, te devuelva un plan en pasos y te pregunte lo que no entienda. Revisa ese plan con calma. Si algo no lo entiendes, pídele que lo explique con un ejemplo cotidiano. Solo cuando el plan te convenza, pídele el primer paso.

La regla que te recomiendo: un paso por petición. Si pides diez cosas a la vez, no sabrás cuál causó un fallo.

¿Cómo pruebas y corriges tu app paso a paso?

Pruebas tu app después de cada paso pequeño, usándola como lo haría un usuario real, y cuando algo falla describes a Claude Code qué hiciste, qué esperabas y qué ocurrió. Probar a menudo evita acumular errores que luego no sabes localizar.

En corto: prueba tras cada paso y reporta los fallos con tres datos: qué hiciste, qué esperabas y qué pasó.

Los días cuatro y cinco son de construir, y el seis es de pulir. El ritmo es el mismo cada día: pides un paso, lo pruebas, anotas el resultado y decides si seguir o corregir. Cuando algo falle, evita decir «no funciona». Escribe algo como: «Al pulsar el botón de guardar, esperaba ver el elemento en la lista, pero la pantalla se queda en blanco». Si hay un mensaje de error, pégalo entero.

Un pequeño hábito que te ahorra disgustos

Antes de cada cambio grande, pídele a Claude Code que guarde una versión del proyecto con control de versiones, para que puedas volver atrás si algo se rompe. Pregúntale cómo hacerlo en tu caso y que te lo deje explicado paso a paso. Es la red de seguridad de quien no programa.

El día seis, haz un recorrido completo sin ayuda: abre la app como si fuera la primera vez y completa la acción principal. Apunta cada tropiezo, aunque sea pequeño, y prioriza solo los que impiden terminar la tarea.

¿Cómo sabes que tu primera versión está lista para enseñarla?

Sabes que está lista cuando una persona que no ha participado en el proyecto puede completar la acción principal sin que le expliques nada. No hace falta que sea bonita ni completa. Hace falta que funcione y que se entienda.

En corto: tu app está lista para enseñarla cuando otra persona completa la acción principal sin tu ayuda.

Para el día siete, usa esta lista de comprobación:

• La acción principal funciona de principio a fin sin errores visibles.
• Un texto corto explica para qué sirve y cómo se usa.
• Has probado el recorrido completo al menos una vez tú mismo.
• Sabes qué tres cosas dejaste fuera a propósito.
• Tienes dos o tres personas dispuestas a probarla.

Cuando se la enseñes, calla y observa. No expliques, no defiendas, no corrijas sobre la marcha. Fíjate en dónde dudan, qué pulsan primero y qué preguntan. Esas pausas te dicen más que cualquier opinión. Al terminar, pregúntales una sola cosa: «¿Para qué usarías esto?». Su respuesta te dice si tu problema era el correcto.

¿Qué haces después de la primera semana?

Después de la primera semana, ordenas lo que has aprendido, eliges una sola mejora para la versión dos y repites el ciclo corto de definir, construir, probar y enseñar. No amplíes por impulso: amplía por lo que viste en las pruebas.

En corto: tras la primera semana, elige una única mejora basada en lo que vieron tus probadores y repite el ciclo.

Revisa tus notas y separa tres grupos: fallos que impiden usar la app, cosas que confundieron e ideas nuevas. Atiende primero el primer grupo, luego el segundo. El tercero va a la lista «Después». Si varias personas tropezaron en el mismo punto, ahí está tu siguiente tarea.

También es buen momento para decidir si tu idea merece seguir. Dejarla también es una decisión legítima, y tener una versión real en las manos te da información que antes solo imaginabas. Si sigues, pregúntate qué necesita tu app para que alguien la use sin ti delante, y construye solo eso.

Esta semana no te da un negocio ni un plazo para tenerlo. Te da algo tangible que enseñar y un método que puedes repetir cada vez que quieras mejorar tu app.

Empieza por aquí esta semana

1. Escribe hoy la frase «Mi app ayuda a [persona] a [acción concreta]» y no sigas hasta que te convenza.
2. Crea la carpeta del proyecto y el documento de notas con las secciones «Decisiones», «Fallos» y «Después».
3. Lista todo lo que querrías en tu app y deja solo tres funciones.
4. Redacta tu encargo con el esqueleto de cinco partes y pídele a Claude Code un plan antes de construir nada.
5. Reserva ya, en tu agenda, el día siete y ponle nombre a la persona que probará tu app.

Escrito por Rupo.