Zurück
Diesen Beitrag hören auf:

Vorstellung des Studios

Diesen Beitrag hören auf:

Wer wir sind, wie wir arbeiten – und warum wir Dinge lieber selbst bauen

Es gibt einen Moment in fast jedem Projekt, in dem sich die Frage stellt: Nehmen wir das fertige Template, das schon zu 80 % passt – oder bauen wir das, was wirklich gebraucht wird? Bei paul&paul fällt diese Entscheidung fast immer gleich aus. Wir bauen selbst.

Wer wir sind

paul&paul ist ein Studio für Entwicklung und Design. Wir sitzen nicht in getrennten Silos, in denen die einen Screens malen und die anderen sie irgendwann "umsetzen" – bei uns entstehen Gestaltung und Code im selben Prozess, oft von denselben Köpfen, immer im selben Gespräch. Das ist kein Lifestyle-Statement, sondern eine Arbeitsweise, die sich aus einer einfachen Beobachtung ergibt: Die besten Ergebnisse entstehen dort, wo niemand eine Idee "übergeben" muss, ohne dass etwas davon auf dem Weg verloren geht.

Wie wir arbeiten

Unser Ausgangspunkt ist immer das konkrete Problem, nicht das verfügbare Werkzeug. Statt zu fragen "Welches Plugin, welches Theme, welcher Baukasten löst das ungefähr?", fragen wir "Was genau braucht dieses Projekt – und wie bauen wir das direkt?" Das bedeutet mehr Aufwand am Anfang. Es bedeutet aber auch: keine Kompromisse, die man drei Monate später wieder ausbügeln muss, weil das Template eben doch nicht konnte, was versprochen wurde.

Dabei denken wir Marke, Interface und Code als eine Einheit. Eine Website, ein Produkt, ein Auftritt – das soll sich anfühlen wie aus einem Guss, nicht wie eine Sammlung von Bausteinen, die zufällig nebeneinanderstehen. Genau deshalb widerstehen wir auch der Versuchung, für einzelne Produkte oder Bereiche eigene, lose visuelle Identitäten zu entwickeln. Große, kohärente Systeme – man denke an Design-Systeme wie das von Figma – funktionieren gerade deshalb so gut, weil eine Idee konsequent durchdekliniert wird, statt an jeder Ecke neu erfunden zu werden.

Warum wir lieber bauen statt verwalten

Templates versprechen Geschwindigkeit. Und für den ersten Prototyp, den schnellen Test, den Proof of Concept sind sie oft genau richtig. Das Problem beginnt, wenn aus dem Prototyp ein Produkt wird – und man plötzlich damit beschäftigt ist, die Grenzen eines fremden Systems zu verwalten, statt an der eigenen Idee zu arbeiten. Jedes Update des Templates wird zum Risiko. Jede individuelle Anforderung wird zum Workaround. Man verbringt am Ende mehr Zeit damit, gegen das Werkzeug zu arbeiten, als mit ihm.

Wenn wir selbst bauen, gehört uns das Ergebnis vollständig – technisch wie gestalterisch. Wir kennen jede Entscheidung, weil wir sie getroffen haben. Wir können erweitern, ohne zu raten, was ein Template-Autor sich vor drei Jahren mal gedacht hat. Und wir können etwas gestalten, das wirklich nach nichts anderem aussieht, weil es nicht aus denselben Baukästen kommt wie tausend andere Websites auch.

Das heißt nicht, dass wir das Rad ständig neu erfinden. Gute Tools, Frameworks und Bibliotheken nutzen wir gerne – überall dort, wo sie eine solide Grundlage bieten, ohne uns in ihre Logik zu zwingen. Der Unterschied liegt darin, wer am Ende die Kontrolle über die Entscheidungen hat: das Werkzeug oder wir.

Was das für unsere Projekte bedeutet

Für Kund:innen heißt das: mehr Individualität, mehr Langlebigkeit, weniger böse Überraschungen bei der nächsten Erweiterung. Für uns heißt es: mehr Verantwortung – aber auch mehr Stolz auf das, was am Ende dasteht. Wir bauen lieber ein Haus, das wirklich passt, als eines aus dem Katalog zu verwalten.

Genau das ist paul&paul.