Eigene Engineering-Arbeit / Web, Mobile & Daten
Foodly
Vom unübersichtlichen Eingang zum nutzbaren Produkt.
Supermarktpreise, Rezepte und Einkaufsentscheidungen liegen in unterschiedlichen Datenwelten. Foodly verbindet Datensammlung und Normalisierung mit Rezeptkosten, Wochenplanung und Einkaufslisten.
Eigene Produktentwicklung. Keine Kundenreferenz.
Die eigentliche Arbeit beginnt vor der Oberfläche.
Produktdaten verschiedener Händler sind nicht automatisch vergleichbar. Bezeichnungen, Preise und die Verbindung zu Rezepten müssen in einen gemeinsamen Zusammenhang gebracht werden.
Foodly setzt deshalb nicht nur bei der Darstellung an. Die Sammlung und Normalisierung der zugrunde liegenden Daten sind Teil des Produkts.
Eine durchgängige Datenstrecke.
Implementiert sind eine Scraping- und Importpipeline, Produkt- und Preishistorie sowie die Normalisierung über Händler hinweg. Aus diesen Daten entstehen Funktionen für Rezeptkosten, Wochenplanung und Einkaufslisten.
Ein ASP.NET-Core-/ .NET-Backend mit PostgreSQL und EF Core bildet die Grundlage. Ein Next.js-Frontend und eine Flutter-App machen die Funktionen auf Web und Mobilgeräten zugänglich. Für ausgewählte Mapping-Aufgaben kommt LLM-Unterstützung zum Einsatz.
End-to-End heißt auch: bis zum Deployment.
Die technische Strecke umfasst Dateneingang, ein konsistentes Modell, Geschäftslogik, Oberflächen und die Bereitstellung über Coolify und GHCR.
Das Projekt zeigt, wie ein datenintensives Produkt als zusammenhängendes System entwickelt wird – mit verschiedenen Oberflächen, aber einer gemeinsamen Grundlage.
Die Daten bleiben eine reale Grenze.
Die technische Umsetzung ist kein Versprechen, dass sämtliche Preise jederzeit aktuell sind oder alle österreichischen Supermärkte abgedeckt werden. Es werden weder eine etablierte Marktdurchdringung noch Nutzerzahlen oder Einsparungen behauptet.
Mehrere Datenquellen. Ein neues Produkt?
Der erste sinnvolle Schritt kann eine belastbare Datenpipeline oder ein kleiner, nutzbarer Produktausschnitt sein.
Über Ihr Vorhaben sprechen