Anfang 2021 entstand innerhalb von CodingPassion die Idee, neben der Dienstleistung auch ein eigenes Produkt zu entwickeln. Als Unternehmen, das großen Wert auf Nachhaltigkeit legt, war unser Gedanke, so unseren positiven Impact in der Welt maximieren zu können. Nach langer Überlegung stand der Beschluss fest, eine vegane Kochbox, mit ausschließlich biologischen Lebensmitteln zu erschaffen. Kochboxen wie HelloFresh, MarleySpoon und co. gibt es bereits viele auf dem Markt, doch eine rein bio-vegane Alternative existierte zu diesem Zeitpunkt noch nicht. Auch erschien uns der Moment passend, da die Nachfrage für vegane Lebensmittel in Deutschland höher war, als jemals zuvor.
Die große Vision hinter Brokkoli umfasste mehr, als nur eine einfach Kochbox. Geplant war ein smarter und nachhaltiger Online-Supermarkt, der es auch Menschen, die nicht in Großstädten wohnen, ermöglicht, bequem und einfach auf ein Sortiment, wie man es bei Alnatura oder Bio Denns findet, zugreifen zu können.
"Also, ich muss sagen, ich bin wirklich begeistert von Brokkoli! Die Idee einer nachhaltigen, veganen Kochbox mit ausschließlich biologischen Lebensmitteln hat mich von Anfang an angesprochen. Und als ich dann das erste Mal bestellt und die Box erhalten habe, war ich einfach nur begeistert. Die Auswahl der Rezepte war super und ich habe wirklich viele neue Gerichte entdeckt, die ich so zuvor noch nicht kannte. Außerdem hat die Qualität der Lebensmittel mich wirklich überzeugt - alles war frisch und von bester Qualität.
Aber nicht nur das Kochen mit Brokkoli hat mir Freude bereitet, sondern auch die App an sich. Sie ist super einfach zu bedienen und ich konnte mein Abonnement und meine Rezepte mit nur wenigen Klicks verwalten. Und als ich mal eine Frage hatte, konnte mir der Kundenservice schnell und freundlich weiterhelfen.Ich bin auf jeden Fall ein großer Fan und kann Brokkoli nur jedem empfehlen, der nach einer nachhaltigen, veganen Kochbox sucht!"
Da unsere Expertise nicht in der Lebensmittelindustrie, sondern in der Software lag beschlossen wir Brokkoli progressiv aufzubauen - gemäß dem Ansatz “Learning by doing”. Dies verschaffte uns enorm viele Vorteile. Zum einen konnten wir unsere App mit einer minimalen Anzahl an Features in den App-und Playstores launchen und weitere Features dann direkt mit Hilfe von Kundenfeedback entwickeln. Da wir selbst noch nicht exakt wussten, worauf unsere Kund:innen am meisten Wert legten, mussten wir durch diesen Ansatz keine umfangreiche App bauen, die nur auf Annahmen basiert.
(Tatsächlich wurde der erste MVP der App innerhalb von weniger als 5 Tagen im Zuge eines Hackathons gebaut und veröffnetlicht.) Weitere Vorteile waren das reduzierte Risko sowie die niedrigeren Kosten, falls sich das Produkt für uns als nicht wirtschaflich oder umsetzbar herrausstellen sollte.
Den ersten Prototyp starteten wir gerade einmal mal folgenden Features:
Unsere Hauptkunden in dieser Iteration bestanden aus Freunden, Familie und ein paar Interessierte von unserer ersten E-Mail Kampagne.
Wie erwartet - und gewollt - unterliefen uns in dieser initialen Phase viele Fehler, aus denen wir lernten und am Ende des Tages ein besseres Produkt erschaffen konnten. Vor allem durch den engen Kontakt zu unseren Kund:innen war es einfach, Probleme schnell zu identifizieren und Verbesserungsvorschläge in den Logistik -und Versandprozess sowie in die App zu integrieren.
Mit Hilfe dieses Prinzips haben wir Brokkoli nicht nur in der Anfangsphase, sondern kontinuierlich verbessert.
Wertvolles Kundenfeedback lässt sich auf unterschiedliche Arten sammeln. Aktives Feedback durch App- und Playstore Reviews, Support E-Mails, etc. können hilfreich sein, reichen aber in der Regel nicht ansatzweise aus. Um ein perfektes Produkt anbieten zu können benötigten wir Feedback zu den Rezepten, zur Lieferung, zur Qualität der Lebensmittel zur Benutzerfreundlichkeit der App, Input zu neuen Features, usw …
Damit wir genau das erreichen, haben wir neben User-Interviews und UX-Tests auch darauf gesetzt, schnelle Rückmeldungen innerhalb der App zu bekommen. Beispielsweise gibt es in der App unter jedem Rezept eine Feedback-Sektion, in der Kund:innen Geschmack und Rezeptanleitung bewerten können. Das war extrem hilfreich, um Gerichte, die kein Anklang fanden auszusortieren und die Anleitungen kontinuierlich zu verbessern.
Ein weiteres Beispiel ist, dass Kund:innen uns Rückmeldungen über verspätete Lieferungen, schlechte oder fehlende Lebensmittel per E-Mail gaben. Das war sowohl für uns, als auch für unsere Nutzer:innen umständlich. Also vereinfachten wir den Prozess und gaben Nutzer:innen die Möglichkeit, Probleme mit der Kochbox ganz einfach innerhalb der App melden zu können. Um den Vorgang für alle noch einfach zu gestalten gaben wir eine vorgefertigte Auswahlmöglichkeit an Problemen, die sehr häufig vorkamen, wie z.B. “Problem mit der Lieferung”, “Qualität der Lebensmittel”, “Fehlende Lebensmittel”, etc. .
Wertvolles Kundenfeedback lässt sich auf unterschiedliche Arten sammeln. Aktives Feedback durch App- und Playstore Reviews, Support E-Mails, etc. können hilfreich sein, reichen aber in der Regel nicht ansatzweise aus. Um ein perfektes Produkt anbieten zu können benötigten wir Feedback zu den Rezepten, zur Lieferung, zur Qualität der Lebensmittel zur Benutzerfreundlichkeit der App, Input zu neuen Features, usw …
Damit wir genau das erreichen, haben wir neben User-Interviews und UX-Tests auch darauf gesetzt, schnelle Rückmeldungen innerhalb der App zu bekommen. Beispielsweise gibt es in der App unter jedem Rezept eine Feedback-Sektion, in der Kund:innen Geschmack und Rezeptanleitung bewerten können. Das war extrem hilfreich, um Gerichte, die kein Anklang fanden auszusortieren und die Anleitungen kontinuierlich zu verbessern.
Ein weiteres Beispiel ist, dass Kund:innen uns Rückmeldungen über verspätete Lieferungen, schlechte oder fehlende Lebensmittel per E-Mail gaben. Das war sowohl für uns, als auch für unsere Nutzer:innen umständlich. Also vereinfachten wir den Prozess und gaben Nutzer:innen die Möglichkeit, Probleme mit der Kochbox ganz einfach innerhalb der App melden zu können. Um den Vorgang für alle noch einfach zu gestalten gaben wir eine vorgefertigte Auswahlmöglichkeit an Problemen, die sehr häufig vorkamen, wie z.B. “Problem mit der Lieferung”, “Qualität der Lebensmittel”, “Fehlende Lebensmittel”, etc. .
Wertvolles Kundenfeedback lässt sich auf unterschiedliche Arten sammeln. Aktives Feedback durch App- und Playstore Reviews, Support E-Mails, etc. können hilfreich sein, reichen aber in der Regel nicht ansatzweise aus. Um ein perfektes Produkt anbieten zu können benötigten wir Feedback zu den Rezepten, zur Lieferung, zur Qualität der Lebensmittel zur Benutzerfreundlichkeit der App, Input zu neuen Features, usw …
Damit wir genau das erreichen, haben wir neben User-Interviews und UX-Tests auch darauf gesetzt, schnelle Rückmeldungen innerhalb der App zu bekommen. Beispielsweise gibt es in der App unter jedem Rezept eine Feedback-Sektion, in der Kund:innen Geschmack und Rezeptanleitung bewerten können. Das war extrem hilfreich, um Gerichte, die kein Anklang fanden auszusortieren und die Anleitungen kontinuierlich zu verbessern.
Ein weiteres Beispiel ist, dass Kund:innen uns Rückmeldungen über verspätete Lieferungen, schlechte oder fehlende Lebensmittel per E-Mail gaben. Das war sowohl für uns, als auch für unsere Nutzer:innen umständlich. Also vereinfachten wir den Prozess und gaben Nutzer:innen die Möglichkeit, Probleme mit der Kochbox ganz einfach innerhalb der App melden zu können. Um den Vorgang für alle noch einfach zu gestalten gaben wir eine vorgefertigte Auswahlmöglichkeit an Problemen, die sehr häufig vorkamen, wie z.B. “Problem mit der Lieferung”, “Qualität der Lebensmittel”, “Fehlende Lebensmittel”, etc. .
Beim Erstellen von großen Features, wie z.B. die Integration unseres Online-Supermarkt Systems, setzten wir vor der Implementierung auf UX-Tests in Userinterviews. Wie ließen also unsere Kund:innen durch einen Klickdummy navigieren und beobachteten dabei, an welchen Stellen sie Probleme hatten und wo noch Verbesserungspotential war. Besonders hilfreich war das auch, um unsere Hypothesen im App-Design zu validieren.
Als User durch unseren Supermarkt scrollten stellten wir z.B. fest, dass die oberen Elemente schwierig mit dem Daumen zu erreichen sind. Dabei kam uns eine ausgefallene, kreative Lösung, von der wir allerdings erst untersuchen mussten, ob Nutzer:innen diese auf Anhieb verstanden. (Abbild. rechts) Wie sich herrausstellte war unsere Hypothese richtig und unsere Kund:innen verstanden die ungewöhnliche UI-Komponente und aktzeptierten sie ohne Probleme.
Ein weiteres einleuchtendes Beispiel ist die in der App integrierte Timer Funktion. Beim Nachkochen von Rezepten viel uns auf, dass User oft zwischen ihrer eigenen Timer-App und der Brokkoli-App wechselten, wenn ein Kochtimer wie z.B. für Spagehtti benötigt wurde. Vor allem, wenn ihr eigener Herd über keine Timer-Funktion verfügte. Interessanterweise fehlte diese Funktion in anderen Kochbox-Apps ebenfalls. Wir bauten den Timer jedoch innerhalb von 2 Wochen ein und verbesserten damit die Experience beim Kochen.
Weitere Änderungen die wir an der App vornahmen, nachdem sie uns in UX-Tests auffielen waren:
Auch neben dem Aspekt der Benutzerfreundlichkeit fanden wir zahlreiche Features, die unsere Kund:innen sich wünschten. Ein gutes Beispiel hierfür ist die Nährwertangabe zu den Rezepten. In Interviews mit unserer Zielgruppe fiel uns immer wieder auf, dass diese sehr viel Wert auf eine gesunde, ausgewogene Ernährung achtete oder spezielle Diäten verfolgte, bei denen Nährwerte eine wichtige Rolle spielten. Da es mit einem gewissen Aufwand verbunden war, zu jedem Rezept die Nährwerte akribisch auszurechnen, entschieden wir uns zu Beginn dagegen, dieses Feature einzubauen. Doch nachdem so viele User Interviews zeigten, wie wichtig es unseren Kund:innen war, implementierten wir es letzendlich.
Beim Erstellen von großen Features, wie z.B. die Integration unseres Online-Supermarkt Systems, setzten wir vor der Implementierung auf UX-Tests in Userinterviews. Wie ließen also unsere Kund:innen durch einen Klickdummy navigieren und beobachteten dabei, an welchen Stellen sie Probleme hatten und wo noch Verbesserungspotential war. Besonders hilfreich war das auch, um unsere Hypothesen im App-Design zu validieren.
Als User durch unseren Supermarkt scrollten stellten wir z.B. fest, dass die oberen Elemente schwierig mit dem Daumen zu erreichen sind. Dabei kam uns eine ausgefallene, kreative Lösung, von der wir allerdings erst untersuchen mussten, ob Nutzer:innen diese auf Anhieb verstanden. (Abbild. rechts) Wie sich herrausstellte war unsere Hypothese richtig und unsere Kund:innen verstanden die ungewöhnliche UI-Komponente und aktzeptierten sie ohne Probleme.
Ein weiteres einleuchtendes Beispiel ist die in der App integrierte Timer Funktion. Beim Nachkochen von Rezepten viel uns auf, dass User oft zwischen ihrer eigenen Timer-App und der Brokkoli-App wechselten, wenn ein Kochtimer wie z.B. für Spagehtti benötigt wurde. Vor allem, wenn ihr eigener Herd über keine Timer-Funktion verfügte. Interessanterweise fehlte diese Funktion in anderen Kochbox-Apps ebenfalls. Wir bauten den Timer jedoch innerhalb von 2 Wochen ein und verbesserten damit die Experience beim Kochen.
Weitere Änderungen die wir an der App vornahmen, nachdem sie uns in UX-Tests auffielen waren:
Auch neben dem Aspekt der Benutzerfreundlichkeit fanden wir zahlreiche Features, die unsere Kund:innen sich wünschten. Ein gutes Beispiel hierfür ist die Nährwertangabe zu den Rezepten. In Interviews mit unserer Zielgruppe fiel uns immer wieder auf, dass diese sehr viel Wert auf eine gesunde, ausgewogene Ernährung achtete oder spezielle Diäten verfolgte, bei denen Nährwerte eine wichtige Rolle spielten. Da es mit einem gewissen Aufwand verbunden war, zu jedem Rezept die Nährwerte akribisch auszurechnen, entschieden wir uns zu Beginn dagegen, dieses Feature einzubauen. Doch nachdem so viele User Interviews zeigten, wie wichtig es unseren Kund:innen war, implementierten wir es letzendlich.
Beim Erstellen von großen Features, wie z.B. die Integration unseres Online-Supermarkt Systems, setzten wir vor der Implementierung auf UX-Tests in Userinterviews. Wie ließen also unsere Kund:innen durch einen Klickdummy navigieren und beobachteten dabei, an welchen Stellen sie Probleme hatten und wo noch Verbesserungspotential war. Besonders hilfreich war das auch, um unsere Hypothesen im App-Design zu validieren.
Als User durch unseren Supermarkt scrollten stellten wir z.B. fest, dass die oberen Elemente schwierig mit dem Daumen zu erreichen sind. Dabei kam uns eine ausgefallene, kreative Lösung, von der wir allerdings erst untersuchen mussten, ob Nutzer:innen diese auf Anhieb verstanden. (Abbild. rechts) Wie sich herrausstellte war unsere Hypothese richtig und unsere Kund:innen verstanden die ungewöhnliche UI-Komponente und aktzeptierten sie ohne Probleme.
Ein weiteres einleuchtendes Beispiel ist die in der App integrierte Timer Funktion. Beim Nachkochen von Rezepten viel uns auf, dass User oft zwischen ihrer eigenen Timer-App und der Brokkoli-App wechselten, wenn ein Kochtimer wie z.B. für Spagehtti benötigt wurde. Vor allem, wenn ihr eigener Herd über keine Timer-Funktion verfügte. Interessanterweise fehlte diese Funktion in anderen Kochbox-Apps ebenfalls. Wir bauten den Timer jedoch innerhalb von 2 Wochen ein und verbesserten damit die Experience beim Kochen.
Weitere Änderungen die wir an der App vornahmen, nachdem sie uns in UX-Tests auffielen waren:
Auch neben dem Aspekt der Benutzerfreundlichkeit fanden wir zahlreiche Features, die unsere Kund:innen sich wünschten. Ein gutes Beispiel hierfür ist die Nährwertangabe zu den Rezepten. In Interviews mit unserer Zielgruppe fiel uns immer wieder auf, dass diese sehr viel Wert auf eine gesunde, ausgewogene Ernährung achtete oder spezielle Diäten verfolgte, bei denen Nährwerte eine wichtige Rolle spielten. Da es mit einem gewissen Aufwand verbunden war, zu jedem Rezept die Nährwerte akribisch auszurechnen, entschieden wir uns zu Beginn dagegen, dieses Feature einzubauen. Doch nachdem so viele User Interviews zeigten, wie wichtig es unseren Kund:innen war, implementierten wir es letzendlich.
Ein Pain-point, den wir hatten, war die zu geringe Conversion-Rate in unserem Onboarding-Prozess. Allerdings war uns nicht zu 100% klar, wodurch diese entstand, da zu viele Faktoren darauf einspielen konnten (z.B. Kochbox-Preis, kompliziertes Preismodell, Onboarding-UI, Lieferinformationen, Abrechnung,…). Als KPI setzten wir uns, die Conversion-Rate um mindestens 30% zu steigern.
Um verstehen zu können, wie Nutzer:innen durch die App navigieren, an welchem Punkt im Onboarding sie abspringen und daraus wiederum neue Hypothesen aufstellen zu können brauchten wir eine Möglichkeit, der User-Flow zu tracken. Aus diesen Hypothesen wiederum konnten wir dann neue Features und Verbesserungen ableiten, die wir wiederum validieren konnten.
Beispielsweise hatte der ursprüngliche Onboarding-Prozess 4 aufeinanderfolgende Schritte mit eigenen Screens. Auf dem ersten Screen konnten Nutzer:innen die Rezepte (und Rezeptanzahl) für die erste Woche auswählen. In Schritt 2 konnten sie dann die entsprechende Portionszahl dazu auswählen, wo auch der entsprechende Preis angezeigt wurde. Über User-Flow Diagramme stellten wir fest, dass an dieser Stelle eine gewissen Absprungrate gegeben war, die höher war, als erwartet. Unsere Vermutung war es, dass es für Nutzer:innen verständlicher war, wenn wir Rezept- und Portionsauswahl auf einem Screen anzeigen und passten die App dahingehend an. Auch in User-Interviews konnten wir feststellen, dass den Nutzer:innen noch viel Kontext zu Brokkoli fehlte. Wir entschieden uns dazu, zusätzlich ein kurzes Erklärvideo am Anfang der App abzuspielen, in dem alle häufig gestellten Fragen geklärt wurden.Das Endergebnis war, dass wir das von uns gesetzte Ziel, die Conversion-Rate um 30% zu erhöhen, erreichten, was uns ohne die entsprechenden Daten vermutlich nicht möglich gewesen wäre.
Ein Pain-point, den wir hatten, war die zu geringe Conversion-Rate in unserem Onboarding-Prozess. Allerdings war uns nicht zu 100% klar, wodurch diese entstand, da zu viele Faktoren darauf einspielen konnten (z.B. Kochbox-Preis, kompliziertes Preismodell, Onboarding-UI, Lieferinformationen, Abrechnung,…). Als KPI setzten wir uns, die Conversion-Rate um mindestens 30% zu steigern.
Um verstehen zu können, wie Nutzer:innen durch die App navigieren, an welchem Punkt im Onboarding sie abspringen und daraus wiederum neue Hypothesen aufstellen zu können brauchten wir eine Möglichkeit, der User-Flow zu tracken. Aus diesen Hypothesen wiederum konnten wir dann neue Features und Verbesserungen ableiten, die wir wiederum validieren konnten.
Beispielsweise hatte der ursprüngliche Onboarding-Prozess 4 aufeinanderfolgende Schritte mit eigenen Screens. Auf dem ersten Screen konnten Nutzer:innen die Rezepte (und Rezeptanzahl) für die erste Woche auswählen. In Schritt 2 konnten sie dann die entsprechende Portionszahl dazu auswählen, wo auch der entsprechende Preis angezeigt wurde. Über User-Flow Diagramme stellten wir fest, dass an dieser Stelle eine gewissen Absprungrate gegeben war, die höher war, als erwartet. Unsere Vermutung war es, dass es für Nutzer:innen verständlicher war, wenn wir Rezept- und Portionsauswahl auf einem Screen anzeigen und passten die App dahingehend an. Auch in User-Interviews konnten wir feststellen, dass den Nutzer:innen noch viel Kontext zu Brokkoli fehlte. Wir entschieden uns dazu, zusätzlich ein kurzes Erklärvideo am Anfang der App abzuspielen, in dem alle häufig gestellten Fragen geklärt wurden.Das Endergebnis war, dass wir das von uns gesetzte Ziel, die Conversion-Rate um 30% zu erhöhen, erreichten, was uns ohne die entsprechenden Daten vermutlich nicht möglich gewesen wäre.
Ein Pain-point, den wir hatten, war die zu geringe Conversion-Rate in unserem Onboarding-Prozess. Allerdings war uns nicht zu 100% klar, wodurch diese entstand, da zu viele Faktoren darauf einspielen konnten (z.B. Kochbox-Preis, kompliziertes Preismodell, Onboarding-UI, Lieferinformationen, Abrechnung,…). Als KPI setzten wir uns, die Conversion-Rate um mindestens 30% zu steigern.
Um verstehen zu können, wie Nutzer:innen durch die App navigieren, an welchem Punkt im Onboarding sie abspringen und daraus wiederum neue Hypothesen aufstellen zu können brauchten wir eine Möglichkeit, der User-Flow zu tracken. Aus diesen Hypothesen wiederum konnten wir dann neue Features und Verbesserungen ableiten, die wir wiederum validieren konnten.
Beispielsweise hatte der ursprüngliche Onboarding-Prozess 4 aufeinanderfolgende Schritte mit eigenen Screens. Auf dem ersten Screen konnten Nutzer:innen die Rezepte (und Rezeptanzahl) für die erste Woche auswählen. In Schritt 2 konnten sie dann die entsprechende Portionszahl dazu auswählen, wo auch der entsprechende Preis angezeigt wurde. Über User-Flow Diagramme stellten wir fest, dass an dieser Stelle eine gewissen Absprungrate gegeben war, die höher war, als erwartet. Unsere Vermutung war es, dass es für Nutzer:innen verständlicher war, wenn wir Rezept- und Portionsauswahl auf einem Screen anzeigen und passten die App dahingehend an. Auch in User-Interviews konnten wir feststellen, dass den Nutzer:innen noch viel Kontext zu Brokkoli fehlte. Wir entschieden uns dazu, zusätzlich ein kurzes Erklärvideo am Anfang der App abzuspielen, in dem alle häufig gestellten Fragen geklärt wurden.Das Endergebnis war, dass wir das von uns gesetzte Ziel, die Conversion-Rate um 30% zu erhöhen, erreichten, was uns ohne die entsprechenden Daten vermutlich nicht möglich gewesen wäre.
In der IT-Branche sieht man sehr oft den Fehler, dass Entwickler versuchen, das Rad neuzuerfinden. Gemeint ist damit, dass generische Funktionalitäten wie z.B. User-Authentifizierung und eine dazugehörige Anmeldeseite häufig In-House entwickelt wird, obwohl es genau hierfür bereits ausgereifte SaaS Produkte gibt. Durch den Einkauf solcher Software-Produkte spart man sich für gewöhnlich sehr viel Zeit und Kosten und kann sich auf die eigentlich wichtigen Business-Cases konzentrieren.
Als Extrembeispiel haben wir bei Brokkoli Auth0, ein Service für Authentication und Authorization, verwendet, statt die Funktionalität selbst zu entwickeln oder über OpenSource Projekte wie Keycloak zu integrieren (was zusätzlichen Wartungsaufwand bedeuten würde). Durch Auth0 bekamen wir out-of-the-box eine einfach zu konfigurierende web-basierte Anmeldeseite, auf der sich Nutzer registrieren und einloggen konnten. Der Entwicklungsaufwand auf unserer Seite, ohne Auth0, wäre vermutlich 10-15 Tage gewesen. Der Service dagegen kostete uns nicht einen Cent, da der Free-Plan für den Anfang völlig ausreichend war.
Noch interessanter war die Entscheidung, Retool als Back-Office Tool zu verwenden, statt selbst eine Adminoberfläche zu bauen. Viele Apps benötigen neben der mobilen Anwendung selbst noch ein Web-Portal, auf dem Mitarbeiter administrative Aufgaben erledigen können. Darunter fällt klassische Nutzerverwaltung, Supportaufgaben, wie bei uns zum Beispiel das Auswerten von Rezepte-Feedback und Problemmeldungen mit der Box, oder das Auslesen von Bestellungen in der Produktion.
Diese Administrationsportale können schnell sehr umfangreich werden und einen erheblichen Aufwand in der Entwicklung darstellen.Was viele allerdings nicht wissen ist, dass für den Bau solcher generischer Portale bereits Software existiert, durch die man sich 90% des Programmieraufwands sparen. Mit Retool zum Beispiel kann man sich die gewünschte Weboberfläche unglaublich schnell zusammenklicken und die gewünschte Funktionalität mit ein wenig JavaScript und SQL implementieren.
In der IT-Branche sieht man sehr oft den Fehler, dass Entwickler versuchen, das Rad neuzuerfinden. Gemeint ist damit, dass generische Funktionalitäten wie z.B. User-Authentifizierung und eine dazugehörige Anmeldeseite häufig In-House entwickelt wird, obwohl es genau hierfür bereits ausgereifte SaaS Produkte gibt. Durch den Einkauf solcher Software-Produkte spart man sich für gewöhnlich sehr viel Zeit und Kosten und kann sich auf die eigentlich wichtigen Business-Cases konzentrieren.
Als Extrembeispiel haben wir bei Brokkoli Auth0, ein Service für Authentication und Authorization, verwendet, statt die Funktionalität selbst zu entwickeln oder über OpenSource Projekte wie Keycloak zu integrieren (was zusätzlichen Wartungsaufwand bedeuten würde). Durch Auth0 bekamen wir out-of-the-box eine einfach zu konfigurierende web-basierte Anmeldeseite, auf der sich Nutzer registrieren und einloggen konnten. Der Entwicklungsaufwand auf unserer Seite, ohne Auth0, wäre vermutlich 10-15 Tage gewesen. Der Service dagegen kostete uns nicht einen Cent, da der Free-Plan für den Anfang völlig ausreichend war.
Noch interessanter war die Entscheidung, Retool als Back-Office Tool zu verwenden, statt selbst eine Adminoberfläche zu bauen. Viele Apps benötigen neben der mobilen Anwendung selbst noch ein Web-Portal, auf dem Mitarbeiter administrative Aufgaben erledigen können. Darunter fällt klassische Nutzerverwaltung, Supportaufgaben, wie bei uns zum Beispiel das Auswerten von Rezepte-Feedback und Problemmeldungen mit der Box, oder das Auslesen von Bestellungen in der Produktion.
Diese Administrationsportale können schnell sehr umfangreich werden und einen erheblichen Aufwand in der Entwicklung darstellen.Was viele allerdings nicht wissen ist, dass für den Bau solcher generischer Portale bereits Software existiert, durch die man sich 90% des Programmieraufwands sparen. Mit Retool zum Beispiel kann man sich die gewünschte Weboberfläche unglaublich schnell zusammenklicken und die gewünschte Funktionalität mit ein wenig JavaScript und SQL implementieren.
In der IT-Branche sieht man sehr oft den Fehler, dass Entwickler versuchen, das Rad neuzuerfinden. Gemeint ist damit, dass generische Funktionalitäten wie z.B. User-Authentifizierung und eine dazugehörige Anmeldeseite häufig In-House entwickelt wird, obwohl es genau hierfür bereits ausgereifte SaaS Produkte gibt. Durch den Einkauf solcher Software-Produkte spart man sich für gewöhnlich sehr viel Zeit und Kosten und kann sich auf die eigentlich wichtigen Business-Cases konzentrieren.
Als Extrembeispiel haben wir bei Brokkoli Auth0, ein Service für Authentication und Authorization, verwendet, statt die Funktionalität selbst zu entwickeln oder über OpenSource Projekte wie Keycloak zu integrieren (was zusätzlichen Wartungsaufwand bedeuten würde). Durch Auth0 bekamen wir out-of-the-box eine einfach zu konfigurierende web-basierte Anmeldeseite, auf der sich Nutzer registrieren und einloggen konnten. Der Entwicklungsaufwand auf unserer Seite, ohne Auth0, wäre vermutlich 10-15 Tage gewesen. Der Service dagegen kostete uns nicht einen Cent, da der Free-Plan für den Anfang völlig ausreichend war.
Noch interessanter war die Entscheidung, Retool als Back-Office Tool zu verwenden, statt selbst eine Adminoberfläche zu bauen. Viele Apps benötigen neben der mobilen Anwendung selbst noch ein Web-Portal, auf dem Mitarbeiter administrative Aufgaben erledigen können. Darunter fällt klassische Nutzerverwaltung, Supportaufgaben, wie bei uns zum Beispiel das Auswerten von Rezepte-Feedback und Problemmeldungen mit der Box, oder das Auslesen von Bestellungen in der Produktion.
Diese Administrationsportale können schnell sehr umfangreich werden und einen erheblichen Aufwand in der Entwicklung darstellen.Was viele allerdings nicht wissen ist, dass für den Bau solcher generischer Portale bereits Software existiert, durch die man sich 90% des Programmieraufwands sparen. Mit Retool zum Beispiel kann man sich die gewünschte Weboberfläche unglaublich schnell zusammenklicken und die gewünschte Funktionalität mit ein wenig JavaScript und SQL implementieren.
Auch auf Entwicklungsseite haben wir uns nach langer Überlegung dazu entschieden, vieles komplett anders zu machen, als es einige konservativere Softwareentwicklungs Unternehmen machen würden.
Hinweis: Viele Informationen in diesem Abschnitt sind für Personen, die nicht aus der IT-Branche kommen unter Umständen schwer zu verstehen. Eine ausführliche Erklärung der Begrifflichkeiten würde aber leider den Rahmen dieser Customer Story sprengen. Wir planen jedoch eine ausführlichere Erklärung zu unserem außergewöhnlichen Entwicklungsprozesses in weiteren Blog-Artikeln.
Eine Sache, die uns in vergangenen Projekte aufgefallen ist, war dass die Wartung verschiedener Entwicklungsumgebungen (Staging, Integration, QS, …) zu viel Zeit und Nerven in Anspruch nimmt. Meistens sogar soviel, dass die Kosten den Nutzen deutlich überwiegen. Auch wird der Release-Cycle dadurch schnell komplexer und länger.Wir schlugen also einen konträren Weg ein und verzichteten auf alle zusätzlichen (nicht lokalen) Umgebungen. Und das Ergebnis war besser als wir es uns anfangs vorstellen konnten.
Der Performance-Boost, den wir dadruch erreicht haben, lässt sich am besten veranschaulichen, wenn man einen Blick auf unseren (veränderten) Entwicklungsprozess wirft:
Aus reiner Frontend-Sicht hätte das Programmieren nicht angenehmer sein können.
Auch die Backendentwicklung gestaltete sich als unkompliziert. Um die Produktion-Datenbank nicht versehentlich beim Entwickeln zu zerstören, hat jeder Entwickler einen eigenen Klon der Datenbank bekommen. Es konnte also ganz einfach mit echten Daten getestet werden und Bugs ließen dadurch sehr schnell reproduzieren.
Besonders interessant war unser automatisierter QA & Release-Prozess. Nachdem ein neues Feature entwickelt wurde und der dazugehörige Pull-Request (eine Anfrage, den neuen Code in die bestehende Code-Basis zu integrieren) erstellt und erfolgreich reviewed wurde, wurde die neue Version nicht erst auf einer Integrations-Umgebung deployed und manuell von QA-Engineers auf Fehler geprüft, wie es bei den meisten anderen Softwareentwicklungs Unternehmen der Fall ist. Bei uns liefen automatisierte Tests, die die Applikation ausgiebig auf Korrektheit testeten und nachdem diese Tests erfolgreich waren, wurde der neue Codestand sofort im Appstore / Playstore oder auf Azure veröffentlicht. Die durchschnittliche Zeit von der Fertigstellung eines Features bis zum Release redurzierte sich dadurch von Wochen auf Minuten bis Stunden. Das sorgte nicht nur für zufriedene Entwickler:innen, sondern vor allem auch für zufriedene Kund:innen und Stakeholder.
Neben den offensichtlichen Vorteilen gab es noch viele andere positive Aspekte und Learnings, die den Rahmen dieser Customer Story leider sprengen würden. Wenn du mehr über Testing on Production erfahren willst empfehle ich dir unseren Blog Artikel.
Auch auf Entwicklungsseite haben wir uns nach langer Überlegung dazu entschieden, vieles komplett anders zu machen, als es einige konservativere Softwareentwicklungs Unternehmen machen würden.
Hinweis: Viele Informationen in diesem Abschnitt sind für Personen, die nicht aus der IT-Branche kommen unter Umständen schwer zu verstehen. Eine ausführliche Erklärung der Begrifflichkeiten würde aber leider den Rahmen dieser Customer Story sprengen. Wir planen jedoch eine ausführlichere Erklärung zu unserem außergewöhnlichen Entwicklungsprozesses in weiteren Blog-Artikeln.
Eine Sache, die uns in vergangenen Projekte aufgefallen ist, war dass die Wartung verschiedener Entwicklungsumgebungen (Staging, Integration, QS, …) zu viel Zeit und Nerven in Anspruch nimmt. Meistens sogar soviel, dass die Kosten den Nutzen deutlich überwiegen. Auch wird der Release-Cycle dadurch schnell komplexer und länger.Wir schlugen also einen konträren Weg ein und verzichteten auf alle zusätzlichen (nicht lokalen) Umgebungen. Und das Ergebnis war besser als wir es uns anfangs vorstellen konnten.
Der Performance-Boost, den wir dadruch erreicht haben, lässt sich am besten veranschaulichen, wenn man einen Blick auf unseren (veränderten) Entwicklungsprozess wirft:
Aus reiner Frontend-Sicht hätte das Programmieren nicht angenehmer sein können.
Auch die Backendentwicklung gestaltete sich als unkompliziert. Um die Produktion-Datenbank nicht versehentlich beim Entwickeln zu zerstören, hat jeder Entwickler einen eigenen Klon der Datenbank bekommen. Es konnte also ganz einfach mit echten Daten getestet werden und Bugs ließen dadurch sehr schnell reproduzieren.
Besonders interessant war unser automatisierter QA & Release-Prozess. Nachdem ein neues Feature entwickelt wurde und der dazugehörige Pull-Request (eine Anfrage, den neuen Code in die bestehende Code-Basis zu integrieren) erstellt und erfolgreich reviewed wurde, wurde die neue Version nicht erst auf einer Integrations-Umgebung deployed und manuell von QA-Engineers auf Fehler geprüft, wie es bei den meisten anderen Softwareentwicklungs Unternehmen der Fall ist. Bei uns liefen automatisierte Tests, die die Applikation ausgiebig auf Korrektheit testeten und nachdem diese Tests erfolgreich waren, wurde der neue Codestand sofort im Appstore / Playstore oder auf Azure veröffentlicht. Die durchschnittliche Zeit von der Fertigstellung eines Features bis zum Release redurzierte sich dadurch von Wochen auf Minuten bis Stunden. Das sorgte nicht nur für zufriedene Entwickler:innen, sondern vor allem auch für zufriedene Kund:innen und Stakeholder.
Neben den offensichtlichen Vorteilen gab es noch viele andere positive Aspekte und Learnings, die den Rahmen dieser Customer Story leider sprengen würden. Wenn du mehr über Testing on Production erfahren willst empfehle ich dir unseren Blog Artikel.
Auch auf Entwicklungsseite haben wir uns nach langer Überlegung dazu entschieden, vieles komplett anders zu machen, als es einige konservativere Softwareentwicklungs Unternehmen machen würden.
Hinweis: Viele Informationen in diesem Abschnitt sind für Personen, die nicht aus der IT-Branche kommen unter Umständen schwer zu verstehen. Eine ausführliche Erklärung der Begrifflichkeiten würde aber leider den Rahmen dieser Customer Story sprengen. Wir planen jedoch eine ausführlichere Erklärung zu unserem außergewöhnlichen Entwicklungsprozesses in weiteren Blog-Artikeln.
Eine Sache, die uns in vergangenen Projekte aufgefallen ist, war dass die Wartung verschiedener Entwicklungsumgebungen (Staging, Integration, QS, …) zu viel Zeit und Nerven in Anspruch nimmt. Meistens sogar soviel, dass die Kosten den Nutzen deutlich überwiegen. Auch wird der Release-Cycle dadurch schnell komplexer und länger.Wir schlugen also einen konträren Weg ein und verzichteten auf alle zusätzlichen (nicht lokalen) Umgebungen. Und das Ergebnis war besser als wir es uns anfangs vorstellen konnten.
Der Performance-Boost, den wir dadruch erreicht haben, lässt sich am besten veranschaulichen, wenn man einen Blick auf unseren (veränderten) Entwicklungsprozess wirft:
Aus reiner Frontend-Sicht hätte das Programmieren nicht angenehmer sein können.
Auch die Backendentwicklung gestaltete sich als unkompliziert. Um die Produktion-Datenbank nicht versehentlich beim Entwickeln zu zerstören, hat jeder Entwickler einen eigenen Klon der Datenbank bekommen. Es konnte also ganz einfach mit echten Daten getestet werden und Bugs ließen dadurch sehr schnell reproduzieren.
Besonders interessant war unser automatisierter QA & Release-Prozess. Nachdem ein neues Feature entwickelt wurde und der dazugehörige Pull-Request (eine Anfrage, den neuen Code in die bestehende Code-Basis zu integrieren) erstellt und erfolgreich reviewed wurde, wurde die neue Version nicht erst auf einer Integrations-Umgebung deployed und manuell von QA-Engineers auf Fehler geprüft, wie es bei den meisten anderen Softwareentwicklungs Unternehmen der Fall ist. Bei uns liefen automatisierte Tests, die die Applikation ausgiebig auf Korrektheit testeten und nachdem diese Tests erfolgreich waren, wurde der neue Codestand sofort im Appstore / Playstore oder auf Azure veröffentlicht. Die durchschnittliche Zeit von der Fertigstellung eines Features bis zum Release redurzierte sich dadurch von Wochen auf Minuten bis Stunden. Das sorgte nicht nur für zufriedene Entwickler:innen, sondern vor allem auch für zufriedene Kund:innen und Stakeholder.
Neben den offensichtlichen Vorteilen gab es noch viele andere positive Aspekte und Learnings, die den Rahmen dieser Customer Story leider sprengen würden. Wenn du mehr über Testing on Production erfahren willst empfehle ich dir unseren Blog Artikel.
Ohne Kochbox, keine Kochbox. Irgendwie und vor allem irgendwo mussten wir die Lebensmittel lagern, verpacken und versenden. Daniels Eltern hatten früher eine Hof-Metzgerei, wo wir glücklicherweise die Räumlichkeiten verwenden konnten. Dort wo früher also Bratwurst-Hack im Regal stand, lagen jetzt die Karotten und Gurken. Irgendwie war das ein sehr schönes Zeichen wie Transformation gut gelingen kann. Das die Räume von dem Gesundheitsamt bereits geprüft waren hat uns dann auch sehr in die Karten gespielt.
Innerhalb kürzester Zeit durften wir uns aneignen, wie Lebensmittel effizient eingekauft werden, richtig gelagert werden, passend verpackt und sicher versendet werden. Die gesamte Lebensmittel Lieferkette eben.
Um den Pick und Pack Prozess zu vereinfachen, haben wir uns mit Retool eine sehr einfache und effiziente Unterstützung gebaut. Software eben - das läuft bei uns🙂
Doch mit anderen Herausforderungen haben wir nicht gerechnet. So waren wir zum Beispiel sehr überrascht und gefordert
An unserem allerersten Produktionstag haben wir zu viert knapp 8h gebraucht um die Boxen fertig zu haben. Nach ein paar Monaten schafften wir dann 100 Boxen zu Zweit 💪.
Raus aus der Software, waren wir auch plötzlich sehr lokal und regional in Geschäftsbeziehungen aktiv, um das alles realisieren zu können. Ganz besonders möchten wir hier dem Bioland Hof Sinke aus Weinsfeld und dem Ohne Laden in Hilpoltstein danken, die uns von Anfang an so super tatkräftig unterstützt haben die Lebensmittel zur richtigen Zeit an den richtigen Ort zu bekommen.
Ohne Kochbox, keine Kochbox. Irgendwie und vor allem irgendwo mussten wir die Lebensmittel lagern, verpacken und versenden. Daniels Eltern hatten früher eine Hof-Metzgerei, wo wir glücklicherweise die Räumlichkeiten verwenden konnten. Dort wo früher also Bratwurst-Hack im Regal stand, lagen jetzt die Karotten und Gurken. Irgendwie war das ein sehr schönes Zeichen wie Transformation gut gelingen kann. Das die Räume von dem Gesundheitsamt bereits geprüft waren hat uns dann auch sehr in die Karten gespielt.
Innerhalb kürzester Zeit durften wir uns aneignen, wie Lebensmittel effizient eingekauft werden, richtig gelagert werden, passend verpackt und sicher versendet werden. Die gesamte Lebensmittel Lieferkette eben.
Um den Pick und Pack Prozess zu vereinfachen, haben wir uns mit Retool eine sehr einfache und effiziente Unterstützung gebaut. Software eben - das läuft bei uns🙂
Doch mit anderen Herausforderungen haben wir nicht gerechnet. So waren wir zum Beispiel sehr überrascht und gefordert
An unserem allerersten Produktionstag haben wir zu viert knapp 8h gebraucht um die Boxen fertig zu haben. Nach ein paar Monaten schafften wir dann 100 Boxen zu Zweit 💪.
Raus aus der Software, waren wir auch plötzlich sehr lokal und regional in Geschäftsbeziehungen aktiv, um das alles realisieren zu können. Ganz besonders möchten wir hier dem Bioland Hof Sinke aus Weinsfeld und dem Ohne Laden in Hilpoltstein danken, die uns von Anfang an so super tatkräftig unterstützt haben die Lebensmittel zur richtigen Zeit an den richtigen Ort zu bekommen.
Ohne Kochbox, keine Kochbox. Irgendwie und vor allem irgendwo mussten wir die Lebensmittel lagern, verpacken und versenden. Daniels Eltern hatten früher eine Hof-Metzgerei, wo wir glücklicherweise die Räumlichkeiten verwenden konnten. Dort wo früher also Bratwurst-Hack im Regal stand, lagen jetzt die Karotten und Gurken. Irgendwie war das ein sehr schönes Zeichen wie Transformation gut gelingen kann. Das die Räume von dem Gesundheitsamt bereits geprüft waren hat uns dann auch sehr in die Karten gespielt.
Innerhalb kürzester Zeit durften wir uns aneignen, wie Lebensmittel effizient eingekauft werden, richtig gelagert werden, passend verpackt und sicher versendet werden. Die gesamte Lebensmittel Lieferkette eben.
Um den Pick und Pack Prozess zu vereinfachen, haben wir uns mit Retool eine sehr einfache und effiziente Unterstützung gebaut. Software eben - das läuft bei uns🙂
Doch mit anderen Herausforderungen haben wir nicht gerechnet. So waren wir zum Beispiel sehr überrascht und gefordert
An unserem allerersten Produktionstag haben wir zu viert knapp 8h gebraucht um die Boxen fertig zu haben. Nach ein paar Monaten schafften wir dann 100 Boxen zu Zweit 💪.
Raus aus der Software, waren wir auch plötzlich sehr lokal und regional in Geschäftsbeziehungen aktiv, um das alles realisieren zu können. Ganz besonders möchten wir hier dem Bioland Hof Sinke aus Weinsfeld und dem Ohne Laden in Hilpoltstein danken, die uns von Anfang an so super tatkräftig unterstützt haben die Lebensmittel zur richtigen Zeit an den richtigen Ort zu bekommen.
Einer der mit Abstand coolsten Tasks für das Entwicklerteam war die Entwicklung des gesamten Online-Supermarkts. Im Gegensatz zur Remotearbeit haben wir uns hierbei nämlich dazu entschieden, einen 2-wöchigen Hackathon in Kroatien zu machen, um diese Monsteraufgabe innerhalb von kürzester Zeit zu erledigen. Da unser erster Hackthon, in dem wir den MVP von Brokkoli entwickelt hatten, bereits so erfolgreich war, waren wir voller Hoffnung, diesen Erfolg reproduzieren zu können. Und tatsächlich hat alles so geklappt, wie wir es uns vorgestellt haben. Der Teamspirit und Feature-Output hätte in dieser Zeit kaum höher sein können. Durch erklassige Koordination und Zusammenarbeit integrierten wir ein komplettes Shoppingsystem in die Brokkoli App, die davor nur für ein Kochbox-Abomodell ausgelegt war.
Einer der mit Abstand coolsten Tasks für das Entwicklerteam war die Entwicklung des gesamten Online-Supermarkts. Im Gegensatz zur Remotearbeit haben wir uns hierbei nämlich dazu entschieden, einen 2-wöchigen Hackathon in Kroatien zu machen, um diese Monsteraufgabe innerhalb von kürzester Zeit zu erledigen. Da unser erster Hackthon, in dem wir den MVP von Brokkoli entwickelt hatten, bereits so erfolgreich war, waren wir voller Hoffnung, diesen Erfolg reproduzieren zu können. Und tatsächlich hat alles so geklappt, wie wir es uns vorgestellt haben. Der Teamspirit und Feature-Output hätte in dieser Zeit kaum höher sein können. Durch erklassige Koordination und Zusammenarbeit integrierten wir ein komplettes Shoppingsystem in die Brokkoli App, die davor nur für ein Kochbox-Abomodell ausgelegt war.
Einer der mit Abstand coolsten Tasks für das Entwicklerteam war die Entwicklung des gesamten Online-Supermarkts. Im Gegensatz zur Remotearbeit haben wir uns hierbei nämlich dazu entschieden, einen 2-wöchigen Hackathon in Kroatien zu machen, um diese Monsteraufgabe innerhalb von kürzester Zeit zu erledigen. Da unser erster Hackthon, in dem wir den MVP von Brokkoli entwickelt hatten, bereits so erfolgreich war, waren wir voller Hoffnung, diesen Erfolg reproduzieren zu können. Und tatsächlich hat alles so geklappt, wie wir es uns vorgestellt haben. Der Teamspirit und Feature-Output hätte in dieser Zeit kaum höher sein können. Durch erklassige Koordination und Zusammenarbeit integrierten wir ein komplettes Shoppingsystem in die Brokkoli App, die davor nur für ein Kochbox-Abomodell ausgelegt war.
Die nachzukochenden vegangen Gerichte wurden auf einem Gesundheits-Schema aufgebaut. Vollwertige Ernährung (z.B. genügend Proteine) und das abwechselnde Angebot für verschiedene Geschmacks-Typen (Frisch und Leicht oder doch lieber Umami und deftig?) waren uns hierbei wichtig. Somit können wir sagen, die Ernährung mit Brokkoli ist gesünder und somit auch nachhaltiger. Das Thema Bio ist selbstredent wesentlich Ressourcenschonender.
Auf das Einsparpotenzial von CO2 durch verkürzte Lieferwege der Lebensmittel oder die circa 20% geringere Lebensmittelverschwendung bei Kochboxen gehen wir hier nicht näher ein.
Was jedoch zu erwähnen ist, wie wir in der App einen Nachhaltigkeits-Bezug geschafft haben. Orientiert haben wir uns hier an der selbst durchgeführten Studie unseres Banking-Projektes (Studie: Einflussfaktoren für nachhaltiges Bezahl und Investmentverhalten der Generation Y)Auf Basis dessen, haben wir angefangen jedem Gericht neben Nährstoffangaben (Relevante Gesundheits-Tags für den Nutzer) auch einen Tag für den CO2 Fußabdruck des Gerichtes zu implementieren. Mit dem CO2 Tag wäre es uns möglich gewesen über die Zeit hinweg bei den Nutzer:innen Referenz und Vergleichswerte zu manifestieren und dadurch das Bewusstsein bei der Ernährung noch weiter zu erhöhen.
Firmenkantinen wie die der Audi AG machen dies übrigens auch schon. Jede Mahlzeit in der Kantine wird mit CO2 gelabelt.
Die nachzukochenden vegangen Gerichte wurden auf einem Gesundheits-Schema aufgebaut. Vollwertige Ernährung (z.B. genügend Proteine) und das abwechselnde Angebot für verschiedene Geschmacks-Typen (Frisch und Leicht oder doch lieber Umami und deftig?) waren uns hierbei wichtig. Somit können wir sagen, die Ernährung mit Brokkoli ist gesünder und somit auch nachhaltiger. Das Thema Bio ist selbstredent wesentlich Ressourcenschonender.
Auf das Einsparpotenzial von CO2 durch verkürzte Lieferwege der Lebensmittel oder die circa 20% geringere Lebensmittelverschwendung bei Kochboxen gehen wir hier nicht näher ein.
Was jedoch zu erwähnen ist, wie wir in der App einen Nachhaltigkeits-Bezug geschafft haben. Orientiert haben wir uns hier an der selbst durchgeführten Studie unseres Banking-Projektes (Studie: Einflussfaktoren für nachhaltiges Bezahl und Investmentverhalten der Generation Y)Auf Basis dessen, haben wir angefangen jedem Gericht neben Nährstoffangaben (Relevante Gesundheits-Tags für den Nutzer) auch einen Tag für den CO2 Fußabdruck des Gerichtes zu implementieren. Mit dem CO2 Tag wäre es uns möglich gewesen über die Zeit hinweg bei den Nutzer:innen Referenz und Vergleichswerte zu manifestieren und dadurch das Bewusstsein bei der Ernährung noch weiter zu erhöhen.
Firmenkantinen wie die der Audi AG machen dies übrigens auch schon. Jede Mahlzeit in der Kantine wird mit CO2 gelabelt.
Die nachzukochenden vegangen Gerichte wurden auf einem Gesundheits-Schema aufgebaut. Vollwertige Ernährung (z.B. genügend Proteine) und das abwechselnde Angebot für verschiedene Geschmacks-Typen (Frisch und Leicht oder doch lieber Umami und deftig?) waren uns hierbei wichtig. Somit können wir sagen, die Ernährung mit Brokkoli ist gesünder und somit auch nachhaltiger. Das Thema Bio ist selbstredent wesentlich Ressourcenschonender.
Auf das Einsparpotenzial von CO2 durch verkürzte Lieferwege der Lebensmittel oder die circa 20% geringere Lebensmittelverschwendung bei Kochboxen gehen wir hier nicht näher ein.
Was jedoch zu erwähnen ist, wie wir in der App einen Nachhaltigkeits-Bezug geschafft haben. Orientiert haben wir uns hier an der selbst durchgeführten Studie unseres Banking-Projektes (Studie: Einflussfaktoren für nachhaltiges Bezahl und Investmentverhalten der Generation Y)Auf Basis dessen, haben wir angefangen jedem Gericht neben Nährstoffangaben (Relevante Gesundheits-Tags für den Nutzer) auch einen Tag für den CO2 Fußabdruck des Gerichtes zu implementieren. Mit dem CO2 Tag wäre es uns möglich gewesen über die Zeit hinweg bei den Nutzer:innen Referenz und Vergleichswerte zu manifestieren und dadurch das Bewusstsein bei der Ernährung noch weiter zu erhöhen.
Firmenkantinen wie die der Audi AG machen dies übrigens auch schon. Jede Mahlzeit in der Kantine wird mit CO2 gelabelt.
Ein Jahr nach Start von Brokkoli evaluierten wir, ob wir die Ziele & KPIs, die wir uns selbst gesetzt haben, erreicht haben. Davon abhängig machten wir, wie eine Zukunft für Brokkoli aussehen kann.
Auch wenn wir selbst und unsere Kund:innen mit Brokkoli zufrieden waren, mussten wir feststellen, dass wir es in naher Zukunft wohl nicht hinbekommen, profitabel zu werden. Als Software Menschen, haben wir das Thema Lebensmittel-Supply-Chain sowie BtoC Kundenaquise etwas unterschätzt. Gegen eine Fremdfinanzierung entschieden wir uns auch, da das Produkt aus unserer Sicht noch nicht Investor-ready war. Nach reiflicher Abwägung von Risiko und Erfolgschanchancen haben wir uns dazu entschlossen, Brokkoli vorerst auf unbestimmte Zeit zu pausieren.
Unsere Kernkompetenz liegt primär im Software-Bereich 🙂
Nichtsdestotrotz sind wir stolz auf die Ergebnisse, die wir innerhalb so kurzer Zeit erreichen konnten und vor allem auf die vielen Kund:innen, die wir mit Brokkoli glücklich gemacht haben.
Ein Jahr nach Start von Brokkoli evaluierten wir, ob wir die Ziele & KPIs, die wir uns selbst gesetzt haben, erreicht haben. Davon abhängig machten wir, wie eine Zukunft für Brokkoli aussehen kann.
Auch wenn wir selbst und unsere Kund:innen mit Brokkoli zufrieden waren, mussten wir feststellen, dass wir es in naher Zukunft wohl nicht hinbekommen, profitabel zu werden. Als Software Menschen, haben wir das Thema Lebensmittel-Supply-Chain sowie BtoC Kundenaquise etwas unterschätzt. Gegen eine Fremdfinanzierung entschieden wir uns auch, da das Produkt aus unserer Sicht noch nicht Investor-ready war. Nach reiflicher Abwägung von Risiko und Erfolgschanchancen haben wir uns dazu entschlossen, Brokkoli vorerst auf unbestimmte Zeit zu pausieren.
Unsere Kernkompetenz liegt primär im Software-Bereich 🙂
Nichtsdestotrotz sind wir stolz auf die Ergebnisse, die wir innerhalb so kurzer Zeit erreichen konnten und vor allem auf die vielen Kund:innen, die wir mit Brokkoli glücklich gemacht haben.
Ein Jahr nach Start von Brokkoli evaluierten wir, ob wir die Ziele & KPIs, die wir uns selbst gesetzt haben, erreicht haben. Davon abhängig machten wir, wie eine Zukunft für Brokkoli aussehen kann.
Auch wenn wir selbst und unsere Kund:innen mit Brokkoli zufrieden waren, mussten wir feststellen, dass wir es in naher Zukunft wohl nicht hinbekommen, profitabel zu werden. Als Software Menschen, haben wir das Thema Lebensmittel-Supply-Chain sowie BtoC Kundenaquise etwas unterschätzt. Gegen eine Fremdfinanzierung entschieden wir uns auch, da das Produkt aus unserer Sicht noch nicht Investor-ready war. Nach reiflicher Abwägung von Risiko und Erfolgschanchancen haben wir uns dazu entschlossen, Brokkoli vorerst auf unbestimmte Zeit zu pausieren.
Unsere Kernkompetenz liegt primär im Software-Bereich 🙂
Nichtsdestotrotz sind wir stolz auf die Ergebnisse, die wir innerhalb so kurzer Zeit erreichen konnten und vor allem auf die vielen Kund:innen, die wir mit Brokkoli glücklich gemacht haben.
“Absolut geiles proooooddduuuukkkktt…. ich mein gericht 🫠😝😂 richtig geiles rezept.. danke ihr erweitert meinen Horizont sooo unglaublich. vielen dank was ihr mit Brokkoli aufbaut. Ich hoffe ihr bekommt noch 1 millionen neuer Mitglieder. Ich unterstütze euch gerne 🙏🏼🙌🏼”
“mega, vielen dank 🙏🏼”
“Das schmeckt nach mehr. Wird in unserem Speiseplan fest integriert. Vielen Dank”
“mein Lieblingsessen bei Brokkoli 😋”
“sehr sehr lecker!! und vielen Dank für das viele Gemüse in dieser Box 👍👍”
“Schreit nach mehr. 😋”
“Sehr lecker. Aber viel zu viel für zwei Personen (zumindest für uns). Uns hättest Hälfte gereicht. Aber so haben wir noch was für morgen :-)“
“nix🤩 Alles priiiiimaaaa”
