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.