Zum Inhalt springen
Creaitercreate your vision with ai
EinloggenRegistrieren
Alle Beispielprojekte

Web-App

Rezept-Eingang

Rezepte sammeln und auf das Wesentliche eindampfen

Eine Web-App, die aus einem eingefügten Rezept die reine Zutaten- und Schrittliste macht — ohne die Geschichte drumherum.

Konstruierte Lehrbeispiele: Diese drei Projekte wurden für den Kurs entlang der belegten Sieben-Tage-Regeln geschrieben. Es sind keine echten Nutzerprojekte, es gibt keine laufende App, keinen Live-Link und keinen Store-Eintrag. Der Beleg sind die Entscheidungen, nicht ein Bildschirmfoto.

Wofür es gebaut wurde

Rezepte im Netz stehen zwischen langen Vorreden, Werbung und Fotos. Wer in der Küche steht, will Zutaten und Schritte. Die App nimmt einen eingefügten Text oder Link und legt das Wesentliche als Karte ab.

Der Kernloop in vier Schritten

  1. 1Öffnen — die eigene Sammlung steht da
  2. 2Ein Rezept einwerfen — Text einfügen oder Link angeben
  3. 3Das Ergebnis prüfen — Zutaten und Schritte, korrigierbar
  4. 4Speichern und weitermachen — die Karte liegt in der Sammlung

Bewusst weggelassen

Das Verkleinern des Scopes ist die eigentliche Arbeit von Tag 1. Diese Punkte hätten das Projekt größer gemacht, ohne den Kernloop besser zu machen.

  • Keine Einkaufsliste — der naheliegendste nächste Schritt, aber ein eigener Ablauf mit eigenen Zuständen. Er steht auf der V1.1-Liste.
  • Keine Mengenumrechnung auf Portionen — sie klingt trivial und ist es bei realen Rezepten nicht („eine Prise“, „ein Bund“).
  • Kein Teilen und keine öffentlichen Sammlungen — das verlangt Rechte, Sichtbarkeiten und eine Antwort auf fremde Urheberrechte.
  • Kein Foto-Import per Kamera — die Texterkennung wäre ein zweiter kostenpflichtiger Pfad neben dem bereits vorhandenen.

Release-Ziel

Öffentlich erreichbare Web-App mit einem angemeldeten Bereich für die eigene Sammlung.

Die sieben Bautage

Für jeden Tag steht getrennt, was danach sichtbar war und welche Entscheidung dahinterstand. Wo etwas zuerst nicht funktionierte, steht auch das.

  1. 1Tag 1 — Dein Scope steht

    Was entstand
    Eine Spec mit Kernloop, vier Nicht-Zielen und der frühen Festlegung, dass genau ein kostenpflichtiger Pfad erlaubt ist.
    Warum so
    Das Eindampfen des Rezepttexts übernimmt ein bezahlter Dienst. Diese Abhängigkeit wurde an Tag 1 bewusst zugelassen und auf genau eine Stelle begrenzt — jede weitere hätte einen zweiten Kostenpfad, ein zweites Limit und einen zweiten Ausfallfall bedeutet.

  2. 2Tag 2 — Ein echter Build läuft

    Was entstand
    Ein laufendes Projekt mit Anmeldung, zwei Ansichten und einer serverseitigen Route, hinter der der bezahlte Dienst liegt.
    Warum so
    Der Schlüssel des Dienstes lag von der ersten Zeile an auf dem Server, nie im Browser. Ein Schlüssel im Browser ist kein Fehler, den man später repariert — er ist ab dem ersten Deploy öffentlich.

  3. 3Tag 3 — Dein Kernloop funktioniert

    Was entstand
    Der vollständige Ablauf von eingefügtem Text bis zur gespeicherten Karte, mit korrigierbarem Zwischenergebnis.
    Warum so
    Das Ergebnis ist bearbeitbar, bevor es gespeichert wird. Ein automatisches Verfahren liegt manchmal daneben; ohne Korrekturmöglichkeit landet der Fehler dauerhaft in der Sammlung und der Nutzer verliert das Vertrauen in alle Karten.

  4. 4Tag 4 — Deine App hält auch schlechte Tage aus

    Was entstand
    Leere Sammlung mit Einstieg, unbrauchbare Eingabe mit Erklärung, Dienst nicht erreichbar mit Wiederholung, langsame Antwort mit ehrlichem Wartezustand.
    Warum so
    „Dienst nicht erreichbar“ bekam eine eigene Behandlung getrennt von „Text unbrauchbar“. Beides als ein Fehler zu zeigen, hätte dem Nutzer die Schuld für einen Ausfall gegeben, den er nicht verursacht hat.

  5. 5Tag 5 — Betrieb, Recht und Kosten stehen

    Was entstand
    Rechtstexte, Support-Weg und eine serverseitige Kostengrenze pro Nutzer und Tag, dazu ein erreichbarer Not-Aus für den gesamten Import.
    Warum so
    Die Grenze prüft der Server vor jedem Aufruf des Dienstes, nicht der Browser. Ein Login sagt, wer jemand ist, nicht wie viel er verbrauchen darf — die Reihenfolge lautet Anfrage, Prüfung, Budget reservieren, Dienst starten, Nutzung verbuchen.
    Was zuerst nicht klappte
    Die erste Fassung zählte die Nutzung erst nach der Antwort des Dienstes. Zwei schnell hintereinander abgeschickte Importe liefen dadurch beide durch, obwohl das Tageslimit nach dem ersten erreicht war. Reserviert wird seitdem vorher.

  6. 6Tag 6 — Ein echter Release-Kandidat

    Was entstand
    Ein veröffentlichbarer Stand, getestet in zwei Browsern und auf einem echten Telefon, mit einem Testzugang für Prüfende.
    Warum so
    Der Testzugang enthält bereits drei Beispielkarten. Ein leeres Konto zwingt jede prüfende Person, zuerst den Import zu benutzen — und damit ausgerechnet den Teil, der von einem fremden Dienst abhängt.

  7. 7Tag 7 — Deine Entscheidung ist belegt

    Was entstand
    Ein Protokoll aller Release-Gates mit Belegen, dazu eine V1.1-Liste, angeführt von der Einkaufsliste.
    Warum so
    Veröffentlicht wurde. Ausschlaggebend war, dass der einzige kostenpflichtige Pfad ein geprüftes Limit und einen erreichbaren Not-Aus hat — ohne beides wäre die App trotz funktionierendem Kernloop nicht herausgegangen.

Mitnehmen und remixen

Der Remix übernimmt Idee, Kernloop, Nicht-Ziele und Release-Ziel als deinen Ausgangspunkt — nicht die Lösung. Die sieben Bautage bleiben identisch, du überspringst keinen Schritt und kein Prüfkriterium.

Auftrag für dein KI-Werkzeug

Wenn du lieber sofort loslegst, statt über den Pfad zu gehen: Dieser Auftrag beschreibt das Projekt vollständig genug, dass ein KI-Werkzeug damit anfangen kann.

Ich baue eine kleine Web-App: Rezept-Eingang — Rezepte sammeln und auf Zutaten und Schritte eindampfen.

Kernloop in vier Schritten:
1. Öffnen — die eigene Sammlung steht da
2. Ein Rezept einwerfen — Text einfügen oder Link angeben
3. Das Ergebnis prüfen — Zutaten und Schritte, korrigierbar
4. Speichern und weitermachen

Ausdrücklich NICHT in Version 1: Einkaufsliste, Mengenumrechnung auf Portionen, Teilen und öffentliche Sammlungen, Foto-Import per Kamera.

Release-Ziel: öffentlich erreichbare Web-App mit Anmeldung. Genau EIN kostenpflichtiger Pfad ist erlaubt (das Eindampfen des Rezepttexts) — mit serverseitiger Prüfung vor jedem Aufruf, Tageslimit und Not-Aus.

Hilf mir, damit anzufangen:
1. Stelle mir Rückfragen zu allem, was du für den ersten Schritt wissen musst.
2. Schlage die kleinste Datenstruktur vor, die diesen Kernloop trägt.
3. Beschreibe die serverseitige Kette Anfrage → Prüfung → Budget reservieren → Dienst starten → Nutzung verbuchen für meinen Fall.

Ändere den Scope nicht, ohne mich zu fragen.