Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#74 - Bubble Breakup? Was das neue Pricing des No-Code Anbieters für dich bedeutet.
390 Plays2 years ago
In dieser Episode des VisualMakers Podcasts sprechen Lilith Brockhaus und Alexander Sprogis über die neuen Preismodelle von Bubble und deren Auswirkungen auf die App-Entwicklung. Bubble wechselt von einem kapazitätsbasierten zu einem nutzungsbasierten Preismodell und führt die neue Metrik der Workload Units ein, anhand derer das neue Preismodell festgemacht wird. Wir diskutieren die Auswirkungen dieser Änderung auf Deine B2B- und B2C-Apps und teilen Tricks zur Reduzierung von Workload Units.
Bubble's Pricing Ankündigung vom 06.04: https://bubble.io/blog/2023-pricing-updates/
////////// Gefällt dir unser VisualMakers Content? Werde selbst zum VisualMaker mit einem unserer vielen kostenlosen Kurse. Starte jetzt durch und werde NoCode Profi https://bit.ly/3OCIRsy
////////// Folge uns auf LinkedIn: https://bit.ly/3SfL6oOYoutube: https://bit.ly/3OF5jBjInstagram: https://bit.ly/3cMYH6NSlack: https://bit.ly/3cMNJhC
////////// Jetzt Newsletter abonnieren und keine NoCode News mehr verpassen! https://bit.ly/3cMYNeF
Recommended
Transcript
Einführung und Thema des Podcasts
00:00:07
Speaker
Herzlich willkommen zu einer neuen Episode vom Visual Makers Podcast. Ich bin Lilith und diesmal habe ich keinen Gast dabei, sondern einen alten Bekannten, der schon lange nicht mehr im Podcast war. Alex, du bist wieder dabei. Auf jeden Fall freue ich mich, mal wieder mit dir sprechen zu können, hier vor allen Dingen über ein Thema, das die letzte Woche extrem war.
00:00:29
Speaker
besprochen wurde auf Twitter, in diversen Social-Media-Netzwerken, im Bubble-Forum. Genau um Bubble geht es heute. Da gehen wir drauf ein.
00:00:39
Speaker
Aber erstmal finde ich es extrem schön, mal wieder hier im Podcast dabei zu sein. Ich freue mich auch. Good old times.
Änderungen der Bubble-Preise und Reaktionen
00:00:47
Speaker
Genau, wir sprechen nämlich heute über das neue Bubble Pricing. Für die, die es noch nicht mitbekommen haben, letzte Woche hat Bubble also das mächtigste Web-App-Bildertool, was es zurzeit so am Markt gibt.
00:01:02
Speaker
hat ein neues Pricing bekanntgegeben, was ab 1. Mai in Kraft tritt. Aber für die, die schon ein Bubble-Count haben, es dauert 18 Monate, bis ihr auf das neue Pricing gehen müsst. Genau. Und was das für euch heißt, wie wir das Ganze einschätzen, wie Apps vielleicht neu berechnet werden, welche Kosten auf euch zukommen und so, das wollen wir heute in der Folge besprechen. Weil, ich würde sagen, es ist ziemlich turbulent zugegangen.
00:01:29
Speaker
auf Twitter, in den Foren und so. Und das wollen wir in dieser Folge einmal für euch auseinanderklamüsern und euch auch eine Einschätzung geben, wie wir das Ganze so sehen. Genau. Deshalb lass uns gerne direkt reinstarten. Vielleicht erst mal zu dem, was eigentlich bisher der Stand war und genau, was bisher geschah.
Alte Preisstruktur und bisherige Versuche
00:01:52
Speaker
Genau, also bisher ist es so, dass Bubble sein Preismodell nach Kapazität gestaltet hat. Das heißt, also letztendlich wurde das ein bisschen an der Nutzerzahl festgemacht und je mehr Nutzer deine Plattformen genutzt haben, deine Web-App oder deine Website, desto höher war im Prinzip dein Preis, den du monatlich gezahlt hast und
00:02:16
Speaker
Das war gut skalierbar, würde ich behaupten. Und vor allen Dingen, weil auch hier in dem Bauen keine Grenzen gesetzt waren. Das heißt, du konntest ja deine Bubble App gestalten, wie du wolltest. Ob du jetzt Prozesse ineffizient oder effizient gebaut hast, hat erstmal keinen interessiert. Das hat sich höchstens eben so ein bisschen in der Performance halt bemerkbar gemacht. Aber es ging im Prinzip darum, dass du
00:02:42
Speaker
das die Performance dann eingebrochen ist, wenn extrem viele Nutzer auf deiner App Zugange waren. Das konnte man in den Logs relativ gut nachvollziehen. Also Bubble hat ja eigene App-Statistiken und da gibt es dann auch eine
00:02:56
Speaker
Ja, eine Messung im Prinzip von der Kapazität der Auslastung deiner Applikation und das hat man dann da genau gesehen, wenn deine App da eben an Grenzen gestoßen ist und dann konnte man im Prinzip Kapazität dazu buchen oder eben in höhere Pläne wechseln. Das war also relativ gut kalkulierbar, würde ich sagen, weil man dann immer sagen konnte, okay, meine App hat regelmäßig 10.000 Nutzer, das kann ich ungefähr bei dem und dem Preismodell oder Preisplan verordnen.
00:03:24
Speaker
Genau, und da vielleicht zur Einschätzung. Also Bumble hat schon immer einen Freeplan gehabt, wo man der relativ begrenzt war, konnte man aber schon gut mit starten und dann der Personal Plan lag so bei 29 Dollar und dann ging es weiter mit 129, glaube ich, und dann die Dev-Version quasi für, oder die Developer- oder Agency-Version dann irgendwie für
00:03:45
Speaker
400 Dollar im Monat oder so, irgendwie so um den Dreh, aber man, also die meisten, zum Beispiel auch unserer Kunden und die meisten aus unserer Community lagen entweder bei dem 29-Euro-Plan oder bei dem 129-Euro-Plan oder Dollar-Plan und das, also man konnte da extrem gut skalierbare Apps draufbauen, vielleicht genau nicht mit den Nutzern, weil dann irgendwann die Performance runtergelitten hat,
00:04:09
Speaker
Aber je nachdem, wenn man zum Beispiel eine B2B-App gebaut hat oder so, konnte man da sehr, sehr viel Revenue mitmachen. Und er hat eben nur diesen geringen monatlichen Preis. Problem ist, damit haben halt super viele jetzt sehr, sehr lange gerechnet. Und es war aber auch sehr lange jetzt schon klar, dass Babel nicht bei diesem Pricing bleiben wird. Weil die natürlich auch erfolgreich werden wollen. Und sie haben letztes Jahr schon mal einen Versuch gestartet,
00:04:38
Speaker
das Pricing zu ändern. Der ist grandios gescheitert, würde ich sagen.
00:04:44
Speaker
Ja, auf jeden Fall. Das ist was noch glimpflich formuliert. Also auch da gab's einen riesen Shitstorm aus der Community. Und zwar sollte die neue Preisberechnung anhand von Data Records festgemacht werden. Das heißt, pro Plan hast du eine fest definierte Anzahl an Datenbank-Einträgen, die du in deiner App verzeichnen konntest, bevor du dann eben den höchsten Plan halt buchen musstest von Bubble. Und ich weiß gar nicht mehr ganz genau, wie da die Zahlen waren. Ich glaube, im ...
00:05:15
Speaker
Im Grundpreis waren 1000 Records enthalten, meine ich, also bei dem 29-Dollar-Plan. Und bei Ads, die halt extrem datenintensiv sind, mit vielen Datenmengen arbeiten oder bei großen Datenmengen arbeiten, war das im Prinzip schon
00:05:31
Speaker
hat sich das im Prinzip noch gar nicht mehr gerechnet, dann eben Bubbles zu nutzen, weil die Preise abnormal hoch waren. Es sei denn, man hätte jetzt irgendwie ein externes Backend verwendet und das hätte somit keinen Einfluss auf die eigentliche Bubble App gehabt. Genau, aber dafür, da natürlich ein Großteil der Bubble Apps, die es auf dem Markt gibt, eben auch die integrierte Datenbank nutzen, so ist ja auch eigentlich vorgesehen, hat es an vielen Stellen einfach das Pricing explodieren lassen.
00:05:58
Speaker
Ja, ich weiß es auch nicht mehr ganz, was die Preise waren, was damals auf jeden Fall passiert ist. Es gab diesen Shitstorm aus der Community und daraufhin haben die Gründer Emanuel und Josh darauf reagiert und haben das Pricing erstmal wieder zurückgenommen und nach hinten geschoben und jetzt ein Jahr später
00:06:16
Speaker
gibt es eben dieses neue Pricing, worauf wir gleich nochmal eingehen. Vielleicht nochmal ein kurzer Exkurs fürjenigen, die nicht wissen, wie generell bei vielen SaaS-Produkten Pricing gestaltet wird und warum das so klar war, dass die Preise sich ändern werden.
Neue Nutzungsbasierte Preisgestaltung
00:06:33
Speaker
Weil bisher, wie gesagt, war das eben sehr, sehr günstig, mit Bubble zu bauen und Bubble hat nicht daran partizipiert,
00:06:40
Speaker
wenn Apps besonders erfolgreich wurden, quasi mit seinen Nutzern zu wachsen oder mit seinen Kunden zu wachsen und an deren Erfolg zu partizipieren. Was ja total Sinn macht, weil je erfolgreicher die Leute mit Bubble sind, desto erfolgreicher kann Bubble sein. Also so funktioniert eigentlich jedes Vergleichbare, wenn es überhaupt irgendwas Vergleichbares gibt,
00:07:02
Speaker
Produkt, quasi Saasprodukt auf dem Markt. Und deshalb macht das auch sehr viel Sinn, quasi weg von diesem Capacity-based pricing zu gehen, hin zu einem Usage-based pricing.
00:07:16
Speaker
Genau. Und jetzt gab es einen neuen Versuch, dieses oder was heißt ein neuen Versuch, aber jetzt gibt es ein neues Pricing, was eben noch mal ein bisschen mehr durchdacht ist. Da gab es aber auch ein bisschen Kommunikations-Fährigkeiten, würde ich sagen.
00:07:33
Speaker
Definitiv, es hat große Wellen gegeben. Ich weiß gar nicht, wann Sie initial mit dem neuen Pricing an den Start gegangen sind. Ich glaub, es war vorletzte Woche am Donnerstag, also heute ist der 17. April. Sie wollen am 1. Mai launchen, aber die Kommunikation war quasi letzte Woche, genau.
00:07:50
Speaker
Genau, die Kommunikation. Und offiziell los geht's am 1. Mai. Bestehende Apps haben aber die Möglichkeit, eben das aktuelle Pricing, ja, ich weiß gar nicht, so einzulocken sozusagen für die nächsten 18 Monate oder festzusetzen für die nächsten 18 Monate mit einer 10-prozentigen Steigerung des Preises, also wenn man jetzt den Grundpreis zahlt für 29 Dollar,
00:08:15
Speaker
sodass dann eben 2,90 Dollar die jetzt für die nächsten 18 Monate dazukommen. Sonst verändert sich aber nichts. Das heißt also, man kann jetzt sich seine App anschauen und diese App hingehen des neuen Pricings optimieren, bevor dann in 18 Monaten eben das neue Preismodell aktiv wird und die App dann danach abgerechnet wird.
00:08:36
Speaker
Das muss man allerdings einmal aktiv in der App bestätigen, dass man auf dem alten oder dem aktuellen Preisplan bleiben möchte. Ansonsten startet am 01.05. quasi das neue Pricing oder die neue Abrechnungsmethode. Genau, die neue Abrechnungsmethode findet statt anhand von sogenannten Workload Units. Das heißt also,
00:09:00
Speaker
Jetzt wird nach der geleisteten Arbeit in einer App abgerechnet und nicht mehr nach Kapazität. Also ich würde sagen, wenn man sich eine App als ein Haus vorstellt, dann zahlt man jetzt nicht mehr für die Anzahl der Personen in dem Haus.
00:09:15
Speaker
sondern für den Strom, den diese Personen in dem Haus verbrauchen. Das heißt, es ist völlig egal, wie viele Personen in deinem Haus sind. Es wird eben nach der Stromnutzung abgerechnet. Es kann also sein, dass einige Bewohner deutlich weniger Strom als andere verbrauchen. Was dazu führen kann, dass wenige Personen den Großteil des Stromverbrauchs ausmachen können.
00:09:44
Speaker
Und somit wird es halt schwierig kalkulierbar in Zukunft, diese Workload Units zu berechnen. Das heißt also alles, was mit einer App passiert, ob das jetzt ein Page Load ist, also deine Seite geladen wird, ob irgendeine Datenabfrage stattfindet, in der eine Datenbank durchsucht wird und ein Ergebnis dargestellt wird, sonst irgendwo ein Button geklickt wird, all das kostet eben eine fest definierte Anzahl an Workload Units.
00:10:09
Speaker
Dazu muss man noch wissen, dass nur das abgerechnet wird, was serverseitig passiert. Es gibt also auch Sachen, die in einer App passieren, die im Browser des Nutzers, also kleinseitig, durchgeführt werden.
00:10:24
Speaker
Und da wird ganz klar unterschieden, diese kleinseitig durchgeführten Aktionen, die kosten nichts und eben nur das, was auf Bubbles Servern passiert. Und diese Workload-basierte Abrechnung oder diese Nutzung, die kann in jeder Bubble App eingesehen werden, und zwar unter den Logs in jeder App. Das heißt, auf der linken Seite, wenn man sich eine Bubble App anschaut oder geöffnet hat, auf der linken Seite in dem Menü ganz unten der letzte Punkt, Logs,
00:10:52
Speaker
Und da sieht man jetzt eine Aufstellung der genutzten Workload-Units im Prinzip. Und auch eine Übersicht, welche Aktionen in einer App im Prinzip den größten Anteil ausmachen. Das ist in so einem Kuchen-Chart quasi dargestellt. Und da kann man dann auch noch tiefer reingehen und sich anschauen, welcher Workflow in meiner App verbraucht jetzt die meisten Workload-Units. Genau.
00:11:19
Speaker
Und das Problem mit der ersten Ankündigung war, dass Bubble ein Tool veröffentlichen wollte und inzwischen glaube ich sogar auch hat, was die Workload Units berechnet und das aber noch nicht fertig war. Das war jetzt, das war im ersten Moment total intransparent.
00:11:35
Speaker
Wie berechnen sich eigentlich solche Workload-Units? Und dementsprechend dann auch eine große Unsicherheit geherrscht hat von wie viel kostet denn meine App jetzt eigentlich? Und teilweise vom Bubble-Team Zahlen genannt wurden, die wesentlich geringer waren als das, was die Leute tatsächlich in ihren Apps gesehen
Transparenz und Unterstützung der Community
00:11:55
Speaker
haben. Also
00:11:56
Speaker
Sie haben gesagt, okay, ein Pageload zum Beispiel sollte so und so viele Workload-Units kosten und die User in den Apps haben teilweise das Zehnfache davon in ihren Apps gesehen. Und das hat so sehr, sehr viel Verwirrung gesorgt. Oder für sehr, sehr viel Verwirrung gesorgt.
00:12:12
Speaker
Da gab es jetzt aber direkt schon ein Update. Also eins, was man Babbel wirklich hoch, hoch anrechnen muss, ist die Kommunikation mit der Community und generell auch, wie die Community innerhalb sich selber quasi kommuniziert, aber auch, wie die Gründer darin kommunizieren, weil die wirklich sehr, sehr nah dran sind, Feedback wirklich ernst nehmen und hören und da dann auch relativ schnell dann gepostet haben und Antworten darauf gepostet haben. Und da gab es jetzt auch nochmal ein Update.
00:12:39
Speaker
wo jetzt die Zahlen auch übereinander stimmen, dass eben nicht diese Workload-Units für bestimmte Workflows oder in dem Sinne auch für alle Workflows nicht mehr zehnmal höher sind, als das von Babel ursprünglich angekündigte.
00:12:57
Speaker
Ja, interessanterweise muss man, also es gibt eine Übersicht mit Punkten, also mit Aktionen in einer Bubble App und den dazugehörigen Kosten, also Workload-Unit-Kosten. Aber auch die muss man wiederum lesen können. Also diese Tabelle an sich, die bietet sehr viel Raum für Interpretation. Man kann das ganz gut einsehen in seiner eigenen Bubble App, wie viel Workflow, Workload-Units für was
00:13:26
Speaker
gebraucht werden, eben anhand dieser Tabelle. Und ja, da ist auf jeden Fall Interpretationsspielraum. Und Bubble hat selber sich schon darauf committed, dass sie bessere Tools zur Verfügung stellen werden, um diese Workload Units zu analysieren. Hätte man jetzt auch mal früher machen können, also wenn man diesen Release macht mit dem neuen Pricing und Workload Units, dann wäre es vielleicht gut, da jetzt schon Tools, die wirklich signifikant
00:13:56
Speaker
in Transparenz schaffen, bereitzustellen. Aber wir sind relativ zuversichtlich, dass das passiert in den nächsten Wochen. Also das wird eines der ersten Dinge sein, die sie nachziehen werden. Mit dem geupdateten
00:14:16
Speaker
Workload-Unit-Berechnungen kommt es tatsächlich in vielen Fällen ran an das alte Pricing. Also manche Apps werden sogar ein bisschen günstiger, andere Apps werden ein bisschen teurer, aber generell hält sich das jetzt mit den neuen Berechnungen tatsächlich im Rahmen.
00:14:35
Speaker
Ja genau, das ist auch das, was wir aus unseren Projekten sehen, die wir machen. Das hält sich jetzt nach der Neukalkulation sehr in Grenzen, die Auslastung. Das heißt, Bubble hat nach dem ganzen Feedback der Community die Workload-Unit-Kosten reduziert von bis zu 99 Prozent.
00:14:57
Speaker
Und das heißt, also sowas wie API-Calls sind so ungefähr das Zehnfache reduziert in den Kosten. Normale Datenbankoperationen wie Lesen, Schreiben, Löschen, Updaten bei ungefähr fünffach vergünstigt quasi. Und ja, damit kann man die
00:15:20
Speaker
verhalten sich die Kosten eigentlich relativ überschaubar. Also es ist natürlich super unterschiedlich von App zu App, deswegen kann man es auch super schlecht vorhersagen, welche App jetzt wie viel Workload Units kostet, weil es wirklich abhängig ist von einzelnen Nutzern in dieser Anwendung.
00:15:38
Speaker
Alles in allem, aber wie gesagt, kann man das in den Logs von Bubble ganz gut einsehen. Wie du schon gesagt hast, arbeiten die auch daran, das jetzt schnellstmöglich oder stetig auch zu verbessern und transparenter zu machen. Das heißt, in den Logs selber siehst du auch ganz genau, welche Bereiche, wie viel, also erstmal, wie hoch der prozentuale Anteil ist von verschiedenen Workflows zum Beispiel, wie viele Workload-Units die ausmachen. Mittlerweile steht aber auch eine konkrete Anzahl dahinter.
00:16:06
Speaker
Und so kann man ganz gezielt auch Workflows verbessern, optimieren, Datenbankabfragen reduzieren, wo sie nicht nötig sind zum Beispiel, oder eben mit bestehenden Daten arbeiten. Genau, also da gibt es eine ganze Reihe an Optimierungsmöglichkeiten, die man hat und Bubble versucht da möglichst viel Transparenz zu schaffen, gibt eine ganze Liste mit Updates, die jetzt bis zum 1.5. oder noch nach dem 1.5. halt live gehen sollen.
00:16:35
Speaker
um das Ganze ein bisschen besser planbar zu machen. Zum Anfang hatten die einen Subscription Planner noch veröffentlicht, wo, glaube ich, auch sich die Community relativ viel von erwartet hat, also um besser einschätzen zu können, okay, welchen Plan brauche ich denn jetzt für meine App.
00:16:51
Speaker
Allerdings war das ja tatsächlich einfach nur ein Eingabefeld, was da dann hinzugefügt worden ist mit, ja, mit einer Anzahl, beziehungsweise mit einer Eingabe, wo du dann die Anzahl der Workload-Units eingibst, die deine App dann vielleicht verbraucht und daraus wurde dir dann eben der entsprechende Plan vorgeschlagen oder es gibt dann ja noch sowas wie Tiers, die man updaten kann, also ich glaube irgendwie eins bis fünf oder sowas, die dann
00:17:17
Speaker
weitere Workload-Units freischalten für den aktuellen Monat oder für dauerhaft. Dieser Subscription Planner, der hat dir im Prinzip nur den entsprechenden Plan vorgeschlagen, plus vielleicht einen T, also dass du da monatlich halt die optimalsten Pläne dann buchen kannst für deine App. Das war jetzt aber nicht ein, ich habe die und die App mit der und der Anzahl von Nutzern. Sag mir doch mal, wie viel sind die monatlichen Kosten, was ist da zu erwarten? Also das war es leider nicht. Das kam dann von einem Community-Nutzer, der
00:17:47
Speaker
so einen Workload Unit Planner gebaut hat, wo man dann mit der Anzahl von Nutzern und der zu erwarteten Workflow-Auslastung dann einen Preis berechnen kann. Das heißt, du brauchst im Prinzip genau die Anzahl der Nutzer und wie viele Workflows die ungefähr ausführen innerhalb deiner App. Aber auch das ist natürlich schwer zu schätzen, wenn du jetzt gerade erst anfängst, eine App zu entwickeln.
00:18:15
Speaker
Genau. Von daher, das ist ein bisschen aufgeteilt. Das hat er kategorisiert in Basic App, in Complex App und noch zwei weitere Kategorien, damit man es ein bisschen einordnen kann. Aber das ist wirklich noch ein ganz grober Anhaltspunkt, wo man sich orientieren kann. Ja. Das finde ich aber auch nochmal ein Beispiel für, wie wichtig die Community von Bubble ist und wie viel das auch hilft bei einer Tool-Auswahl. Also, wir kommen später noch drauf, so nutzen wir weiter Bubble.
00:18:44
Speaker
wenn ja warum und was der Unterschied nochmal zu anderen Tools und so. Und Bubble hat einfach eine wahnsinnig starke Community, die bei allen möglichen Problemen aushelfen können. Das Forum wird so krass genutzt und es gibt eigentlich für jedes Problem gibt es irgendeine Lösung.
00:19:00
Speaker
schon von irgendeinem Community-Member. Und die sind einfach wirklich, wirklich stark. Und es gab jetzt diesen riesen Shitstorm und man merkt aber auch immer wieder, wie Leute sagen so, hey, ich liebe dieses Produkt und ich will das weiter nutzen und sich auch wirklich bemühen, da eine gute Lösung zu finden. Und das ist sehr, sehr cool zu sehen.
Herausforderungen durch Anbieterbindung
00:19:21
Speaker
Vielleicht noch zum Thema Workload-Units, was auch noch ganz wichtig ist, weil das auch bei der ersten Kommunikation aufkam.
00:19:30
Speaker
das mit so einem neuen Pricing, so einem Usage Base Pricing experimentieren, eben auch viel teurer wird. Und weil je nachdem wie viel, wenn du aus Versehen Loop reinbaust oder sowas in deine Workflows und das Ganze auf einmal unendlich läuft,
00:19:48
Speaker
da quasi ein Hebel zu haben, dass das nicht unendlich viel kostet. Und da haben Sie jetzt auch nochmal ein Update gemacht, dass es quasi Developer Workload Units gibt, die innerhalb eines Plans freigegeben werden. Die sind begrenzt. Also, ich weiß die genauen Zahlen jetzt gerade nicht, aber ich meine, es werden irgendwie sowas wie... Das sind 100.000, glaube ich.
00:20:10
Speaker
Genau, also 100.000 Workload-Units, wo man wirklich schon gut mitarbeiten kann, wo man wirklich viel ausprobieren kann und eben auch optimieren kann, bevor man seine App live schaltet und da User drauf lässt und vielleicht im kritischsten Fall irgendeinen Loop gebaut hat oder vielleicht nicht Workload optimiert gebaut hat oder so. Also das hat sich auf jeden Fall auch schon nochmal verbessert, weil das war einer der größten Kritikpunkte auch am Update, dass Bubble, Bubbles Vision ist ja eigentlich
00:20:39
Speaker
Tech zu demokratisieren und Software-Building zugänglich zu machen, zu einer breiten Masse an Leuten. Und dass das im ersten Moment ein bisschen im Gegensatz stand zu dem, wie Bubble das Pricing strukturiert hat, das Neue. Und das ändert sich jetzt eben wieder ein bisschen, ja, es ist ein komplexes Pricing und das sollte man einmal ganz gut verstehen, trotzdem kann man sehr gut anfangen und erstmal herumexperimentieren und erstmal bauen, ohne Angst haben zu müssen,
00:21:07
Speaker
da jetzt auf einmal ein Vermögen wortwörtlich zu verbauen. Ja, ja, total. Genau das sollte eigentlich das auch sein, wofür No-Code steht, wofür Bubble steht, dieses ich kann nämlich ausprobieren, ich brauche jetzt keine Angst vor Tag haben und darf auch Fehler machen, ohne irgendwie Konsequenzen zu spüren. Und ja, das haben Sie so ein Stück weit auf jeden Fall wieder gelöst, dieses wovor halt jetzt gerade viel Angst hat. Jetzt fange ich an.
00:21:37
Speaker
Ich hab mich auf Bubble committed, möchte jetzt ausprobieren und jetzt muss ich aber genau aufpassen, was ich mache und darf jetzt keine Fehler machen. Da können wir vielleicht auch noch mal ganz gut drauf gucken, wenn wir gerade schon dabei sind. Was heißt das denn eigentlich für die No-Code-Welt? Weil No-Code an sich und ich glaube, Bubble auch ganz klar als Vorreiter steht eigentlich für dieses Experimentieren, Ideen umsetzen, auch nicht technische Leute, die Ideen umsetzen können.
00:22:06
Speaker
Und was ich ein bisschen schade an dem ganzen Ding finde, ist, dass da einfach im ersten Moment sehr viel Vertrauen verloren gegangen ist, weil eine Diskussion, die wir ja oft haben, ist sowas wie Vendor-Login. Dass man auf eine Plattform geht, wenn man sich für eine Plattform wie Bubble entscheidet, wo man den Code nicht exportieren kann, im Gegensatz zu anderen No-Code-Tools, wie zum Beispiel Flutterflow oder Weweb oder so, wo man den Code exportieren kann. Oder sogar Webflow.
00:22:32
Speaker
dass man eben lockende Effekte hat von okay, jetzt schieße ich mich auf so ein Tool ein.
00:22:38
Speaker
Und dann kann es halt sein, dass eben Pricing geändert wird oder dass bestimmte Sachen geändert werden oder irgendjemand pleite geht oder so was. Das sind Fragen, die wir total oft bekommen. Nur da würde ich mich auch immer fragen, okay, was steht denn im Gegensatz dazu? Weil selbst bei den Tools, wo man Code exportieren kann, bei vielen kannst du ihn nicht wieder importieren. Und wenn du Code exportierst, dann ist das ja im Rahmen von diesen No-Code-Tools, also Webflow-Code zum Beispiel, den man exportiert,
00:23:06
Speaker
Da sind ja die Webflow-Komponenten mit drin. Das heißt, ich kann damit nicht einfach so weiterbauen. Also kann ich schon, aber dann brauche ich halt wieder super viel Ahnung davon. Oder muss eben programmieren können. Genauso bei Flutterflow oder Weweb. Also da ist immer die Frage, okay, wie viel bringt mir das denn wirklich, diesen Code exportieren zu können?
00:23:29
Speaker
Und das steht halt auch im ganz krassen Gegensatz zur Schnelligkeit, weil es ist ja die Frage, was will ich damit erreichen? Will ich zum Beispiel, wenn ich ein Prototyp bauen will oder wenn ich ein Produkt bauen will und ich habe keinen technischen Co-Founder, selber keine Programmierungskills oder muss einfach sehr, sehr schnell sein im Markt und ich glaube, das wird immer wichtiger werden, dann sind diese Tools
00:23:53
Speaker
trotzdem noch die richtige Lösung. Selbst wenn ich irgendwann sage, okay, ich bin so erfolgreich, dass ich irgendwie umbauen muss, dann kann ich das ja oft immer noch in noch mal in Code bauen oder Teile davon in Code bauen und wir kommen gleich auch nochmal auf Optionen ein, die man auch in Bubble jetzt zum Beispiel hat, um Workload-Units zu reduzieren oder eben nicht nur von einer oder weniger abhängig von einer Plattform quasi zu sein, zum Beispiel
00:24:20
Speaker
Frontend und Backend auftrennen, vielleicht Workflows, besonders rechenintensive, irgendwie nochmal auszulagern. Also da gibt es einige Hebel, wie man diesen Wender-Login tatsächlich ein bisschen umgehen kann, was ich nur halt super schade finde, dadurch wie diese Kommunikation gelaufen ist, dass das schon hart kurz am Vertrauen gekratzt hat.
00:24:45
Speaker
Ja, so ein bisschen auf jeden Fall, ja. Zumal die Kommunikation dann auch von der Vice President of Marketing, glaube ich, getätigt wurde. Ah, ja. Eine Person, die der Community komplett unbekannt war eigentlich. Also ich glaube, es war auch ihr erster Beitrag in dem Forum. Und niemand kennt diese Person. Und dann wird so was announced, was ja auch wirklich weitreichende Auswirkungen hat auf jegliche Unternehmen, die Bubble nutzen. Zumal ja auch ganze Existenzen quasi von Bubble abhängig sind.
00:25:16
Speaker
Genau, von daher. Aber genau, da brauchen wir vielleicht auch gar nicht tiefer drauf eingehen. Ich glaube, da gibt es einiges, woraus Bubble gelernt hat. Ja.
00:25:27
Speaker
Aber auch dieser No-Code-Aspekt generell oder auch dieser Vendor-Login, den hast du ja noch auf ganz anderen Ebenen. Ich sag mal, selbst wenn du eine Anwendung entwickelst und das auf einer Amazon Web Services Infrastruktur hostest, weil du es nicht in einem eigenen Rechenzentrum haben möchtest, dann hast du ja auch wiederum einen Vendor-Login, weil du deine Anwendung AWS anvertraust.
00:25:48
Speaker
Und wenn die ihr Pricing erhöhen, dann musst du auch gucken, okay, welche Option habe ich dann? Wo kann ich jetzt hingehen? Oder das Gleiche ist bei Google und Microsoft Azure. Hast du da genauso? Es gibt eben die großen Player auf dem Markt und irgendwo wirst du immer einen Vendor-Login eingehen müssen. Ja, aber es gibt immer Alternativen auf jeden Fall. Ja, ja, total.
00:26:14
Speaker
Okay, was machen wir denn jetzt konkret? Es gibt ja einige Tricks und so, wie ich Workflow-Units reduzieren kann. Und du hast auch schon einige rausgefunden, Alex.
00:26:27
Speaker
Ja, genau. Ich glaube, die offensichtlichsten sind erstmal Kosten reduzieren, indem man möglichst wenig Datenbankabfragen macht in seiner Applikation. Das ist so das, was mit am teuersten ist. Das heißt, schaut einfach mal in eure Applikation. Ihr seht ja sowieso das in dem Log eurer Bubble App, wo ihr am meisten verbraucht. Wenn das dann eben Workflows sind, in denen ihr Daten erstellt, Daten bearbeitet oder
00:26:57
Speaker
Daten lest, dann schaut das ihr vielleicht, wenn ihr das macht auf verschiedenen Seiten, das nicht doppelt und dreifach macht und vielleicht irgendwie auf einer Seite mehrfach die gleiche Datenbanktabelle abfragt, sondern dann ihr schaut, okay, wie kann ich diese eine Abfrage, die ich gemacht habe, wieder verwenden für meine anderen beiden Abfragen. Ich denke, da kann man
00:27:18
Speaker
Anwendung schon deutlich verschlagen, indem man einfach sparsam mit solchen Datenbankabfragen umgeht und möglichst Daten wiederverwendet. Ansonsten, was noch sehr intensiv ist, ist gerade das Anlegen bearbeiten und löschen von Listen. Das sollte man möglichst wenn auf Minimum reduzieren.
00:27:34
Speaker
Oder auch diese Aktion Do X Every 5 Seconds. Also es gibt ja Sachen, die man in einem bestimmten Zeitsegment immer wieder durchführen kann. Und auch die sind natürlich extrem kostenintensiv. Genauso wie Workflows, die beim PageLoad ausgeführt werden.
00:27:55
Speaker
Ja, sollte man einfach optimieren, damit diese Sachen nicht vielleicht, oder dass die nicht notwendigen Sachen, die beim PageLoad nicht unbedingt benötigt werden, eben ausgelagert werden irgendwie in andere Trigger statt in dem PageLoad. Ansonsten, wenn
00:28:12
Speaker
Wenn ihr mit sehr viel datenintensiven Anwendungen arbeitet oder wenn eure Anwendung sehr datenintensiv ist, lohnt es sich vielleicht auch, sich ein externes Backend
Optimierung und externe Lösungsansätze
00:28:20
Speaker
anzuschauen. Wir nutzen für fast alle unsere Projekte Xano als Backend. Das hat zumal den Vorteil, dass man Xano auf einem europäischen Server hosten kann, also direkt in Frankfurt.
00:28:34
Speaker
auf einer Amazon-Web-Services-Infrastruktur. Und mittlerweile gibt es ein Plugin, was von zwei Member aus der Community entwickelt worden ist, um API-Aufrufe für Xano aus dem Browser des Nutzers zu machen. Aktuell ist es so, dass wenn du einen API anschließt über Bubble, über den API-Connector, dass die Calls serverseitig gemacht werden. Das heißt, die Daten gehen auch noch mal über den Proxy-Server von Bubble.
00:29:01
Speaker
Und das kostet wiederum natürlich auch alles Workload Units. Wenn man ApiCalls aber kleinzeitig machen kann aus dem Browser des Nutzers, dann hat das keinen Einfluss auf die Workload Units. Man spart sich das also komplett. Und genau, das wäre einfach nur zu empfehlen, wenn ihr datenintensive Apps habt, das auszulagern in so eine Backend-Anwendung wie Xano, weil man auch da die komplette Geschäftslogik für die Anwendung abbilden kann. Das heißt, man spart sich da vielleicht auch insgesamt deutlich mehr Logik.
00:29:31
Speaker
in Bubble und nutzt Bubble selber eigentlich nur noch so ein bisschen als reines Frontend sozusagen und all das, die ganze Logik passiert eben im Hintergrund bei Plattformen wie Xan und so weiter. Genau, und das hat sich bei uns als sehr Workload Unit sparend erwiesen, also ich hab jetzt nochmal gerade auch nach der Neukalkulation bei uns in die Apps reingeschaut, die wir für uns und für Kunden gebaut haben,
00:29:58
Speaker
Und das sind wirklich, ja, wenige hundert Workload-Units, die wir da am Tag verbrauchen. Auch das natürlich super individuell und das kann man überhaupt nicht über alle Apps generell hinweg sagen, hängt ja immer wieder stark von der Nutzung ab.
00:30:12
Speaker
Wir sind da sehr zuversichtlich, dass wir da auf jeden Fall super sparsam unterwegs sind, somit. Genau, das sind so ein paar Sachen, auf die man achten kann. Wie gesagt, ansonsten hat man ja alles in den Logs im Überblick und kann dahingehend dann perfekt optimieren. Und vielleicht noch dazu am Rande, Bubble hält am 20. April ein Webinar zu dem ganzen Thema, wie optimiere ich meine Bubble App hinsichtlich Workload Units.
00:30:36
Speaker
Das wird sicher auch aufgezeichnet, also vielleicht, wenn der 20. schon rum ist, einfach mal auf dem YouTube-Kanal von Bubble nachschauen und sich die Aufzeichnung reinziehen. Genau, verlinken wir auch beides in den Show Notes, also sowohl das Webinar an sich und dann auch später die Aufnahme. Dann könnt ihr einfach mit einem Klick dahin. Und generell, wenn ihr lernen wollt, wie ihr mit Bubble wirklich sparsam
00:31:04
Speaker
baut, dann schaut euch gerne mal auch unsere, ähm, unsere Bubble Masterclass an. Ähm, da zeigen wir euch, ähm, wie ihr da, ähm, ja, Workflow Unit sparsam, ähm, quasi bauen könnt. Wir haben es noch, also jetzt zum Zeitpunkt der Aufnahme, haben wir, äh, die, die Bubble Masterclass dahingehend noch nicht aktualisiert, quasi auf das neue Pricing. Ähm, aber, äh, auch in der Struktur, wie sie wir jetzt schon haben, ähm, lernt ihr da sehr sparsam, äh, quasi zu bauen.
00:31:32
Speaker
und vor allem auch effizient eure Workflows und so zu bauen. Deshalb schaut da auf jeden Fall auch gerne mal rein. Verlinken wir euch natürlich auch in die Show Notes. Gibt es denn irgendwas, wo du sagen würdest, okay, da würdest du nicht mehr mit Babel bauen? Und es gab ja auch ganz viele, die gesagt haben, boah, ich guck mir jetzt super viele Alternativen an. Wir haben uns natürlich auch ein paar Alternativen nochmal genauer angeguckt.
Vergleich mit alternativen Plattformen
00:32:01
Speaker
Kommt irgendwas an Bubble ran gerade? Also in dem Umfang, wie Bubble heute existiert, denke ich auf gar keinen Fall. Also es gibt sehr vielversprechende Konkurrenz mit Weweb oder mit Flutterflow. Aber die sind natürlich noch lange nicht so ausgereift wie Bubble, gerade vor allen Dingen, weil die alle erst seit ein, zwei, drei Jahren am Markt sind und dementsprechend natürlich noch gar nicht den Umfang haben können. Zumal die Communities natürlich auch deutlich kleiner sind, als sie bei Bubble ist.
00:32:32
Speaker
Also wenn man sich WeWipe zum Beispiel anguckt, dann hat das in den Grundzügen schon in annähernd ähnlichen Funktionsumfang wie Bubble, ich schätze mal, ist jetzt glaube ich zwei Jahre alt oder so was. Und die haben jetzt natürlich, also ich weiß nicht, ob das in Reaktion auf das Bubble Pricing Announcement war, aber auch ihre eigenen Preise angepasst und sind in der Grundversion nochmal deutlich günstiger geworden. Ich glaube von 59 Dollar auf 39 Dollar, glaube ich, reduziert.
00:33:01
Speaker
Auch da mit Einschränkungen natürlich, aber war ein interessantes Verhalten jetzt auch in der Situation. Und Sie haben ja auch Ihren, also vorher gab es den Code Export ja auch erst im Enterprise Plan und jetzt gibt es den glaube ich schon in dem kleinen Plan, richtig?
00:33:18
Speaker
Genau, gibt's noch einen kleinen Plan, vorausgesetzt, du buchst den auf jährlicher Basis. Ja. Ich hatte mir dazu so ein Q&A-Event angeschaut, die meinen, natürlich machen die das um sich selber so ein bisschen auch abzusichern, weil du könntest jetzt WeWork buchen für einen Monat, baust deine App fertig, explodierst den Code und dann sehen sie dich nie wieder. Das wollen sie natürlich verhindern, in dem Sinne, dass du dich ein bisschen besser oder ein bisschen mehr committest.
00:33:45
Speaker
Letztendlich stellen sie dir ja auch einen super komplexen Designer zur Verfügung, mit dem das erst möglich gemacht wird. Von daher ist das total gerechtfertigt. Und WeeWeb ist in dem Sinne auch ein bisschen anders, weil WeeWeb ein reiner Frontend-Bilder ist. Das heißt, du brauchst unbedingt ein externes Backend, wie zum Beispiel Xano, eine eigene SQL-Datenbank oder wie auch immer. Ohne kannst du da gar keine Web-Anwendungen bauen.
00:34:11
Speaker
Von daher unterscheidet sich das auf jeden Fall zu Bubble, weil Bubble alles inklusive hat. Sowohl das Frontend, die Logik, als auch das Backend. Genau. Und bei Weweb ist es so, dass du Schnittstellen in Form von Plugins hinzufügst. Es gibt so eine ganz kleine Plugin-Auswahl bisher bei Weweb, wo dann sowas existiert wie eine Xano-Anbindung, eine native oder
00:34:34
Speaker
eine Superbase-Anbindung, Airtable-Anbindung und so weiter. Und in dem kleinsten Plan hast du, glaube ich, maximal vier Plugins inklusive. Und bei Xano wäre es so, du brauchst einmal das normale Xano-Plugin für den Datenbankzugriff, und dann brauchst du noch ein Plugin für die Authentifizierung mit Xano. Das heißt, dir sind schon mal zwei Plugins quasi dafür reserviert. Also musst du wirklich schauen, okay, was mache ich jetzt mit den anderen beiden? Muss ich noch irgendeinen externen Service anschließen oder sowas?
00:35:01
Speaker
Und das Ganze ist auch begrenzt auf, ich glaube, 50.000 Zugriffe im Monat, die man natürlich auch nachher relativ schnell erreicht haben könnte, je nachdem, wie viel Traffic auf der Website ist. Also, jedes Neuladen einer Seite ist ein Pageview. Kann auch vom selben Nutzer sein. Das heißt, nur wenn du eine Seite aktualisierst, hast du schon zwei Pageviews verbraucht.
00:35:23
Speaker
Genau, also ich glaube, Limits hast du überall und das ist auch total okay. Letztendlich stellen die dir ja auch eine komplette Infrastruktur bereit, die du dann als nicht technischer Nutzer oder technischer Nutzer nutzen kannst. Für dich und ich finde immer, das Pricing auch bei Bubble jetzt 32 Dollar für eine vollumfängliche Web-App, das ist also ein kompletter No-Brain immer noch. Voll, ich finde auch, das muss auch echt nochmal betont werden von, ähm, Bubble war halt viel zu günstig.
00:35:50
Speaker
Also jetzt bestimmt fünf, sechs Jahre lang war Bubble einfach viel, viel, viel zu günstig. Und das ist ja auch was, was man möchte. Also wir wollen ja zum Beispiel auch, dass Bubble erfolgreich ist. Und dafür ist es total natürlich, dass sie auch am Erfolg ihrer Nutzer partizipieren. Schweres Wort.
00:36:12
Speaker
Und nur die Kommunikation war einfach ein bisschen schwierig gewählt und einfach sehr viele Hickups am Anfang, die einfach nicht hätten sein müssen, die ein bisschen weniger Chaos vielleicht verursacht hätten oder Verwirrung in der Community und so. Aber generell, dass das Pricing von Bubble ein bisschen höher wird, war, glaube ich, total erwartbar und ist auch total
00:36:36
Speaker
sinnvoll, wenn ein Tool, wie das einfach, ja, weiter wachsen, erfolgreich sein will und so. Und Sie haben ja gerade 100 Millionen Investment eingesammelt. Das heißt, es sind jetzt WCs drin. Aber man merkt trotzdem noch, wie sehr das noch gründergesteuert ist. Also es ist echt, das ist unglaublich, was die Community einfach ausmacht bei Bubble.
00:36:59
Speaker
Lass uns noch einmal kurz sprechen über Flutterflow. Flutterflow kann glaube ich featuremäßig relativ viel. Ist aber halt an Firebase sehr, sehr stark gebunden. Eben auf der ganzen Google-Umgebung quasi. Und ist ja auch für Mobile Apps optimiert, richtig? Ja, genau. Also mittlerweile kannst du auch andere Backends anschließen. Auch so was wie Xano könntest du auch mit Flutterflow nutzen.
00:37:27
Speaker
Aber wie du sagst, die kommen halt von mobile first. Also es war ja zu Anfang nur möglich.
00:37:34
Speaker
eine native Mobile Apps zu entwickeln. Mittlerweile kannst du auch Web Apps damit entwickeln. Die sind aber vom Aufbau her und so noch stark limitiert. Also zumindest von dem, was ich mitbekomme. Ich muss sagen, ich bin jetzt kein intensiver Flutterflow Nutzer. Aber das ist noch sehr, sehr stark an Mobile First orientiert. Deswegen würde ich sagen, gerade bei Web Apps können die Bubble noch lange nicht in den Rang ablaufen. Ja. Und eben auch dieser Community Aspekt, gerade die Erweiterbarkeit.
00:38:02
Speaker
der Anwendung ist noch super limitiert. Also es gibt nichts Vergleichbares, wie zum Beispiel den Plugin Marktplatz bei Bubble, wo es ja wirklich Tausende Community-entwicklte Plugins gibt. Ja, sagt mir der Problem, ich habe ein Plugin dafür. Eins, was mir noch aufgefallen ist, das kannte ich vorher nicht, ein Tool. Da wollten wir uns auch mal
00:38:27
Speaker
auch mal tiefer reinschauen, ist Repler, glaube ich heißt das, ne? Das ist ein Tool, das ist mir öfter mal auch, okay, du hast noch nicht davon gehört, auf Twitter begegnet. Das soll aber sehr viel technischer sein und ist für, für Entwickler, die Bubble nutzen, wohl, wohl ganz interessant, aber ist halt überhaupt nicht den Aspekt von, okay, no, no und low-code, also eher so in die sehr low-code
00:38:54
Speaker
Code Richtung eher, also auch nicht so wirklich ein Vergleich, weil mit Bubble ja wirklich jeder, jeder starten kann. Die Lernkurve ist zwar relativ groß, weil es einfach ein komplexes Tool ist, aber trotzdem braucht man eben keine Coding-Kenntnisse oder Programmier-Kenntnisse, um mit Bubble starten zu können.
00:39:13
Speaker
Ja, ja, absolut. Und genau das ist auch das, was ich also jetzt nochmal gerade in der Situation, wie wir sie jetzt haben, mit dem okay, ich muss halt, also kann schon noch Fehler machen, aber es wäre gut, wenn die Applikation einigermaßen effizient aufgebaut ist.
00:39:29
Speaker
Einfach dieses begleitende Bauen, also entweder ich schaue mir irgendwo ein paar Videos dazu an, schaue mir einen Kurs dazu an, weil ich kenne das auch selber. Ich habe ja auch versucht, ohne Hilfsmittel in Bubble zu starten, bin dreimal gescheitert und habe mir dann einen Kurs geholt und habe dann Schritt für Schritt gelernt anhand von einem Use Case. Das hat es mir deutlich einfacher gemacht und das ist, würde ich jetzt sagen, noch umso wichtiger.
00:39:52
Speaker
Ja, genau, das denke ich auch direkt von Anfang an, irgendwie sinnvoll bauen zu können, die ganzen Frustrationen sich zu ersparen und nachher auch ein böses Erwachen zu ersparen. Genau, wir haben da auch einen kostenlosen E-Mail-Kurs zu Bubble, der wird tatsächlich demnächst nicht mehr nur E-Mail-Kurs sein, sondern nochmal auf eine andere Plattform umgezogen werden. Aber dazu bald mehr. Genau, da könnt ihr euch kostenlos anmelden, verlinken wir auch in den Shownotes.
00:40:22
Speaker
wenn ihr mal in Bubble reinschnuppern wollt. Genau. Ich glaube, wir haben schon viel dazu gesagt. Aber was ist denn so unser Fazit?
Bubble's Engagement mit der Community
00:40:33
Speaker
Sind wir immer noch Bubble-Lover? Ja, ja, total. Ich meine, klar hat das Vertrauen jetzt noch ein bisschen eine kleine Kerbe. Aber ich denke, die tun jetzt alles dafür, die Community einigermaßen happy zu machen.
00:40:47
Speaker
Was man ja schon jetzt mit der Optimierung gesehen hat, die sind super aktiv im Forum, antworten eigentlich immer gebündelt auf mehrere Fragen. Gleichzeitig jetzt war ja auch nochmal ein Riesenthema. Okay, was passiert denn, wenn ich jetzt zum Beispiel einen DDoS-Angriff erfahre für meine App? Also bots, die zahlreiche Anfragen an meine Seiten schicken und jeder PageLoad kostet ja bekanntlich Workload-Units. Sind meine Units dann in ein paar Minuten aufgebraucht oder was? Und das sind jetzt Themen, da arbeiten sie im Hintergrund dran.
00:41:17
Speaker
um das eben zu verhindern. Und das ist natürlich bei anderen Applikationen nicht anders, auch wenn man sich jetzt eine Web App vorstellt mit 50.000 monthly visitors oder page views, die da limitiert sind.
00:41:31
Speaker
In der Grundversion zumindest, die haben ja genau das gleiche Thema. Also auch da, ich glaube jetzt, wegen einem Problem zu sagen, ich wechsle jetzt auf eine andere Plattform, das sollte man sich vielleicht mal überlegen und schauen, wie das bei anderen Plattformen gehandelt wird. Ich denke, da haben viele Plattformen einfach ähnliche Probleme auch. Genau, also nach wie vor, wir werden die kommenden Wochen, Monate, Jahre hundertprozentig weiter mit Bubble arbeiten.
00:41:55
Speaker
und schauen halt, dass wir deren Ressourcen möglichst optimal nutzen. Wir arbeiten sowieso mit externen Backends, wie bereits gesagt. Ich glaube, das ist eine sehr, sehr gute Möglichkeit, Workload Units und Kosten zu sparen. Ja, und nach wie vor, es ist ein geniales Tool. Man kann so viel damit umsetzen. Wie gesagt, es gibt kaum ein News Case, der sich damit nicht realisieren lässt. Bin nach wie vor großer Fan.
00:42:22
Speaker
Ja, ja voll. Ich auch. Also ich muss sagen, an dem Wochenende, wo es rauskam, vor allem, weil es auch kurz vor Ostern war und so, also die erste Kommunikation war ich kurz echt ziemlich pissed, ehrlich gesagt, und habe echt so gedacht, so war Leute ernsthaft und aber habe jetzt also durch die durch die Nachkommunikation quasi echt wieder total das Vertrauen gewonnen, weil man einfach sieht, wie sehr die beiden Frauen da mit drin hängen mit ihrer Vision und wie sehr sie das steuern und da
00:42:52
Speaker
und da jetzt einfach sehr, sehr gut nachkommunizieren quasi und man merkt, wie die Updates kommen, man merkt, wie die Transparenz kommt und ich hab da ehrlich gesagt vollstes Vertrauen in das Bubble Team, dass die jetzt in den nächsten 18 Monaten das so sehr optimieren werden, dass man auch, dass es viel verständlicher wird, viel transparenter, dass die Sachen, die gerade noch schief laufen, geupdated werden. Das sieht man jetzt gerade, wenn jetzt gerade ein
00:43:19
Speaker
ein Feature Update oder eine Feature Anfrage irgendwie im Forum kommt zu dem ganzen Thema Pricing und so wird es super schnell umgesetzt. Und ich glaube, da kann man wirklich sehr zuversichtlich sein, dass das auch nach wie vor das Bubble keine 180 Grad Drehung macht zu
00:43:39
Speaker
zu einem unbezahlbaren Tool, weil ehrlich gesagt würden sie sich auch damit ins eigene Knie schießen, wenn sie da einfach den Großteil ihrer Community verlieren würden. Und das sieht man jetzt schon, dass sie das nicht tun und da echt auf dem richtigen Weg sind. Genau, deshalb auch ich nach wie vor riesiger Fan, obwohl ich ja gar nicht der Experte von uns beiden bin oder bei uns im Team von Visual Makers auch inzwischen nicht mehr. Da gibt's einige, die mich inzwischen wieder überholt haben mit dem Thema Bubble.
00:44:09
Speaker
Aber ja, nach wie vor großartiges Tool und unerreicht in dem, was Use Cases, Funktionalität und eben auch Community angeht. Ja, total. Ja, hundertprozentige Zustimmung. Wenn ihr Fragen dazu habt, wir werden das Thema sicherlich nochmal aufgreifen in den nächsten Monaten. Aber wenn ihr
00:44:38
Speaker
Fragen dazu habt, meldet euch gern bei uns in der Community, kommt einfach zu uns in Slack und fragt, wenn ihr Sachen nicht versteht oder sowas in eurer App. Oder wenn ihr euch fragt, lohnt sich Babel überhaupt noch für mein Projekt? In den meisten Fällen wird es nach wie vor der Fall sein. Und genau, wenn ihr euch da unsicher seid, kommt einfach auf uns zu, fragt uns am liebsten per Slack, ihr könnt aber auch eine Mail schreiben. Genau, und dann können wir euch da helfen.
00:45:11
Speaker
Jo, bleibt abschließend zu sagen. Happy building. Bis zum nächsten Mal. Ja, wirklich. Happy building. Bis zum nächsten Mal. Bis nächste Woche. Genau, macht's gut.