Saltar al contenido
Creaitercreate your vision with ai
Iniciar sesiónRegistrarse
Todos los proyectos de ejemplo

App web

Bandeja de recetas

Reunir recetas y reducirlas a lo esencial

Una app web que convierte una receta pegada en una lista limpia de ingredientes y pasos, sin la historia alrededor.

Ejemplos didácticos construidos: estos tres proyectos se escribieron para el curso siguiendo las reglas documentadas de los siete días. No son proyectos reales de personas usuarias, no hay ninguna app en marcha, ni enlace en vivo ni ficha de tienda. La prueba aquí son las decisiones, no una captura de pantalla.

Para qué se construyó

Las recetas en internet están entre preámbulos largos, publicidad y fotos. Quien está en la cocina quiere ingredientes y pasos. La app toma un texto pegado o un enlace y archiva lo esencial como ficha.

El bucle central en cuatro pasos

  1. 1Abrir — tu colección está ahí
  2. 2Echar una receta — pegar texto o dar un enlace
  3. 3Revisar el resultado — ingredientes y pasos, corregibles
  4. 4Guardar y seguir — la ficha queda en la colección

Dejado fuera a propósito

Reducir el alcance es el trabajo real del día 1. Estos puntos habrían hecho el proyecto más grande sin mejorar el bucle central.

  • Sin lista de la compra: el siguiente paso más evidente, pero es un flujo propio con estados propios. Está en la lista V1.1.
  • Sin conversión de cantidades por raciones: suena trivial y con recetas reales no lo es («una pizca», «un manojo»).
  • Sin compartir ni colecciones públicas: exige permisos, visibilidades y una respuesta a los derechos de autor ajenos.
  • Sin importación por cámara: el reconocimiento de texto sería una segunda ruta de pago junto a la que ya existe.

Objetivo de publicación

App web accesible públicamente con un área identificada para la colección propia.

Los siete días de construcción

Para cada día se indica por separado qué quedó visible después y qué decisión había detrás. Donde algo no funcionó al principio, también consta.

  1. 1Día 1 — Tu alcance está definido

    Qué se construyó
    Una especificación con el bucle central, cuatro no-objetivos y la decisión temprana de permitir exactamente una ruta de pago.
    Por qué así
    La reducción del texto de la receta la hace un servicio de pago. Esa dependencia se permitió a propósito el día 1 y se limitó a un único punto: cualquier otra habría supuesto una segunda ruta de coste, un segundo límite y un segundo caso de fallo.

  2. 2Día 2 — Un build real funciona

    Qué se construyó
    Un proyecto en marcha con inicio de sesión, dos vistas y una ruta de servidor tras la que está el servicio de pago.
    Por qué así
    La clave del servicio estuvo en el servidor desde la primera línea, nunca en el navegador. Una clave en el navegador no es un fallo que se repara después: es pública desde el primer despliegue.

  3. 3Día 3 — Tu bucle central funciona

    Qué se construyó
    El flujo completo del texto pegado hasta la ficha guardada, con resultado intermedio corregible.
    Por qué así
    El resultado es editable antes de guardarse. Un procedimiento automático a veces se equivoca; sin corrección el error queda permanentemente en la colección y la persona pierde la confianza en todas las fichas.

  4. 4Día 4 — Tu app aguanta también los días malos

    Qué se construyó
    Colección vacía con entrada, entrada inservible con explicación, servicio inalcanzable con reintento, respuesta lenta con estado de espera honesto.
    Por qué así
    «Servicio inalcanzable» recibió un tratamiento propio, separado de «texto inservible». Mostrar ambos como un mismo error habría culpado a la persona de una caída que no provocó.

  5. 5Día 5 — Operación, aspectos legales y costes

    Qué se construyó
    Textos legales, vía de soporte y un límite de coste en servidor por persona y día, además de un botón de apagado accesible para toda la importación.
    Por qué así
    El límite lo comprueba el servidor antes de cada llamada al servicio, no el navegador. Un inicio de sesión dice quién es alguien, no cuánto puede consumir: el orden es petición, comprobación, reservar presupuesto, arrancar servicio, registrar uso.
    Qué no funcionó al principio
    La primera versión contaba el uso solo tras la respuesta del servicio. Dos importaciones enviadas seguidas pasaban ambas aunque el límite diario se alcanzara con la primera. Desde entonces el presupuesto se reserva antes.

  6. 6Día 6 — Un candidato de lanzamiento real

    Qué se construyó
    Un estado publicable, probado en dos navegadores y en un teléfono real, con una cuenta de prueba para quien revise.
    Por qué así
    La cuenta de prueba ya contiene tres fichas de ejemplo. Una cuenta vacía obliga a quien revisa a usar primero la importación, es decir, justo la parte que depende de un servicio ajeno.

  7. 7Día 7 — Tu decisión está documentada

    Qué se construyó
    Un registro de todas las puertas de publicación con pruebas, además de una lista V1.1 encabezada por la lista de la compra.
    Por qué así
    Se publicó. Lo decisivo fue que la única ruta de pago tiene un límite comprobado y un apagado accesible: sin ambas cosas la app no habría salido pese a tener el bucle central funcionando.

Llévatelo y remézclalo

La remezcla toma la idea, el bucle central, los no-objetivos y el objetivo de publicación como tu punto de partida, no la solución. Los siete días quedan idénticos: no te saltas ningún paso ni ningún criterio.

Encargo para tu herramienta de IA

Si prefieres empezar ya en lugar de pasar por la ruta: este encargo describe el proyecto con detalle suficiente para que una herramienta de IA pueda comenzar.

Estoy construyendo una pequeña app web: Bandeja de recetas — reunir recetas y reducirlas a ingredientes y pasos.

Bucle central en cuatro pasos:
1. Abrir — mi colección está ahí
2. Echar una receta — pegar texto o dar un enlace
3. Revisar el resultado — ingredientes y pasos, corregibles
4. Guardar y seguir

Expresamente NO en la versión 1: lista de la compra, conversión de cantidades por raciones, compartir y colecciones públicas, importación por cámara.

Objetivo de publicación: app web accesible públicamente con inicio de sesión. Se permite exactamente UNA ruta de pago (la reducción del texto de la receta), con comprobación en servidor antes de cada llamada, límite diario y botón de apagado.

Ayúdame a empezar:
1. Hazme las preguntas que necesites para el primer paso.
2. Propón la estructura de datos más pequeña que sostenga este bucle central.
3. Describe para mi caso la cadena en servidor: petición → comprobación → reservar presupuesto → arrancar servicio → registrar uso.

No cambies el alcance sin preguntarme.

Ajuste de privacidad

¿Podemos medir vistas de página seudónimas y grabaciones de sesión?

Con tu consentimiento, PostHog EU mide qué páginas se abren y además graba tu sesión: los movimientos del ratón, los clics, el desplazamiento y el contenido mostrado se guardan como una reconstrucción reproducible. Las entradas escritas se enmascaran antes del envío. Los contenidos del inicio de sesión, el registro, la recuperación de contraseña, el chat del fundador, el campo de newsletter, la vista de tu correo, tus respuestas del cuestionario y las listas de comprobación no se graban en absoluto; en las páginas de inicio de sesión y registro la grabación se detiene. Las direcciones se guardan siempre sin parámetros de consulta. También se procesan un identificador de dispositivo aleatorio y datos técnicos de conexión como la dirección IP. Además se miden eventos de uso estrictamente definidos: hasta dónde se leyó un artículo, qué elemento se utilizó, qué llamada a la acción se pulsó, cómo terminó una suscripción al boletín, hasta dónde llegas en un curso o en el feed (registrando solo si una tarea fue correcta o incorrecta, nunca tu respuesta), qué vídeo inicias, si cambias de idioma y cómo terminó un intento de inicio de sesión o registro: sin la dirección de correo, sin la contraseña y sin el mensaje de error. Solo se transmiten valores de una lista fija y números enteros de rangos fijos: ninguna entrada y ningún texto libre. También etiquetamos por separado las visitas de producción, internas y de pruebas automatizadas, y derivamos si una visita procede de una interfaz conocida como ChatGPT, Claude o Perplexity a partir de un dominio de referencia conocido o de un valor de campaña estrictamente permitido. No se envían la dirección de referencia completa ni los parámetros de consulta, y esto no permite identificar un modelo de IA concreto. Si el enriquecimiento geográfico basado en IP está activado en el proyecto de PostHog, el servicio puede derivar aproximadamente el país, continente y región; no solicitamos la ubicación del navegador ni del GPS. Además, cada visita se asigna a un área de la página tomada de una lista fija (por ejemplo inicio, blog, herramientas, cuenta): se envía el área, no la dirección. También se miden indicadores de carga y estabilidad de la página (Core Web Vitals: LCP, CLS, INP, FCP), sin contenidos de red. Un clic en un enlace que lleva fuera del sitio se registra solo como dominio de destino de una lista fija, sin ruta, sin parámetros de consulta y sin el texto del enlace. En las herramientas Rueda de ideas, Etiquetado de IA y Reinicio de límites solo se mide el tipo de acción —por ejemplo girar, cambiar una opción, copiar o exportar—, nunca tus entradas ni los resultados. Más información sobre privacidad

Sin tu consentimiento no se carga ningún código de analítica ni se graba nada. Puedes revocarlo en cualquier momento: la revocación finaliza la recogida de inmediato; los datos ya recogidos pueden haberse transmitido en ese momento y se eliminan tras el plazo de conservación.