Zum Inhalt springen
Creaitercreate your vision with ai
EinloggenRegistrieren
Alle Beispielprojekte

Web-App

Schichtnotiz

Schichten eintragen und die eigene Woche überblicken

Eine Web-App, in der man in unter zehn Sekunden eine Schicht einträgt und die kommende Woche auf einen Blick sieht.

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

Wer in Schichten arbeitet, hat den Plan meist als Foto im Handy oder auf einem Zettel. Die Frage „arbeite ich Samstag?“ kostet dann jedes Mal Suchen. Die App beantwortet genau diese eine Frage schnell — sie ersetzt keinen Dienstplan des Arbeitgebers.

Der Kernloop in vier Schritten

  1. 1Öffnen — die aktuelle Woche steht sofort da
  2. 2Eine Schicht eintragen — Tag, Beginn, Ende
  3. 3Die Woche sehen — was liegt an, wie viele Stunden
  4. 4Die nächste Woche planen — vorblättern und eintragen

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.

  • Kein Team- oder Abteilungsplan — sobald mehrere Personen denselben Plan sehen, braucht es Konten, Rechte und Konfliktauflösung. Das ist ein anderes Produkt.
  • Kein Export nach Kalender oder PDF — nützlich, aber es macht die Frage „arbeite ich Samstag?“ nicht schneller beantwortbar.
  • Keine Lohn- oder Zuschlagsberechnung — sie hängt an Tarif, Land und Vertrag. Falsch gerechnet ist schlimmer als gar nicht gerechnet.
  • Keine Erinnerungen oder Benachrichtigungen — sie verlangen Berechtigungen und einen laufenden Dienst und gehören nicht in eine erste Version.
  • Kein Konto und keine Synchronisierung — die Daten bleiben im Browser. Das schließt Geräteweschsel aus und war der bewusste Preis für sieben Tage.

Release-Ziel

Öffentlich erreichbare Web-App unter eigener Adresse. Kein Store, keine Installation, kein Konto.

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 einseitige Spec: Zielnutzer, das Kernproblem in einem Satz, der Kernloop in vier Schritten, fünf Nicht-Ziele und das Release-Ziel „öffentlich erreichbare Web-App“.
    Warum so
    Als Release-Ziel wurde bewusst die Web-App gewählt und nicht der App Store. Damit liegt der gesamte Weg bis zur Veröffentlichung in eigener Hand — keine Kontoprüfung, kein Review, kein Wartefenster. Für ein Sieben-Tage-Ergebnis ist das der Unterschied zwischen „fertig“ und „eingereicht und dann abwarten“.

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

    Was entstand
    Ein laufendes Projekt mit zwei Ansichten — Woche und Eintragen — und einer Navigation, die mit dem Daumen erreichbar ist. Die Daten liegen lokal im Browser.
    Warum so
    Statt einer Datenbank kam der lokale Browserspeicher zum Einsatz. Das ist die Entscheidung mit dem größten Zeitgewinn im ganzen Projekt: kein Server, kein Konto, keine Anmeldung, keine Datenschutz-Fragen zu gespeicherten Personendaten. Der Preis steht als Nicht-Ziel geschrieben.

  3. 3Tag 3 — Dein Kernloop funktioniert

    Was entstand
    Der vollständige Ablauf: Schicht eintragen, sie erscheint in der Woche, die Wochenstunden aktualisieren sich, die nächste Woche ist erreichbar.
    Warum so
    Die Wochenansicht kam vor dem Eintragen-Formular. Wer zuerst das Formular baut, testet gegen eine leere Fläche und merkt erst spät, ob die Darstellung überhaupt trägt.
    Was zuerst nicht klappte
    Die ersten Testdaten waren „Schicht 1“ bis „Schicht 5“, alle acht Stunden lang. Damit sah die Woche perfekt aus. Mit echten Daten — eine geteilte Schicht, eine Nachtschicht über Mitternacht — brach die Darstellung sofort. Die Nachtschicht über Mitternacht wurde daraufhin zum expliziten Testfall.

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

    Was entstand
    Vier Zustände: leere Woche mit Einstieg, ungültige Eingabe mit Begründung, ein Wiedereinstieg nach Wochen, der auf der aktuellen Woche landet, und geprüfte Textskalierung.
    Warum so
    Der Leerzustand bekam den meisten Text des ganzen Projekts. Er ist der erste Bildschirm jedes neuen Nutzers — dort zu sparen heißt, an der einzigen Stelle zu sparen, die jeder sieht.
    Was zuerst nicht klappte
    Der Wiedereinstieg landete zunächst auf der zuletzt angesehenen Woche. Wer die App vier Wochen nicht öffnete, sah damit eine alte Woche und hielt sie für die aktuelle. Der Sprung auf die laufende Woche war die Korrektur.

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

    Was entstand
    Datenschutzerklärung, Impressum und eine Support-Adresse. Eine Zeile in der App erklärt, dass die Daten den Browser nicht verlassen.
    Warum so
    Es gibt keinen kostenpflichtigen Pfad und deshalb auch keine Kostengrenze. Das wurde ausdrücklich aufgeschrieben statt einfach weggelassen — „keine Fremdkosten“ ist ein Ergebnis der Architektur, nicht eine vergessene Aufgabe. Wer das nicht notiert, sucht in vier Wochen nach dem fehlenden Limit.

  6. 6Tag 6 — Ein echter Release-Kandidat

    Was entstand
    Ein veröffentlichbarer Stand, getestet in zwei Browsern und auf einem echten Telefon, nicht nur im verkleinerten Desktop-Fenster.
    Warum so
    Der Test auf echter Hardware wurde auch für eine Web-App durchgezogen. Ein schmales Desktop-Fenster hat keine Bildschirmtastatur, die die halbe Fläche verdeckt — genau daran scheiterte das Eintragen-Formular beim ersten echten Versuch.

  7. 7Tag 7 — Deine Entscheidung ist belegt

    Was entstand
    Ein Protokoll mit jedem Release-Gate und einem Ja oder Nein dahinter, dazu eine V1.1-Liste mit vier Punkten.
    Warum so
    Veröffentlicht wurde. Ausschlaggebend war nicht die Vollständigkeit, sondern dass der Kernloop auf echter Hardware vollständig durchlief und kein Datenverlust auftrat. Der fehlende Kalenderexport steht als erster Punkt auf der V1.1-Liste — mit dem Satz, warum er nicht in V1 gehörte.

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: Schichtnotiz — Schichten eintragen und die eigene Woche überblicken.

Kernloop in vier Schritten:
1. Öffnen — die aktuelle Woche steht sofort da
2. Eine Schicht eintragen — Tag, Beginn, Ende
3. Die Woche sehen — was liegt an, wie viele Stunden
4. Die nächste Woche planen

Ausdrücklich NICHT in Version 1: Team-/Abteilungsplan, Export nach Kalender oder PDF, Lohn- und Zuschlagsberechnung, Erinnerungen, Konto und Synchronisierung.

Release-Ziel: öffentlich erreichbare Web-App, Daten bleiben lokal im Browser.

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. Nenne mir die drei Testfälle, an denen diese App am ehesten scheitert.

Ändere den Scope nicht, ohne mich zu fragen.