TL;DR
Ich habe eine übersichtliche Kalorientracker‑Web‑App für genau eine Nutzerin gebaut: ohne Werbung, ohne Abo und mit einfacher Bedienung. Das Tool berechnet Tageskalorien und Makros automatisch, berücksichtigt Schritte und zeigt einfache Statistiken. Die größte Hürde war die Schritt-Integration: Statt der auslaufenden Google‑Fit‑API nutze ich jetzt Fitbit mit Token‑Refresh. Es gibt bewusst keine öffentliche Demo, da es sich um eine persönliche Lösung mit echten Daten handelt; aktuell feile ich an Design, Barcode‑Scanner und Feinschliff.
Kontext & Ziel
Der Auslöser war ein Gespräch mit einer Freundin: Es gibt unzählige Kalorien‑Apps, aber viele sind überladen, werbelastig oder die besten Features sind hinter Paywalls versteckt. Da ich zu dem Zeitpunkt eine neue Idee für ein Wochenprojekt brauchte, habe ich mich gefragt: wie schwer ist es wohl, so etwas für eine einzelne Nutzerin zu bauen? Ein Werkzeug, das nur die wirklich wichtigen Funktionen bietet und im Alltag nicht im Weg ist. Das Projekt war als Wochenprojekt angelegt und bewusst nicht für den Massenmarkt gedacht, sondern für eine einzelne Person mit eigener, kleiner Lebensmitteldatenbank. Ziel war eine App, die ein tägliches Kalorienbudget berechnet, Makros automatisch verteilt und genug Einblick bietet, um bessere Entscheidungen zu treffen. 🎯
Meine Anforderungen
Übersichtliche Bedienung ohne Werbung oder Abo
Automatische Berechnung von Tageskalorien und Makros
Optionale Anbindung an einen Schrittzähler, damit Aktivität mit einfließt
Lebensmittel und Rezepte selbst anlegen und pflegen
Wenn möglich Lebensmittel per Barcode scannen, ansonsten manuell suchen
Einfache Statistiken, die Fortschritte sichtbar machen
Eine Tagesansicht, die Einträge ordnet
Passwortschutz, damit die Daten privat bleiben
Mein AI-Workflow
Das Brainstormen und die Feature‑Priorisierung habe ich mit Codex gemacht und in einer kurzen HTML‑Dokumentation festgehalten. Für die Umsetzung habe ich mit Claude Code gearbeitet: erst lokal mit einer Datenbank auf meinem Rechner, dann auf meinen Server deployt, damit die Testnutzerin realistisch damit arbeiten kann. Das Beitragsbild für den Blog ist wie gewohnt mit ChatGPT entstanden.
Was das Tool kann
👉 Beim Öffnen landet man direkt auf einer Tagesansicht, die das aktuelle Kalorienbudget zeigt, die bereits gegessenen Kalorien summiert und wie viel „Luft“ noch bleibt.
👉 Neue Einträge fügen sich als Lebensmittel oder als Rezepte hinzu.
👉 Die App berechnet Kalorien und Makros automatisch und ordnet die Einträge so, dass der Tag übersichtlich bleibt.
👉 Die Budgetlogik berücksichtigt nicht nur Grundumsatz und Aktivitätsniveau, sondern auch ein optionales Gewichts‑Ziel. Schritte werden als Bonus in das Tagesbudget eingerechnet.
👉 Lebensmittel lassen sich in einer eigenen Datenbank pflegen. Ein Produkt kann mit Nährwerten pro 100 g hinterlegt werden, optional mit vordefinierten Portionen wie „1 Scheibe“.
👉 Rezepte bestehen aus einzelnen Lebensmitteln und liefern automatisch Nährwerte pro Portion. Wer also das Lieblings‑Porridge zusammenklickt, kann später mit einem Tap „1 Portion“ hinzufügen, ohne Zutatenlisten zu durchforsten.
👉 In den Statistiken sieht man den Gewichtsverlauf, das Kalorienverhalten relativ zum Budget und eine Aufteilung der Makros. Der Zeitraum lässt sich anpassen, sodass sowohl kurze Phasen als auch längere Trends sichtbar werden
👉 Die App ist passwortgeschützt und für genau einen Account gedacht.
Stack & Tools
Frontend: Next.js (React), Tailwind CSS und eine kleine Komponentenbibliothek
Backend: Next.js
Datenbank: lokal eine Datei‑Datenbank, auf dem Server eine MariaDB
APIs: Open Food Facts, Fitbit
Deployment: Containerbasiert mit Docker auf meinem eigenen Server, dahinter ein Reverse Proxy für HTTPS und Routing
Herausforderungen & Learnings
Die geplante Google‑Fit‑Anbindung fiel wegen API‑Abschaltung flach; die Umstellung auf Fitbit lief nach einigem Debuggen endlich mit Refresh‑Token‑Handling. 🔄
Anforderungen zu definieren braucht Zeit. Statt „alle Features der großen Apps“ haben wir die Grundfunktionen priorisiert.
Der Barcode‑Scanner ist noch nicht lauffähig, da werde ich nächste Woche noch debuggen müssen.
Keine Zeit für Design. Ich habe mich erst auf die Funktionalitäten konzentriert. Sobald ich Feedback zur alltäglichen Nutzung habe, wird das Design verbessert.
Keine Live-Demo
Es gibt bewusst keine öffentliche Demo. Die App ist für eine einzelne Nutzerin gebaut und speichert persönliche Daten; sie läuft passwortgeschützt auf meiner eigenen Infrastruktur.
Fazit
Woche 27: ✅
Der CalorieTracker funktioniert im Kern. Die API‑Anbindung an einen Schrittzähler war der kniffligste Teil, läuft jetzt aber zuverlässig. Barcode‑Scan und UI‑Feinschliff sind die nächsten Baustellen. Ich bin gespannt, wie die Nutzerin das Tool im Alltag findet, und welche Änderungen ich dann nächste Woche umsetzen darf. Nächster Schritt ist also: Feedback aus echter Nutzung einarbeiten, den Scanner verbessern und das Design anpassen. ✅
