Warum haben wir MaxiBlocks gebaut?
Probiere MaxiBlocks kostenlos aus, mit über 500 Bibliotheks-Elementen einschliesslich Basis-Templates. Kein Konto nötig. Kostenloser WordPress-Page-Builder, Theme und Updates inklusive.

Hallo Freunde
Um das zu beantworten, braucht es ein wenig Hintergrund. MaxiBlocks ist im Grunde ein Familienunternehmen. Christiaan (wie man anhand unserer Namen erraten kann) ist mein Mann. Zwar ist er mein Partner im Leben und im Geschäft, aber dieses Projekt ist eher mein als seines. Es ist nicht unser erstes gemeinsames Unternehmen – unser erstes war damals eher „sein Baby“. Wir hatten eine Produktionsfirma in Südafrika, die wir vor einigen Jahren erfolgreich verkauft haben. Ich war seine Partnerin damals, genauso wie er es heute in meinem Projekt ist.
Ich bin seit 1999 Designerin und habe all die Technologien kommen und gehen sehen. Um die Frage zu beantworten, ob ich morgens aufgewacht bin und dachte „Hey, vielleicht bauen wir einen besseren Page Builder als Kadence oder Elementor?“ – nein. Wir sind eher hineingerutscht.
Alles begann vor etwa zehn Jahren, als Side-Hustles und „Geld verdienen im Schlaf“ der grosse Trend waren. 😂 Die Realität sieht natürlich anders aus. Irgendwann kam ich jedoch auf die Idee eines UI-Kits. Wir bauten Kundenwebsites, und damals konnte ich entweder ein schönes PSD kaufen und etwas entwerfen – und danach begann der Albtraum (oder Svits’ Albtraum), das Design umzusetzen – oder ich konnte ein fertiges Theme kaufen, aber ohne Design-Datei, sodass Mock-ups und fertige Website nie richtig zusammenpassten. Ideal war das nicht.
Dann kam Divi. Und man kann sagen, was man will – Divi war bahnbrechend. Es war das erste Tool, mit dem man Designs exportieren und importieren konnte. Bam. Die Idee war geboren, und wir starteten unseren Side-Hustle, über den man hier nachlesen kann.
Springen wir weiter zu MaxiBlocks. Wir haben sieben Jahre lang Produkte für Divi gebaut. Zu Beginn waren wir kurz davor, auch für Elementor Produkte zu machen – ein paar Freebies gab es sogar – aber unser kleines Team konnte das zusätzliche Pensum nicht stemmen, also blieben wir bei Divi.
In den frühen Divi-Jahren merkten wir, dass ich meine Designs dort nicht einfach umsetzen konnte. Das ganze „No-Code“-Gerede funktioniert eben nur, wenn man den Builder im Standard-Look liebt. Damals schickten wir eine Umfrage herum – was mögt ihr an unseren Produkten, was nicht? Die Antworten waren erstaunlich einheitlich:
„Wir lieben eure Designs, aber wir hassen das CSS und die ganzen Klassen.“
Als Gutenberg kam, beschlossen wir, unsere eigene Lösung zu versuchen. Wir nahmen meine Designs auseinander, planten Blockstrukturen und zuerst entwarf ich hunderte Mock-ups von tausenden Blöcken. Dann wurde mir klar: Das führt uns in dieselbe Sackgasse wie bei Divi. Zu viele Block-Typen, zu viele Einstellungen, keine echte Freiheit.
Und dann – nach etwa drei Monaten – sass ich in Photoshop (ja, ich bin oldschool, nicht Figma 😉) und es traf mich. Ich habe dort keinen Team-Block und keinen Pricing-Table-Block. Ich habe Text. Bilder. Rechtecke. Buttons. Und totale Freiheit. Bam. Klarheit.
Wir brauchen keine 100+ Blöcke.
Wir brauchen ein starkes Grid und leistungsfähige Basis-Blöcke.
Zurück zur Ausgangsfrage, ob wir einen Page Builder bauen wollten, um zu konkurrieren. Nein. Im Gegenteil – vor ein bis zwei Jahren habe ich Facebook ganz bewusst gemieden, weil es mich zu sehr abgelenkt hat. Ein Builder bringt ein neues Feature raus – und ich geriet in Panik, dass wir das auch brauchen. Aber das ist nicht unser Ziel.
Was wir wollen, ist Designs und Websites bauen. Muster. Layouts. Lösungen.
Aber um das tun zu können, mussten wir eben zuerst einen Builder bauen. 😑

Hier ein Beispiel für meine ursprüngliche, überkomplizierte Blog-Idee. Wir haben das verworfen und uns stattdessen dafür entschieden, Bild- und Textblöcke mit dynamischen Inhalten zu unterstützen. Das bedeutet, jedes beliebige Pattern kann in ein Blog- oder Woo-Pattern umgewandelt werden, indem man einfach die dynamischen Einstellungen anpasst. Wenn man Divi als Beispiel nimmt: Ein Blog-Pattern in ein Team-Pattern umzuwandeln wäre dort viel aufwendiger, weil das Blog-Modul eigene Blog-Einstellungen hat und das Personen-Modul wieder andere Optionen wie Social-Buttons. Diese Einschränkung haben wir überhaupt nicht.
Um ehrlich zu sein, MaxiBlocks entstand an einer Stelle, die wohl niemand vermuten würde. Wir haben die Style Cards zuerst gebaut. Noch bevor es einen Namen oder ein Konzept dafür gab. Christiaan hatte dann die Idee und den Namen – inklusive der Möglichkeit, sie durchzustöbern.
Wieder einmal hat sich der Support bemerkbar gemacht. Unzählige „Wie ändere ich die Farbe?“-E-Mails 😂 und bis heute gab es, soweit ich weiss, nur eine einzige „Wie ändere ich die Farbe?“-Mail bei Maxi – und das war ein Sonderfall beim Akkordeon. 💪
MaxiBlocks wurde zu 100 Prozent aus Support-Erfahrungen entwickelt – aus all den Fragen, die uns immer und immer wieder gestellt wurden.
Cwickly ist für mich eine traurige Geschichte. Mein Traum wäre ein Cwickly-Maxi-Baby, denn deren Funktionsumfang war beeindruckend. Aber aus seinen Videos zum Klassensystem und aus unserem eigenen Support weiss ich, warum so viele damit Probleme hatten. Es gibt sicher gute Gründe für ein Klassensystem, aber die meisten Menschen interessieren sich nicht dafür. Sie wollen ein Design laden, bearbeiten und veröffentlichen – schnell und unkompliziert.
Trotzdem bin ich besonders stolz auf unsere CSS-Komponente. Für die Momente, in denen man CSS doch einmal braucht.
Wichtig zu erwähnen ist auch, dass wir drei Teams haben, die sich um das kümmern, was für uns wirklich zählt. Und ich meine nicht Buchhaltung, Admin oder Marketing, sondern das eigentliche Produkt.
Unser erstes Team ist die Entwicklung: drei brillante Köpfe im Backend, geführt von Svits, die seit zehn Jahren bei uns ist. Sie ist mein Fels. (Fun Fact: Maxi wird von zwei Frauen geführt!)
Dann haben wir zwei Frontend-Devs für die Patterns, geleitet von Sasha, seit fünf Jahren dabei.
Und Support wird von Marko geführt – manche von euch kennen ihn sicher schon.
Wir haben das Beste aus drei Bereichen genommen und beschlossen, etwas Gemeinsames zu schaffen. Sasha macht ausserdem QA – und er nimmt das sehr ernst, denn jede Schwachstelle trifft ihn beim Pattern-Bau doppelt. Aber auch er kann nicht jeden Bug erwischen 🫠
Während wir die Bibliothek erstellen, haben wir eine einzigartige Chance: Wir testen unser Produkt ständig selbst und sehen dabei sofort, was fehlt und was wir brauchen. Ein grosser Teil unserer Entwicklung entsteht durch den Bau der Library selbst. Wenn es etwas gibt, das uns unterscheidet, dann wahrscheinlich genau das.
Unsere nächste Herausforderung ist Wachstum. Wir haben festgestellt, dass der Plugin-Repo am Anfang kaum Sichtbarkeit bringt. Influencer zu erreichen, ist ebenfalls schwierig, die WordPress-Community ist sehr geschlossen. Und immer wieder kommt die Frage: Elementor? Kadence? – Elementor hat 15 Mio. Finanzierungsbudget, Kadence gehört einem Hosting-Unternehmen. Wir sind stolz darauf, bootstrapped zu sein, aber das bringt seine eigenen Hürden mit sich. Wenn du bis hierhin gelesen hast, kannst du uns unterstützen, indem du uns im Repo bewertest und über uns in Gruppen sprichst. Das würde uns sehr freuen.
Unser kostenloses Theme soll uns im Repo zusätzlichen Schwung geben. Es wird eines der wenigen wirklich freien Open-Source-Themes sein, das nicht aus dem Core stammt. Vielleicht fragst du dich, warum wir keine Funktionen hinter Bezahlschranken verstecken. Die Antwort kommt ebenfalls aus dem Support: Die zweithäufigste Frage nach „Wie ändere ich die Farbe?“ war immer „Was passiert, wenn ich kündige?“ Wir glauben an Open Source und daran, dass man trotzdem mit dem verdienen kann, was man liebt – und das ist Design.
Danke, dass du meine kleine Geschichte gelesen hast. Ich freue mich auf alles, was als Nächstes kommt.