Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#24 - Wie Low- und NoCode Softwareentwicklern effizienteres Programmieren ermöglicht - mit Marco Berger image

#24 - Wie Low- und NoCode Softwareentwicklern effizienteres Programmieren ermöglicht - mit Marco Berger

S1 E24 · VisualMakers
Avatar
188 Plays4 years ago

Marco Berger ist Softwareentwickler und Mitgründer der Biberei, einer Low-Code Softwareagentur, die hauptsächlich mit Bubble arbeitet.

Warum LowCode die logische Weiterentwicklung von klassischer Programmierung ist, wie Hausmeister und Developer zusammenpasst und warum man sich selbst nie zu ernst nehmen sollte - darüber und noch viel mehr haben wir mit ihm gesprochen.

Mehr zur Biberei: www.biberei.de

Podcasts transkribieren mit Product-P: www.product-p.com 

Mit dem Code PARROTPOWER bekommst du 20% Rabatt beim ersten Aufladen deines Guthabens. 

Marco auf LinkdIn: https://www.linkedin.com/in/marco-berger/


Tritt unserer kostenlosen NoCode Community bei: https://bit.ly/3iLTpZW

------------------------------------------------------------------------ VisualMakers.de ist eine Lernplattform und Community für den Bereich NoCode. Lerne mit uns, wie du Webseiten, Web-Apps & Mobile-Apps und Prozesse automatisieren kannst, ohne eine Zeile Programmiercode schreiben zu müssen.

Recommended
Transcript

Einführung in den Visual Makers Podcast

00:00:00
Speaker
Mir ist Low-Code und No-Code schon in Form von einer Arbeitseinstellung, die ich hatte, begegnet, ohne dass ich wusste, dass es mir begegnet. Also was möchte ich damit sagen? Arbeitseinstellung. Ich habe immer probiert, so viel wie möglich fertige Dinge zu benutzen. Herzlich willkommen zum Visual Makers Podcast. Ich bin Alex. Und ich bin Lilith. Wir unterhalten uns jede Woche über Themen rund um No-Code.

Vorstellung von Marco Berger

00:00:30
Speaker
Marco Berger ist Softwareentwickler und Mitgründer der Biberei, einer Low-Code-Software-Agentur. Marco, wir freuen uns sehr, dass du heute hier mit dabei bist. Ja, hi. Vielen Dank für die Anleitung. Ich freue mich auch. Marco, in deiner LinkedIn-Biografie steht, du bist Softwareentwickler und Hausmeister. Wie passt das denn zusammen?
00:00:46
Speaker
Das passt eigentlich ziemlich gut zusammen. Ich mache auch mal solche Dinge wie Kabel verlegen, Lampen aufhängen. Ich habe zusammen mit meiner Frau Sarah gegründet. Wir arbeiten von zu Hause aus.

Marcos Karriereweg

00:00:58
Speaker
Das heißt auch, wenn hier jetzt mal was anfällt, dann bin ich halt einfach auch der Hausmeister im Homeoffice sozusagen.
00:01:05
Speaker
Und zum anderen natürlich, ich werde dir vielleicht auch jetzt merken, ich nehme mich gern nicht so ernst. Und dazu gehört es halt einfach auch, dass ich mir jetzt nicht so einen Titel wie CEO oder sowas verpasse, sondern mich halt einfach auch Hausmeister nenne. Ja, sehr cool. Das gefällt mir auf jeden Fall. Magst du mal so ein bisschen von dir erzählen? Wie war so dein Werdegang bisher? In welchen Firmen hast du gearbeitet? Genau.
00:01:31
Speaker
Ja, genau. Also ich bin Wirtschaftsinformatiker von der akademischen Seite her. Also ich habe einen Bachelor und einen Master in Wirtschaftsinformatik gemacht.
00:01:39
Speaker
und habe mein Berufsleben gestartet bei IBM International Business Machines. War früher ein sehr, sehr großer, sehr prestigeträchtiger Name. Heute leider mittlerweile nicht mehr ganz so doll. Bin aber sehr froh, dass ich da angefangen habe. Also das hat mich sehr geprägt. Ich habe da fünf Jahre gearbeitet, habe da ein Studium gemacht, auch noch ein duales Studium und habe da einfach so ein bisschen diesen amerikanischen Touch mitgekriegt und bin deswegen, glaube ich, auch
00:02:09
Speaker
was so Effizienz angeht und zahlengetrieben sein angeht, glaube ich, ganz gut ausgerüstet und bin da froh, dass ich einfach nicht in einem deutschen Unternehmen gestartet bin, muss ich leider ehrlich so sagen.

Gründung von Biberei

00:02:23
Speaker
Hab dann weitergemacht, bin zu Muvl, das ist ein Corporate Startup von Daimler.
00:02:30
Speaker
Gibt es mittlerweile auch nicht mehr, hat sich beschäftigt mit einer Mobilitäts-App, also da haben wir eine Mobilitäts-App entwickelt, mit der man ganz verschiedene Angebote innerhalb der Städte buchen konnte, also von Car to Go über Bahn bis hin zu Nextbike, Scooter, alles Mögliche.
00:02:49
Speaker
Genau, und habe da eigentlich gearbeitet in einer Dreimann-IT-Abteilung. Also wir haben da mit einem relativ kleinen Team relativ viele User versorgt und hatten auch immer so die Herausforderung, möglichst effizient zu arbeiten, weil wir halt einfach zu wenige Leute waren für das, was wir alles gemacht haben. Und auch da war es so ein Job, also ich habe es gerade schon mal gesagt, wo ich auch mal unterm Tisch gelegen habe und Kabel verlegt habe, das hat da dazu gehört.
00:03:14
Speaker
Das andere Ende dieser Bandbreite war dann die Softwareentwicklung, also ich habe da zum Teil auch Automatisierungstools geschrieben, programmiert, einfach selbst programmiert, für die Personalabteilung zum Beispiel. Genau, das waren so zwei Jahre dazwischen und mein letzter angestellten Job war bei der Qocentric AG, wo ich dann als
00:03:35
Speaker
reiner Software-Entwickler gearbeitet habe auf Kundenprojekten. Also da war es wirklich ganz klassische Software-Entwicklung. Wir haben einen Online-Shop gebaut für Porsche. Wir haben IoT-Entwicklung gemacht. Ja, 100 Prozent Individual-Software entwickelt. Hab da auch in verschiedene Rollen reingeschnuppert, als DevOps-Spezialist gearbeitet, als Grandmaster gearbeitet, Projekte geleitet.
00:03:59
Speaker
Also auch da wieder ganz, ganz viele verschiedene Sachen. Genau, und 2021, also im Januar diesen Jahres, haben wir dann mit der Sara zusammen gegründet.
00:04:11
Speaker
auch teilweise aus den Erfahrungen heraus, die ich in meiner Berufslaufbahn gemacht habe, auch aus Saras Erfahrungen heraus. Also wir haben immer festgestellt, dass doch Softwareentwicklung relativ kompliziert und umfangreich ist und haben uns dann halt auch einfach gefragt, wie das einfacher zu machen geht, wie das schneller zu machen geht, wie das vielleicht auch sogar mit mehr Qualität zu machen geht und haben dann aus diesem Gedanken heraus unter anderem die Biberei gegründet
00:04:39
Speaker
und bieten jetzt, wie du schon gesagt hast, Alex, Low-Code Softwareentwicklung an und spezialisieren uns da auf eine Verbindung zwischen Low-Code und echter Softwareentwicklung. Also das ist ja im Prinzip auch der Hintergrund, wo ich herkomme.
00:04:55
Speaker
Super spannend. Und Sarah hatten wir, hatten wir auch schon bei uns im Podcast vor einigen Folgen. Ich weiß nicht mehr, welches war die zehnte, elfte, dreizehnte, irgendwie sowas. Wir haben da auch schon viel, viel über die Bibelreihe erfahren. Und auch schon ihren Einblick quasi auf Low Code und No Code und so gehabt. Aber aus der Sicht einer, ja, als sie, als
00:05:18
Speaker
Sie als Produktentwicklerin. Jetzt wäre es aber auch nochmal spannend zu hören von dir aus Sicht eines Softwareentwicklers quasi.

Low-Code und No-Code erklärt

00:05:27
Speaker
Was ist denn Low-Code und No-Code für dich und wie habt ihr das überhaupt entdeckt?
00:05:33
Speaker
Ja, das ist eine ganz spannende Frage. Da haben wir heute beim Mittag auch erst wieder darüber diskutiert, was eigentlich Low-Code und No-Code ist. Und ich habe auch gesagt, ich ziehe oft die Software-Entwicklerbrille auf und ich möchte es auch mal mit der Brille hier beschreiben. Ich habe eigentlich, mir ist Low-Code und No-Code schon
00:05:49
Speaker
in Form von einer Arbeitseinstellung, die ich hatte, begegnet, ohne dass ich wusste, dass es mir begegnet. Also was möchte ich damit sagen? Arbeitseinstellung. Ich habe immer probiert, so viel wie möglich fertige Dinge zu benutzen. Also wenn man jetzt Software entwickelt, dann gibt es solche Dinge wie MPM oder
00:06:11
Speaker
Im Python kann man sich Packages in seine Software reinziehen und da gibt es immer ganz viel vorgefertigte Libraries, Packages, Integrationen, die man schon benutzen kann und das war für mich
00:06:25
Speaker
von Anfang an schon wichtig, die Dinge so viel wie möglich zu benutzen, weil ich einfach das Gefühl hatte, das hilft mir zum einen, weil ich das nicht selber coden muss und das hilft natürlich auch der Qualität, weil das halt von jemandem gebaut wurde.
00:06:41
Speaker
mit der Absicht, dass es wiederverwendet wird und es wurde auch dann schon oft verwendet und ist oft getestet. Also in der Softwareentwicklung hat man ja diesen Begriff von Härten von Servern zum Beispiel. Also man härtet eine Anwendung dadurch, dass sie halt einfach der Benutzung ausgesetzt wird. Und wenn so ein Package tausendmal benutzt wurde, dann weiß ich, dass das gehärtet ist und dass das gut funktioniert.
00:07:03
Speaker
und wahrscheinlich auch viel besser funktioniert, als ich das jemals programmieren kann. Und von daher habe ich dann halt oft schon dafür gekämpft, dass wir fertige Dinge einsetzen, was wiederum ein schwieriger Kampf ist mit vielen Entwicklern, weil sie doch sehr gerne auch selber entwickeln. Also da geht es auch oft darum, das Handwerk einfach auszuleben und Spaß daran zu haben, was ich auch völlig nachvollziehen kann.
00:07:26
Speaker
Aber genau, also da ist es mir im Prinzip schon begegnet und dieser Weg, der wurde dann halt immer schmaler, sag ich mal hin, zu den echten Low-Code und No-Code-Tools. Also das ging dann über Packages einsetzen. Dann haben wir ein Projekt gemacht, wo wir eine App gebaut haben, eine Mobile App, die wir mit Flutter und Firebase gebaut haben. Also schon auch ein Entwicklungsframework, was
00:07:49
Speaker
ja, viele Teile mitbringt einfach und sind dann diesen Weg weitergegangen hin zu anderen Anwendungen, wo wir geguckt haben, wie kann man zum Beispiel mobile Apps noch einfacher bauen. Da läuft einem dann zum Beispiel Adalo über den Weg oder von AWS gibt es auch ein Tool, das heißt, glaube ich, Honeycode.
00:08:07
Speaker
Honeycode, genau, er nickt, ja. Genau, und über diesen Weg sind wir dann praktisch zum Low-Code gekommen und zu den Low-Code-Tools und sind jetzt mittlerweile bei Babel angekommen und machen damit ja, ich sag mal, den größten Teil unserer Projekte in Low-Code in der visuellen Programmierung und programmieren nur noch relativ wenig dazu.
00:08:30
Speaker
Ja, krass. Super spannend, aber so die Reise zu sehen, dass ihr eigentlich immer zugesehen habt, effizienter bei der Entwicklung zu werden und immer wieder fertige Komponenten hinzuzuziehen, um das Ganze schneller voranzutreiben. Ja, es ist auch total verrückt. Also vielleicht auch mal, um euch ein Beispiel zu geben aus der Praxis. Das letzte Projekt, wo ich entwickelt habe, da haben wir in einem Team mit drei Leuten entwickelt, also drei Entwickler.
00:08:56
Speaker
Und wir haben, ich glaube, drei oder vier Monate haben wir nur mit Projekt Setup verbracht, wo wir eigentlich noch gar nicht an Funktionalität entwickelt haben. Und wenn man dann davon ausgeht, dass ein Entwickler einen Tagessatz von ungefähr 1000 Euro hat, dann kann man sich schnell hochrechnen, dass da über 200.000 Euro erst mal ins Land gehen, bis man überhaupt zu der Stelle kommt, um eigentliche Businesslogik zu schreiben.
00:09:23
Speaker
um eigentlich Wert zu erzeugen. Und das ist halt so dieser, auch ich hab's vorhin als Motivation gelernt, das ist halt dieser Knackpunkt, wo wir jetzt sehen, das ist halt irgendwie total cool, wenn ich sagen kann, okay, du musst jetzt nicht 200K erstmal irgendwo hinwerfen, damit du ein Softwareprojekt am Laufen hast, sondern du nimmst halt ein Zehntel davon und hast die ganze Software fertig. Das ist jetzt vielleicht ein bisschen übertrieben, aber die Größenordnungen sind schon gigantisch.

Übergang zu Low-Code Lösungen

00:09:52
Speaker
Auf jeden Fall. Und wann war das so zeitlich ungefähr konkret, wo ihr jetzt auf die ersten No-Code-Anwendungen gestoßen seid? Das heißt, ihr habt ja konkret nach solchen Lösungen gesucht oder sind die euch quasi über den Weg gelaufen? Zeitlich ist das schon ungefähr in den Januar einzuordnen. Also das ist fast zeitgleich mit unserer Gründung. Wir haben unser erstes Projekt schon angefangen vor der eigentlichen Unternehmensgründung.
00:10:18
Speaker
September, Oktober letzten Jahres haben das ungefähr drei, vier Monate gemacht. Das war diese Mobile App, von der ich gesprochen habe. Und relativ kurz nach der Gründung ist uns dann Bubble schon über den Weg, also wir benutzen jetzt hauptsächlich Bubble als Low-Code-Anwendung, ist uns das über den Weg gelaufen. Wir haben auch Adalo ausprobiert. Wir haben Google AppSheet ausprobiert. Das war so der Zeitpunkt, an dem wir das entdeckt haben. Genau, und dann ging es eigentlich,
00:10:47
Speaker
Heute haben wir August. Es ging dann relativ schnell, dass wir da reingesogen wurden in dieses Universum und wollte ja mittlerweile auch quasi nur noch das anbieten. Also ich mache jetzt gerade zwar noch ein traditionelles Software-Entwicklungsprojekt. Das haben wir halt quasi schon verkauft, bevor wir uns fokussiert haben auf Low-Code. Aber wir sind jetzt schon so weit, dass wir sagen, wir bieten nur noch das an und fokussieren uns da vollständig drauf.
00:11:12
Speaker
Ja, da haben wir auch letztens diesen LinkedIn-Post von dir gelesen, wo du schreibst, früher habe ich gesagt, unsere Software passt auf alle und dann, wir beschreiben nur noch Individualsoftware und jetzt halt, wir finden die beste Lösung für jeden. Spielt da auch dieses Low-Code-Thema mit rein, dass ihr das mit klassischer Software kombiniert oder ist es wirklich, dass ihr mit Low-Code wirklich alles jetzt gerade umsetzen könnt?
00:11:38
Speaker
Das ist eigentlich, würde ich sagen, ein Thema meiner Biografie, wenn ich das so sagen kann. Also ich habe da vorhin schon am Anfang probiert, ein bisschen zu beschreiben. Ich bin eigentlich schon relativ viel in den Herge eiert zwischen verschiedenen Jobs. Also ich habe der Wirtschaftsinformatik studiert, konnte mich dann auch nie so richtig entscheiden, ob ich jetzt Softwareentwickler sein möchte oder nicht. Habe auch Jobs angenommen und gemacht, wo das nicht Teil war. Also wo ich halt einfach auch andere Dinge gemacht habe.
00:12:08
Speaker
Ja, und das gehört für mich halt einfach dazu. Ich glaube jetzt mittlerweile an den Punkt zu sein, wo ich das Gefühl habe, Low-Code ist so die gute Mitte, die ich für mich gefunden habe. Deswegen auch dieser Post, das war ja quasi am Anfang komplett 100% auf der Standard-Software-Seite, dann 100% auf der Individual-Software-Seite und jetzt halt irgendwo in der Mitte. Und das ist für mich persönlich auch ein ganz schöner Spot, weil ich da
00:12:37
Speaker
teilweise den Spaß habe, Software selber zu entwickeln, aber nicht den Krampf habe, wirklich dieses große Projekt-Setup oder sowas zu machen oder Dinge zu implementieren, auf die ich keine Lust habe. Genau, also das ist so ein bisschen dieser Schlingerweg, der dann zum Mittelweg geworden ist sozusagen.
00:12:55
Speaker
Ja. Glaubst du denn, dass wir haben das mit anderen Gästen teilweise in der Diskussion gehabt? Würde mich interessieren, wie du das siehst. Glaubst du, dass No-Code und Low-Code einmal sinnvolle Begriffe überhaupt so als der Begriff sind? Und ob das Sinn macht, das so stark von klassischem Code zu trennen? Also ich denke schon, dass es Sinn macht, einen anderen Begriff dafür zu haben.
00:13:22
Speaker
Für mich persönlich ist Low-Code und No-Code auch kein Begriff, der sonderlich falsch ist oder so. Der beschreibt für mich schon relativ gut, was wir da machen und was die Intention ist. Ob es die Trennung zwischen den beiden braucht, da würde ich sagen nein. Ihr merkt es auch, wie ich die Wörter verwende. Für mich ist es synonym, vielleicht auch teilweise nicht synonym, aber es ist auch nicht klar, wo die Grenze verläuft. Deswegen sage ich meistens Low-Code, No-Code, wenn ich drüber spreche.
00:13:51
Speaker
Aber die haben für mich ungefähr die gleiche Bedeutung. Für mich ist wichtig eher so die Intention, die dahinter steckt. Das ist für mich weniger programmieren zu müssen und schneller und effizienter zu sein. Und insofern beschreibt für

Herausforderungen bei der Low-Code-Einführung

00:14:07
Speaker
mich dieser Begriff das eigentlich ganz gut.
00:14:09
Speaker
Spannende Frage ist dann wiederum, wie man die Abgrenzung macht zu dem, was ich jetzt traditionelle Softwareentwicklung nenne, weil da wird dann, da braucht man dann wieder den neuen Begriff, weil das ist nicht mehr einfach nur Coden, sondern das ist halt irgendwie traditionelles Coden.
00:14:26
Speaker
Ja, und das verändert sich ja auch immer wieder. Das heißt dann auch traditionell ist dann auch die Frage, ich verstehe total, was du meinst und auch total bei dir. Ja, ist aber spannend. Vielleicht auch noch als kleiner Gänzung dazu, was ich ein ganz spannendes Bild finde, was sich auch ständig bei mir im Kopf abspielt.
00:14:46
Speaker
Wenn man sich Technologien auf einer Zeitleiste vorstellt und man stellt sich vor, die Dinge wandern von links nach rechts und links sind sie ganz neu, rechts sind sie schon eher Commodity, also eher alt, dann ist das für mich ein Zeitstrahl, auf dem immer wieder neue Dinge auftauchen und die wandern von links nach rechts und irgendwo zwischendrin gibt es eine Grenze, wo sie nicht mehr neu sind, sondern wo sie Commodity werden.
00:15:10
Speaker
Und ich finde, Low-Code ist halt einfach auch einer der Begriffe, die auf dieser Zeitleiste auftauchen, weil mit Community wird zum Beispiel die Entwicklung von Web-Anwendungen
00:15:21
Speaker
Mit Low-Code wird die Entwicklung von Web-Anwendungen irgendwann commodity oder ist sie jetzt im Prinzip schon und es wird einfacher, es ist mehr abstrahiert, es ist zugänglicher und ich glaube dieser Begriff wird einfach zumindest in meinem Kopf weiter nach rechts wandern, also weiter Richtung der alten Dinge, aber auf der linken Seite werden wieder ganz neue Sachen hinzukommen.
00:15:42
Speaker
Also es gibt ja zum Beispiel noch solche Bereiche wie IoT oder Data Science, KI und so weiter. Die sind ja jetzt auch noch nicht für den für den Normalbürger, sag ich mal, zugänglich. Die werden sich aber auch so weit weiterentwickeln, dass die zugänglich werden. Und dann braucht man dafür vielleicht auch wieder einen anderen Begriff, wenn ich dann jetzt KI benutzen kann, um Dinge zu tun. Und ich muss dafür nicht programmieren lernen.
00:16:09
Speaker
Wie siehst du so die Adaption Rate in deinem Umfeld? Also vielleicht hast du noch Kontakt zu anderen Entwicklern, zu alten Arbeitskollegen und so weiter. Nutzen die auch schon Low-Code-Tools oder ist das eher noch kein Thema? Das ist sehr gering und ich überlege oft, wie ich mich dazu positionieren soll oder wie ich das bewerten soll. Ich finde es eigentlich sehr schade und ich finde es auf der anderen Seite auch etwas gefährlich, weil ich
00:16:36
Speaker
tatsächlich auch sehe, wie gut diese Tools sind und wie viel sie auch einfach schon können. Also gerade dieser Fakt, wie viel sie können, ist überhaupt nicht bei der Software-Entwickler-Community angekommen. Und da hat man halt als
00:16:52
Speaker
Also ich komme ja aus Firmen, die Projekte verkaufen, die Softwareentwicklung als Projekte verkaufen. Und wenn man da am Ball bleiben muss, dann muss man sich auch mit neuen Dingen beschäftigen. Und wenn man jetzt überhaupt nicht auf dem Radar hat, wie viel das eigentlich kann und wie viel man damit machen kann, dann läuft man halt auch Gefahr, selbst als Anbieter vom Markt zu verschwinden. Und das finde ich ziemlich gefährlich. Vielleicht auch mal als plastisches Beispiel.
00:17:18
Speaker
Wir hatten 2018 eine Firmenkonferenz. Also es gibt immer, gab bei der Concentric oder, also gibt sie jetzt auch noch digital, aber vor Corona gab sie halt auch in Person. Und da sind ungefähr vier bis 500 Leute Software-Entwickler, die da zusammenkommen und sich über verschiedene Themen austauschen.
00:17:37
Speaker
Da gab es ein Vortragsangebot, das hieß Low-Code. In diesem Low-Code-Vortrag, da saßen der Vortragende und ich allein 2018 von 500 Leuten. Also es ist auf jeden Fall nicht so wirklich auf dem Radar. Frage nach den Gründen dafür ist wieder auch eine andere Frage, aber ich sehe sehr, sehr wenig Adoption, wenn ihr danach fragt.
00:18:07
Speaker
Es gibt einzelne Beispiele, also ich habe jetzt mal vor kurzem mit einem Kollegen gechattet wieder. Da hat ein Kunde das angefragt, also da ist sozusagen der Bedarf über den Kunden reingekommen. Nicht aus der Überlegung heraus, wie man das Problem lösen konnte, sondern halt einfach explizit angefragt. Und dann geht das schon, also dann beschäftigen sie sich auch damit. Also derjenige hat sich auch damit beschäftigt und fand das auch cool und hat dann auch Fragen gestellt.
00:18:34
Speaker
Aber den Zugang dazu zu finden, das ist, glaube ich, noch ... braucht noch etwas für die Entwickler-Community.

Vorteile von Low-Code für Startups

00:18:43
Speaker
Was sind denn die Gründe, glaubst du, wenn du sagst, die Frage nach den Gründen ist noch mal eine andere? Also, ich glaube, zum einen ist es halt wirklich, dass es unterschätzt ist, was es kann. Ja, in ganz vielerlei Hinsicht, also Funktionalitäten, Skalierbarkeit,
00:19:03
Speaker
was es für Kunden leisten kann, welche Features drin sind. Zum anderen ist es, glaube ich, auch Skepsis, die in vielen Köpfen drin ist, im Sinne von, das skaliert nicht, kann ich das, was ich brauche? Es gibt auch das Empfinden davon, dass der Code nicht mir gehört.
00:19:31
Speaker
baue jetzt zum Beispiel meine Geschäftslogik in die Anwendung, in die Low-Code-Anwendung rein und habe dann das Gefühl, dass der Code nicht mehr mir gehört. Also diese Diskussion um den Code an sich gibt es ganz viel auch im Dienstleister-Einkaufenden-Verhältnis. Da ist es dann immer die Frage, liegt der Code beim Dienstleister oder liegt der auf den Servern von demjenigen, der es einkauft und dem am Ende die Software gehört. Also da gibt es immer ganz viel Diskussion darum.
00:19:58
Speaker
Wie siehst du das? Also was antwortest du darauf, wenn jemand solche Bedenken bezüglich Low-Code-Anwendungen, gerade vielleicht Bubble sogar auch sagt, weil Bubble ja so eins der mächtigsten Tools ist.
00:20:11
Speaker
Also für mich ist das eine Frage des Bewusstseins. Also man muss sich darüber klar sein, welchen Deal man eingeht. Und der Deal ist hier für mich, ich bekomme Geschwindigkeit, ich bekomme Qualität, ich bekomme ganz viele Features, ich spare ganz viel Geld. Und der Preis, den ich dafür zahle, ist, ich habe den Login, also Login ist halt dieser böse Begriff, der da immer rumgeistert in dieser Diskussion. Ich habe den Login in den Anbieter, also im Bubble in dem Fall oder Adano oder wer auch immer.
00:20:42
Speaker
Aber dieser Login bringt mir halt auch sehr viel auf der anderen Seite und für mich überwiegt ganz klar diese Seite, was bringt mir das, wenn ich mich darauf einlasse.
00:20:52
Speaker
Also wenn ich zum Beispiel auch den Code selber schreibe, dann verliere ich zum Beispiel Updates. Also ich muss meine Software, die ich selber schreibe, ständig updaten. Ich muss mich ständig up-to-date halten. Ich muss neue Features entwickeln. Wenn ich mich in dem Login bei einem Anbieter begebe, dann bekomme ich all diese Features kostenlos dazu. Also nicht kostenlos dazu, aber sie sind in der Rate inbegriffen.
00:21:14
Speaker
Also ich habe nicht nur eine Betrachtung auf den Zeitpunkt, wo ich das kaufe, wo ich diesen Deal angehe, sondern auch in der langen Frist kriege ich nochmal viel mehr raus, als ich selber machen könnte.
00:21:28
Speaker
Genau, und der zweite Punkt, wo wir uns auch so ein bisschen einsortieren als Biberei. Wir sind ja viel bei Gründern, also bei Unternehmensgründern unterwegs oder auch bei Corporate Startups zum Beispiel. Also kleine, agile Abteilungen, die auch entscheidungsfreudig sind und Entscheidungen treffen können. Und da ist es meistens so, dass sie Produkte ausprobieren, dass sie Software ausprobieren.
00:21:55
Speaker
Und man kann durchaus sagen, man macht diese Ausprobierphase mit Low-Code und wenn man merkt, man hat da jetzt den super Spot gefunden und hat da ein Geschäftsmodell getroffen, was super viel Geld bringt, dann kann man das immer noch mit einem richtigen evaluierten Business Case viel Geld in die Hand nehmen und dann wirklich selber Software entwickeln.
00:22:17
Speaker
Aber dann hat man halt die viel bessere Risikoabschätzung, weil man es vorher ausprobiert hat und dieses Ausprobieren ist halt nicht so teuer geworden. Also ich sehe das nicht schwarz und weiß. Man kann das für bestimmte Phasen nutzen. Man kriegt einiges dafür. Man muss was dafür zahlen. Also das ist immer eine Abwägungssache.
00:22:39
Speaker
Interessant. Wie sieht das bei euch aus? Ihr bei der Bibliothek kombiniert Low-Code mit klassischer Programmierung. Wie kann man sich das an einem Projekt vorstellen? Das kann man sich so vorstellen. Also die Frage ist, wann kommt es dazu, dass wir Programmierung einsetzen? Und das ist ja relativ leicht beantwortet. Das kommt immer an dem Punkt, wo die Features nicht mehr ausreichen oder wo jemand etwas möchte, was man nicht mehr abdecken kann mit Low-Code.
00:23:06
Speaker
Und dann überlegen wir, wie man das machen kann. Ich habe da jetzt ja schon ein paar Jahre Erfahrung und bringe da auch relativ viele Ideen mit und habe da ein relativ großes Spektrum an Lösungen, die mir im Kopf sind. Und sobald wir an so einen Punkt stoßen, wo das der Fall ist, fange ich halt an oder Sarah ja auch. Also sie hat ja auch lange Software entwickelt.
00:23:29
Speaker
beziehungsweise Softwareentwicklungsteams geleitet. Dann fangen wir halt an zu brainstormen und gucken, wie man das gut lösen kann. Genau, wir hatten jetzt zum Beispiel gerade den Fall, wir wollen für eine Dokumentation einen Datenbankdiagramm erstellen.
00:23:45
Speaker
Da habe ich jetzt halt einen bisschen kleinen ungerechten Vorteil, weil ich weiß halt zum Beispiel, wenn ich einen SQL-Dump aus einer Datenbank machen kann, was ich vermutlich im Bubble machen kann, dann kriege ich da einen Pfeil raus, da steht SQL drin und da steht eine Schema-Beschreibung von dem SQL drin. Und auf der anderen Seite gibt es halt kluge Leute, die auch keine Lust hatten, Diagramme zu zeichnen, die haben halt aus dieser Schema-Beschreibung Diagrammgeneratoren gebaut.
00:24:10
Speaker
Und dann kann ich sagen, exportiere einfach diese Datenbank, gib mir das Schema, ich pack das in einen Generator rein, und dann generiere ich dir das Diagramm da draus. Das ist jetzt der ganz kleine Ansatz für das kleine Feature. Und wenn es dann größer wird, dann schauen wir, dass wir jetzt im Bubble zum Beispiel einen API-Connector benutzen. Und dann fange ich an, APIs zu programmieren, mit Funktionalität dahinter, die ich gern zusätzlich hätte.
00:24:38
Speaker
Total spannend. Ich finde es auch total schön. Habe ich vorher noch nie so gehört, diesen Ansatz von, ihr seid eine Software Agentur, die sagt, okay, wir setzen da an, alles, was wir mit Low-Code bauen können, bauen wir mit Low-Code und nur dann, wenn Low-Code das nicht mehr schafft, dann setzen wir klassischen Code ein und nicht andersrum. Finde ich sehr, sehr cool.

Einführung von Product P

00:25:02
Speaker
Unser Motto ist ja auch Mut für digital. Und was zum Mutmachen dazugehört, ist ja auch den Leuten zu erklären, hey, es ist kompliziert. Klar, es ist immer noch kompliziert, aber es ist nicht so kompliziert, wie du vielleicht denkst. Ja, da lässt sich drüber streiten. Ich weiß nicht, ob Low-Code komplex ist. Kompliziert ist es auf jeden Fall. Aber in der Regel weiß ich, was passiert, wenn ich irgendwo draufklicke. Das weiß ich bei Code manchmal nicht, wenn ich da Änderungen einfüge.
00:25:32
Speaker
Genau, aber Mut für digital ja auch in dem Sinne, wenn ich Gründer bin und ich stehe vor der Hürde zu entscheiden, ob ich jetzt eine Investition mache über 150.000 Euro, weil ich eine Software entwickeln möchte, dann verlässt mich halt sehr schnell der Mut. Wenn ich die Investitionsentscheidung aber treffen muss über ein 20.000 Euro Projekt, dann verlässt mich hoffentlich nicht so schnell der Mut und ich probiere das einfach mal aus.
00:26:00
Speaker
Ihr habt jetzt ja vor kurzem euer erstes eigenes Produkt gelauncht, Product P. Was hat es damit auf sich und wie seid ihr dazu gekommen?
00:26:10
Speaker
Product P, was hat es damit auf sich? Der Anlass, in dem wir jetzt darüber sprechen, ist eigentlich ganz aufschlussgebend, weil es geht um Podcasts. Bei Product P geht es darum, Podcasts zu transkribieren. Transkribieren heißt, wir verwandeln auf Audio aufgenommene Sprache in Text.
00:26:31
Speaker
Man kann also quasi ein Audiophile hochladen und es wird dann automatisch von Cloud Services in Text umgewandelt und man bekommt einen Transkript von diesem Text. Also würden wir drei jetzt unser Audiophile hochladen, dann bekämen wir danach ein Transkript, wo dann mehr oder weniger gut die Sprache erkannt wurde, nach Sprechen dann aufgeteilt wurde und man kann dann dieses Transkript für
00:26:55
Speaker
jegliche Dinge verwenden, auf die man Lust hat. Also man kann es als Shownotes nehmen, man kann das Publischen auf einem Blog, man kann das irgendwo einfügen als Interview. Genau, und wir sind im Prinzip darauf gekommen, weil ja die Sarah auch selber ein Podcast macht und auch selber viel durch die Podcasts durchreißt und viel spricht.
00:27:18
Speaker
Und im Prinzip wollten wir gerne, also es gibt das Produkt P, wie wir es jetzt kennen, das ist das Transkribieren von Audiofiles. Und wir wollten aber eigentlich gerne eine Volltextsuche für Podcasts entwickeln, weil wir immer das Problem hatten, wir können nicht richtig nach Podcasts suchen. Wir können zwar nach der Beschreibung suchen und nach dem Titel und nach den Show Notes vielleicht, aber man kann da einfach nicht reingucken und gucken, was da drin steht. Also man hat kein Google, was den Inhalt des Podcasts durchsucht.
00:27:48
Speaker
Und das ist so im Prinzip die Phase zwei, in die wir mit Product View wollen. Also es ist für die lange Frist angedacht, dass wir diese Transkripte verarbeiten und durchsuchbar machen mit einer Volltextsuche, die gut funktioniert und dann so ein Prinzip ein Google für Podcasts entwickeln, wo man dann das gesprochene Wort durchsuchen kann. Spannend. Genau.
00:28:09
Speaker
Auch bei uns auf Visual Makers gelistet, wer da mehr darüber erfahren will, da findet ihr auf jeden Fall den Link auch dahin. Sehr, sehr cooles Projekt. Kannst du da technisch ein bisschen drauf eingehen, wie ihr, genau, wie ist es gebaut? Es ist auf Bubble gebaut, richtig?
00:28:29
Speaker
Genau. Also technisch ist das, im Prinzip kann man das trennen in Frontend und Backend, sage ich mal, wenn man wieder in den Entwickler sprecht, zurückfällt, was aber nicht so ganz stimmt, weil wir im Bubble im Prinzip alles bauen, was mit dem User zu tun hat. Also im Bubble gibt es eine Landingpage, da gibt es ein Login, da gibt es eine Registrierung. Der User kommt also zu uns, registriert sich, lädt dann sein Audiofile hoch.
00:28:56
Speaker
und kann dann über eine Stripe-Anbindung bezahlen für diese Transkribierung und dann wird das transkribiert. Und all diese Clicks, all diese User-Interaktionen, all das, was der User sieht, ist in Bubble gebaut. Da geht es einfach darum, das habe ich ja vorhin schon mal gesagt, das sind die Teile, die für mich Commodity sind.
00:29:15
Speaker
Die möchte ich nicht programmieren, weil das hat keinen Wert. Das sind nur Buttons und Klicks und UI, die einfach nur dazu führen, dass der eigentliche Wert geliefert wird. Und der eigentliche Wert ist das, was ich vorhin als Backend beschrieben habe. Das ist die automatische Transkribierung von den Audiofiles.

Technische Umsetzung von Product P

00:29:34
Speaker
Und für diese Transkribierung benutzen wir Amazon Web Services. Da gibt es einen Service, der heißt Transcribe. Ich glaube, der heißt einfach nur Transcribe Service. Der wird dafür genutzt, Audiofiles zu transkribieren. Also, die zielen hauptsächlich ab auf Telefoncenter, auf Callcenter, wo dann Anrufe transkribiert werden. Also, wenn ihr irgendwo eine Nummer wählt und gefragt werdet, ob diese Aufzeichnung verwendet werden kann zu Auswertungszwecken und ihr Ja sagt, dann ist das
00:30:03
Speaker
die Wahrscheinlichkeit hoch, dass es in diesem Service landet. Und dieser Service arbeitet da im Hintergrund, kriegt diese Audiofiles und liefert die Sprache zurück. Das sind Prozesse, die sind schwergewichtig, die dauern lange, die kann man auch unter Umständen nicht allein programmieren, weil es da einfach sehr, sehr viel Trainingszeit und Daten braucht für diese Algorithmen, damit die gut funktionieren. Und an der Stelle habe ich halt gesagt, okay, ich finde diesen Service cool und ich möchte den gerne zugänglich machen.
00:30:32
Speaker
Der ist halt einfach nicht zugänglich für jemanden, der sich nicht Monate damit beschäftigt. Also man muss sich dann, wenn man das nutzen möchte, einen AWS-Account einrichten, dann muss man sich mit den AWS-Services auskennen, man muss wissen, was JSON ist, man muss Sachen hochladen. Also da ist halt jede Menge Barriere drum herum. Und die Barriere habe ich einfach abgebaut und habe das halt über eine Website zugänglich gemacht.
00:30:59
Speaker
Die coole Trennung zwischen Low-Code und richtigen Code ist im Prinzip genau an der Stelle, wo dieser große schwere Algorithmus audiofiles transkribiert. Das mache ich nicht mehr selbst. Das können wir auch nicht im Bubble machen. Das gibt es einfach nicht als Funktionalität. Und das binde ich ein. Um das einzubinden, habe ich eine API entwickelt.
00:31:21
Speaker
Die integriere ich mit Bubble. Also da habe ich auf der Bubble-Seite so ein Plugin, mit dem ich APIs konsumieren kann. Und wenn der User jetzt auf diesen Transkribieren-Button klickt, dann schicke ich da den Dateinamen hin und sage hier bitte Transkribieren. Dann dauert das vielleicht eine Minute, vielleicht zwei, je nachdem, wie lang dieses Audio-File ist. Und dann kriege ich das Ergebnis vom Service zurück und spiele das wieder am Bubble zurück. Und da erscheint dann für den User das Transkript, was er da angefordert hat.
00:31:53
Speaker
Warum habt ihr genau Bubble verwendet dafür? Gibt es wahrscheinlich auch andere potenzielle Kandidaten, die dafür in Frage kämen? Die Frage kann ich gar nicht so richtig ausführlich beantworten, weil ich habe mich ehrlich gesagt relativ wenig mit den anderen Kandidaten beschäftigt. Sicher gibt es viele Kandidaten, mit denen man das auch machen kann. Ich hatte jetzt aber nicht den Bedarf, mich mit anderen zu beschäftigen. Ich hatte da die ganze Palette an Features vorgefunden, die ich brauchte.
00:32:22
Speaker
Ich hab gerade schon gesagt, wir haben da eine Stripe-Integration drin, wir haben einen Connector für APIs, den ich dringend brauchte. Ich hab da eine Datenbank, ich kann da Workflows bauen, ich kann User verwalten. Und wir machen, also hab ich ja vorhin schon gesagt, wir machen unsere meisten Projekte mit Bubble. Deswegen war das für mich einfach die Go-To-Lösung, wo ich nicht viel drüber nachdenken musste.
00:32:47
Speaker
Ja klar, wenn das sowieso euer tägliches Werkzeug ist, dann gibt es einfach keinen Bedarf. Genau. Was ja auch so ein bisschen noch der Hintergrund von Product Peer ist, es ist ja nicht nur eigenes Produkt und eventuell auch mal später irgendwann Geschäftsmodell an sich, sondern es ist ja einfach auch ein bisschen Showcase für das, was wir machen. Showcase und auch Blueprint.
00:33:10
Speaker
weil wir da halt den ganzen Userflow rausprobiert haben. Also wir haben wirklich von Landingpage über Registrierungen, über Bezahlen bis hin zu, man kommt ein Ergebnis geliefert, man kriegt eine E-Mail über das, was man tut, man bekommt hinten eine Rechnung raus. Also da ist wirklich von vorn bis hinten alles abgedeckt und es war einfach auch gut für uns, das mal alles durchzuspielen und durchzudeklinieren, wie das funktioniert und ob das funktioniert. Von daher ist es auch in gewisser Weise ein Test für uns.
00:33:40
Speaker
ob das auch wirklich standhält, ob wir auch wirklich Projekte, die all diese Dinge umfassen, wirklich in Bubble machen können. Das Ergebnis ist eindeutig Ja. Wie lange habt ihr dafür gebraucht, das zu bauen?
00:33:52
Speaker
Das hat gar nicht so lang gedauert. Also ich würde schätzen, Entwicklertage, also jetzt meine Arbeitstage, vielleicht zwei Wochen in Summe. Also da ist, ich würde sagen, ein bisschen mehr als die Hälfte ist da in den traditionellen Code geflossen, also in die Entwicklung auf AWS. Also da gibt es zum Beispiel diese Funktion, die das Transkribieren anstößt. Und da gibt es noch eine weitere Funktion, die diese Audiofiles analysiert.
00:34:22
Speaker
die kriegt die Audiofiles und die liefert zum Beispiel zurück, wie lang sind die Aufnahmen, wie viele Audiochannels gibt es da drin, mit welchem Codex sind die gebaut. Also Informationen, die ich einfach brauche, um den Preis zu berechnen auch unter anderem. Und diese Funktion zu bauen, das hat dann, ich glaube, ein bisschen mehr als die Hälfte gedauert. Und das Frontend dann vorne dran zu bauen mit Bubble, das würde ich mal sagen, vielleicht vier Tage, vier, fünf Tage.
00:34:53
Speaker
Ja, also es ist super schnell. Wenn ich mir vorstelle, ich hätte das früher bei der Core Centric entwickelt, hätten wir wahrscheinlich, keine Ahnung, vier, fünf Monate dafür gebraucht. Ja, Wahnsinn. Cool. Also ich meine, bei so einem Projekt, wo du alles abdeckst, von vorne bis hinten oder auch wahrscheinlich in Kundenprojekten, die du bisher gemacht hast, stell dir ja auch an der einen oder anderen Stelle Begrenzung von Bubble fest. Wo, in welchem Bereich liegen die aktuell? Oder sagt dir, also eigentlich entwickeln wir den geringsten Teil individuell, weil das No-Code-Tool eigentlich schon so viel kann.
00:35:24
Speaker
Also, wir entwickeln wirklich den geringsten Teil individuell. Das ist tatsächlich so. Limitierungen stellen wir... Ich gehe erst mal auf einen anderen Punkt ein, dann wird es einfacher. Was wir bei Babel jetzt oft schon gemerkt haben, ist, dass es auch da ein gewisses Know-how braucht, wie das Internet funktioniert, wie ein kleiner Serverrequest funktioniert, wie Suchungen in der Datenbank funktionieren.
00:35:50
Speaker
Also auch da braucht man ein bisschen Know-how und man muss auch ein bisschen Zeit reinstecken, um zum Beispiel die Pages performant zu machen. Also wir haben das jetzt schon oft gesehen, dass viele Projekte mit unendlich vielen Datenbanks suchen, umherschmeißen und die achtlos verwenden. Und dann hat man halt sehr lange Ladezeiten. Dann dauert es mal zehn Sekunden, bis eine Landing-Page geladen ist, was einfach inakzeptabel ist. Also das sagt halt Google, da lässt dich halt auf Platz.
00:36:20
Speaker
583, wenn du so langsam bist. Da muss man ein bisschen Zeit reinstecken und das ist jetzt nicht unbedingt eine Limitierung vom Bubble, weil man das umsetzen kann mit Bubble, aber man muss sich schon tiefgehend damit beschäftigen, um diese Stolperfallen herauszufinden und zu beseitigen. Und dann die ganz harten Grenzen sind im Prinzip relativ einfach erklärt an dem Beispiel von Product P.
00:36:46
Speaker
Da speichern wir Audiofiles. Also das heißt, ein File ist vielleicht im Durchschnitt 50 MB groß. Und wenn ich jetzt 500, 600, 700.000 Files speichere, dann bin ich da sehr schnell an der Speichergrenze, die mir einen Bubbleplan zum Beispiel erlaubt. Also ich glaube, der erste Plan geht bis 10 GB Storage in der Datenbank und der zweite bis 20 GB. Da bin ich also mit 100 Usern, da bin ich da schon längst oben drüber. Und an der Stelle
00:37:17
Speaker
möchte ich auch einfach den teuren Plan nicht bezahlen und deswegen speichere ich die Files in AWS.

Zukünftige Projekte von Biberei

00:37:22
Speaker
Also auch da wieder gehe ich über diesen API-Connector und sage halt, nö, Files, jetzt lege ich nicht in Bubble ab, sondern ich speichere direkt in AWS in einem S3-Bucket und habe dann halt die Kostenvorteile und habe die im Prinzip auch schon genau da, wo sie dann analysiert werden. Das ist so einfach die ganz harte Grenze. Und dann
00:37:45
Speaker
habe ich ja vorhin auch schon zwei, drei Mal gesagt, die Skalierbarkeit. Also ich möchte im Bubble keine Dinge tun, die sehr viel Rechenpower benötigen. Also sowas wie ein Audiofile analysieren. Zum einen kann ich das da nicht tun oder ich könnte es vielleicht schon in so einer serverseitigen Action, die ich dann irgendwie zusammenfricke mit JavaScript im Hintergrund und so weiter und so fort. Dann habe ich aber wieder eine schlechte Performance von der Webseite.
00:38:13
Speaker
Das möchte ich da nicht tun, das möchte ich im Bubble nicht tun. Und all das, was halt wirklich viel Berechnung braucht, was viel Rechenpower braucht, lange dauert, das kann ich da und möchte ich da nicht machen. Und deswegen machen wir das zum Beispiel in AWS. Also dieses Transkribieren zum Beispiel, das dauert manchmal bis zehn Minuten. Und dann fragen wir halt einfach alle 20 Sekunden bei AWS, dann bist du schon fertig, bist du schon fertig, bist du schon fertig. Und wenn fertig, dann kommt das zurück.
00:38:43
Speaker
Aber dieses Anfragen ist halt, das kostet fast nichts. Also das macht Babel halt im Hintergrund. Das ist ein AP-Request. Das kann ich performancemäßig verkraften. Was ist dann bei euch so für die nächsten zwölf Monate geplant? Also einerseits vielleicht Product P aufs nächste Level heben. Ihr habt ja noch einiges damit vor, was man so hört. Aber vielleicht auch, was die Biberei angeht. Genau, also vielleicht erst mal kurz zum Product P. Also die
00:39:13
Speaker
Unmittelbar nächsten Schritte sind im Prinzip erstmal das Transkript an sich zu verbessern. Also da kommt halt ein Transkript zurück von einem Service, der probiert das bestmöglich zu machen. Das schließt aber nicht aus, dass Dinge da falsch übersetzt sind oder falsch transkribiert sind. Das liegt zum einen daran, dass dieser Algorithmus die nicht erkennt, zum anderen daran, dass man einfach undeutlich spricht oder schnell spricht.
00:39:39
Speaker
Da kommt ganz viel Information von diesem Service zurück. Da gibt es zum Beispiel einen Confidence Score, der mir auf Wortebene angibt, wie gut dieses Wort erkannt wurde. Da ist jetzt erst mal der nächste Schritt, die Information noch verfügbar zu machen und dann den Benutzern die Möglichkeit zu geben, ihr Transkript auch noch zu bearbeiten und wenn möglich mit Unterstützung zu bearbeiten. Also im Sinne von, ich markiere dir die Wörter, die jetzt besonders schlecht erkannt wurden und du kannst dann halt rot markierte Wörter berichtigen.
00:40:09
Speaker
Genau, und dann danach diese Stufe 2, was ich gerade schon erklärt habe, mit der Durchsuchung von den Transkripten. Da überlegen wir jetzt gerade, ob wir noch einen günstigeren Transkribierservice entwickeln. Also da gibt es Open Source Tools, die man nutzen kann von der Mozilla Foundation. Wenn ich Zeit und Muße habe, dann stecke ich da ein bisschen Zeit rein und entwickle da nochmal das Transkribieren auf Open Source, damit ich halt einfach in den Preis runterkomme.
00:40:38
Speaker
Und dann wiederum könnten wir anbieten, hey, lieber Nutzer, du kannst bei uns für umsonst deinen Podcast transkribieren. Das Einzige, was du uns geben solltest, sind die Metadaten dazu. Also sag uns doch bitte, welcher Podcast ist das, welche Episode ist das, damit wir das bei uns in der Datenbank einsortieren können. Und als Gegenleistung bekommst du halt das Transkript, aber vielleicht nicht das ganz supertolle von AWS, sondern nur das Open-Source-Transkript.
00:41:05
Speaker
Das ist so ein bisschen der Plan, um dahin zu kommen, zu dieser Podcast-Suche. Genau, das ist Product P. Und ansonsten bei der Biberei steht jetzt am 23. August schon wieder das nächste Projekt an. Das wird ganz spannend. Da geht es um ein IoT-Projekt. Also auch wieder genau der Space Low-Code mit AWS. Da sind wir in einem Projekt drin.
00:41:31
Speaker
Produktionsmaschinen und ihre Daten, die sie übermitteln, verfügbar gemacht werden in einer WebUI. Das ist genau der Spot, wo es wieder darum geht. Ich baue eine WebUI, kann da Daten abrufen, sehe, ob meine Produktionsmaschine online ist, ob sie gewartet werden muss, ob sie neue Software braucht.
00:41:51
Speaker
Witzigerweise passt das auch genau an das, was ich in meinem letzten Projekt gemacht habe, als ich noch als Angestellter gearbeitet habe. Also da haben wir genau das Gleiche im Prinzip auch 100 Prozent individuell entwickelt. Also das ist eine ganz coole Sache, auf die ich mich persönlich freue, weil ich da mich einfach auch gut auskenne. Und dann arbeiten wir noch an Product B. Also ihr merkt es schon, wir sind nicht ganz so gut in der Namensgebung.
00:42:18
Speaker
sind nach beieinander für uns auch manchmal schwer zu unterscheiden. Product B, wie der Bieber, ist im Prinzip das erste Produkt, mit dem wir angefangen haben, das aber auch ein bisschen umfangreicher ist. Da wollen wir die Projektabwicklung komplett automatisieren. Also das ist vielleicht gerade für Freelancer und für kleine Soloselbstständige zum Beispiel interessant.
00:42:43
Speaker
Da geht es darum, von den Anforderungen über Abnahme der Anforderungen bis hin zur Rechnungsstellung mit einer Chat-Funktion und sich austauschen über Anforderungen, Projekt-Scope verändern und so weiter und so fort. Das bilden wir alles ab, auch mit einer Bubble-App. Wir bauen da jetzt noch Anbindungen an Buchhaltungstools, die in Deutschland verwendet werden, wollen vielleicht auch noch eine Anbindung an eine
00:43:10
Speaker
deutsche Datenbank oder an eine Datenbank gehostet auf einem deutschen Server bauen, um den ganzen Datenschutzbedenken zu begegnen und wollen dann im Prinzip Product B als Projektabwicklungstool anbieten, auch als Software as a Service.
00:43:31
Speaker
Genau, und dann gibt es noch ein weiteres Projekt, wo die Sarah jetzt gerade ausgiebig daran arbeitet. Da wollen wir mit einer Partnerin zusammen eine Online-Ballettschule auf den Weg bringen. Das ist auch ganz interessant. Das ist eine professionelle Balletttänzerin aus Stuttgart, die seit Corona online ihren Ballettunterricht macht.
00:43:53
Speaker
die jetzt zu uns gekommen ist und gefragt hat, wie sie dann ihren Online-Unterricht auf bessere Füße stellen kann. Da wird es dann darum gehen, so eine Art Lernpfade bereitzustellen, wo man bestimmte Figuren, Dinge lernen kann, wo man bestimmte Muskelgruppen trainiert. Und dann auch unter anderem Videos und Fotos von seinen Trainingseinheiten an diese fachkundige Partnerin, die Isabella schicken kann.
00:44:19
Speaker
um dann Feedback einfach zu kriegen, wie man jetzt anders trainieren sollte oder was man noch tun müsste, um ein bisschen besser zu werden. Also das ist auch noch ein spannendes Projekt, auch insofern spannend, dass es für uns die erste Partnerschaft ist, wo wir dann quasi das Software-Knowhow liefern und die Isabella das fachliche Knowhow. Also im Ballett tanzen sind wir beide, glaube ich, nicht zu gebrauchen.
00:44:46
Speaker
Aber super spannend. Ich muss auch ehrlich sagen, ich finde es total schön. Wir haben mit Sarah ja vor ein paar Monaten schon gesprochen. Und da war die Biblierei noch relativ frisch. Und ich finde es total schön zu sehen, wo ihr jetzt schon wieder seid, welche Projekte ihr habt. Ich finde es super inspirierend, wie offen ihr seid, wie neugierig ihr seid auch für alles, was da kommt. Genau, finde ich irgendwie einfach total schön.
00:45:11
Speaker
Das ist auch total verrückt. Also unser Leben ist insgesamt immer schon so verlaufen. Also wir haben, das ist fast schon ein Running Gag bei uns. Wir fragen uns immer, was wir im nächsten Jahr tun werden und geben uns dann immer die Antwort. Wir wissen es eh nicht, was im nächsten Jahr passiert. Also wir wissen nicht, wo wir wohnen werden. Wir wissen nicht, was wir arbeiten werden. Keine Ahnung, was

Persönliches Wachstum von Marco seit der Gründung

00:45:32
Speaker
wir tun werden. Also es kommen ständig Veränderungen. Das ist auch, seitdem wir gegründet haben, ist es auch nochmal einfach,
00:45:38
Speaker
super beschleunigt. Also was wir jetzt in sechs Monaten alles gemacht haben, ist total verrückt. Ja, Wahnsinn. Aber auch super cool. Also ich lerne viel. Ich gehe in Podcast Dinge, die ich früher nie gemacht hätte. Also auch von meinem Naturell. Ja, ich bin eher eher ein introvertierter Mensch und ich werde die Zeit vor Aufgaben gestellt, wie Sales Calls führen, Podcasts sein, Präsentationen halten. Also auch da ist eine ganz große persönliche Entwicklung einfach.
00:46:08
Speaker
Ja, also im Podcast bist du auf jeden Fall schon mal ein Naturtalent. Hast bestanden, auf jeden Fall. Super. Sehr, sehr cool. Auch mega spannende Projekte. Ich bin sehr, sehr gespannt auf das, was kommt. Wie und wo kann man euch denn finden? Also die Viberei, genau, vielleicht kannst du das auch nochmal sagen, wo man die Viberei finden kann. Und auch, falls du gefunden werden möchtest, wo kann man dich denn kontaktieren und mehr über dich erfahren auch?
00:46:35
Speaker
Genau, also die Biberei kann man ganz einfach finden unter biberei.de, also Biberei wie der Biber und der Ort, wo der Biber wohnt, die Biberei.
00:46:46
Speaker
Dann sind wir auch zu finden, beziehungsweise die SAVA mit ihrem Podcast ist zu finden unter lowcodefounders. Da gibt es auch lowcodefounders.com, aber das kann man auch googeln, findet man ganz gut. Über das ProductP kann man uns finden, also auch bei ProductP gibt es einen Impressum und einen Kontaktbutton, wo man dann wiederum zur Biberei kommt. Das ist product-p.com. Und ansonsten, wenn man mit mir persönlich sprechen möchte, findet man mich am besten über LinkedIn.
00:47:14
Speaker
Da kann man mich einfach anschreiben. Ich antworte möglichst schnell auf Nachrichten. Das ist manchmal nicht so schnell, wie die anderen Leute sich das wünschen. Da kommt dann wieder der Software-Entwickler zum Vorschein. Also ich verkriege mich dann schon gerne mal einen Tag und antworte nicht auf Dinge. Also wenn ihr da mich erreichen wollt, dann einfach einen Tag Geduld haben, dann antworte ich schon.
00:47:36
Speaker
Marco, vielen, vielen Dank, dass du bei uns warst. Es hat richtig Spaß gemacht und war echt spannend, auch nochmal die Insights von deiner Seite zu hören. Ja, und ich bin mir sicher, dass wir uns nicht das letzte Mal im Podcast gehört haben und dass wir in ein paar Monaten oder in einem Jahr oder so nochmal sprechen und was sich dann bei euch alles entwickelt hat schon wieder. Da bin ich sehr, sehr gespannt drauf und wünsche euch erstmal ganz, ganz viel Glück und Spaß mit euren jetzigen Projekten.
00:48:02
Speaker
Vielen, vielen Dank, ja. Also, wenn ich dann im Jahr wiederkomme, dann sprechen wir über die Dinge, die dann wie KI, die dann zugänglich gemacht wurde für einfache Anwendungen und so weiter. Ja, hoffentlich. Ja, sehr cool. Auch von mir nochmal vielen, vielen Dank, dass du dabei warst. Megaspannend deine Einblicke in diese Low-Code und No-Code-Szene zu bekommen und auch, genau, mal ein Update zu erhalten, was bei euch gerade so läuft und was ihr noch vor habt. Und ja, freue mich, das zu verfolgen.
00:48:29
Speaker
Ja, also, bis dann. Mach's gut. Ciao! Wenn dir diese Folge gefallen hat, dann freuen wir uns sehr, wenn du uns ein paar Sternchen in der Apple Podcast App dalässt oder uns eine Review schreibst. Das hilft uns nämlich, gefunden zu werden. Und wenn du mehr über No-Code erfahren möchtest, dann schau doch gerne auf unsere Website visualmakers.de vorbei. Ansonsten freuen wir uns, wenn du auch in der nächsten Folge wieder dabei bist. Bis zum nächsten Mal!