Tools of the trade

Unsere Entwickler-Tools: Womit wir bei Resonanz Digital täglich arbeiten

28.07.2026 in Entwicklung

Wie in den meisten Agenturen haben sich auch bei uns über die Jahre eine ganze Menge Entwickler-Tools angesammelt. Das meiste davon bleibt unsichtbar, bis etwas kaputtgeht oder jemand fragt: „Moment mal, warum benutzt ihr das?“ Dabei verrät ein Toolset eine Menge über ein Agentur-Team, und zwar nicht nur durch das, was verwendet wird, sondern auch durch das, was rausgeflogen ist.

Wir arbeiten fast alle aus dem Homeoffice, jeder an seinem eigenen Rechner und mit seinen eigenen Gewohnheiten. Entsprechend ist unser Setup nicht völlig einheitlich. Hier ein Überblick der Tools, zu denen wir täglich greifen – und ein paar Werkzeuge die wir ausprobiert und wieder fallen gelassen haben.

Die Dev-Tools, auf die wir uns verlassen

Beim Code bleibt PhpStorm unser Arbeitspferd: zuverlässig, erweiterbar und besonders stark für unsere PHP-lastige Arbeit. Für praktisch alles gibt es ein Plugin, auch für Svelte und für einige speziellere Content-Management-Systeme und Frameworks. Gelegentlich wird die IDE dadurch etwas träge. Meist hilft dann ein Update oder ein Ausmisten der Plugins (bei den Experimentierfreudigen sammeln sich schon mal die Altlasten ;-)).

Ein Teil des Teams verbringt inzwischen relativ viel Zeit im Editor Zed. KI-Agent, Editor und eine Seitenleiste mit Git-Historie und Projektstruktur sitzen dort in einem einzigen Workspace, und das erweist sich als überraschend angenehme Art zu arbeiten. Gerade bei großen Projekten nimmt uns das einen guten Teil der stumpfen Routine ab.

WordPress ist das Herzstück unseres Geschäfts. Wenn eine Website ihren Plugins und Themes entwächst und für die Entwicklung von Web-Applikationen, greifen wir zu Laravel. Ist dem Kunden das Content-Management besonders wichtig, verwalten wir das Frontend mit Statamic, im Backend setzen wir aber meist auf Laravel Nova. Damit sind starke Admin-Panels schnell aufgesetzt, und es bleibt Zeit für die Teile eines Projekts, die tatsächlich interessant sind.

Entwickelt wird bei uns lokal, überwiegend auf MacBooks, Windows kommt aber auch manchmal vor. Also braucht jeder eine bequeme Möglichkeit, einen Server zu simulieren. Ein Teil des Teams nutzt Laragon, ein anderer schwört auf Local WP. Identische Setups sind ausdrücklich nicht das Ziel; entscheidend ist nur, dass niemand einen Nachmittag an die Konfiguration der eigenen Maschine verliert.

Ein großer Teil unserer Arbeit spielt sich im Backend von Applikationen ab: APIs, Datenimporte, Integrationen und all die unsichtbaren Datenflüsse hinter den sichtbaren Teilen im Frontend. Die API-Arbeit dafür erledigen wir mit Bruno, dazu gleich mehr. Docker kommt ins Spiel, sobald ein Projekt eine vorhersehbare Umgebung braucht.

Von Postman zu Bruno

Lange Zeit war Postman bei der API-Arbeit gesetzt. Zwei Dinge haben die Beziehung beendet: Die Preisgestaltung ist über das hinausgewachsen, was für unsere tatsächliche Nutzung noch sinnvoll war, und ein der Betriebssystem-Wechsel eines Kollegen von Linux zu Windows hat die Collections so gründlich zerschossen, dass wir uns ohnehin nach Alternativen umsehen mussten.

Bruno hat sich seither als Glücksfall erwiesen. Es hält uns nicht dauernd kostenpflichtige Funktionen und Account-Stufen unter die Nase, ist deutlich leichter und schneller, und vor allem legt es seine Collections als schlichte Dateien ab. Die liegen bei uns im Git-Repository, perfekt versioniert wie alles andere auch.

Frontend und Versionskontrolle

Im Frontend haben wir uns Schritt für Schritt von Webpack verabschiedet. Bis auf ein paar Altprojekte kompilieren wir Svelte und JavaScript inzwischen ausschließlich mit Vite, das seinem Namen alle Ehre macht und für schnelle Builds sorgt. npm hält den Rest aktuell.

Nichts, was wir bauen, existiert außerhalb der Versionskontrolle. Git ist überall im Einsatz, die größeren Websites verwalten wir über GitLab. Eine kuriose Ausnahme bleibt: Wer 2026 ein Plugin im WordPress.org-Verzeichnis veröffentlichen will, muss sich noch immer mit SVN herumschlagen. Neben Git wirkt das jedes Mal wie eine kurze Reise in die Vergangenheit.

Argus: unser eigenes Testwerkzeug

Mit BrowserStack testen wir gegen die tatsächliche Bandbreite an Browsern und Geräten, die echte Menschen wirklich nutzen, statt nur gegen die drei, die auf unseren eigenen Schreibtischen stehen.

Für alles Weitere hat keine Standard-Testlösung genau das gemacht, was wir brauchten. Also haben wir unser eigenes Testwerkzeug in Node.js gebaut. Wir nennen es Argus, nach der hundertäugigen Gestalt aus der griechischen Mythologie. Es prüft Websites von Anfang bis Ende und deckt dabei Frontend und Backend gleichermaßen ab. Wie Argus im Detail funktioniert und warum wir uns den Aufwand angetan haben, ist sicher einen eigenen Artikel wert.

Entwickler-Tools, die wir wieder losgelassen haben

Nicht alles, was wir einmal eingeführt haben, ist geblieben. Postman ist der prominenteste Abgang, unsere Snippet-Software der zweite.

Früher haben wir nützliche Codeschnipsel oft in lokalen Snippet-Anwendungen gesammelt. Der Preis dafür war, dass die gemeinsame Bibliothek über mehrere Arbeitsplätze hinweg aktuell gehalten werden musste. Diesen Aufwand wollten wir uns sparen und haben stattdessen eine eigene ProcessWire-Website gebaut, auf der Snippets und Referenzen für das ganze Team an einer Stelle liegen. Für die agenturweite Wissenssammlung kommt zusätzlich unser Confluence-Wiki zum Einsatz.

Der Rest des Werkzeugkastens

Einige Tools erledigen einfach ihre Aufgabe, ohne dass es darüber viel zu sagen gäbe. Der Vollständigkeit halber: OpenVPN Connect bringt uns auf die Büro-IP. Viele sicherheitskritische Funktionen und Zugänge sind bei uns ganz bewusst auf wenige IP-Adressen beschränkt.

Projekte und Aufgaben verwalten wir in Asana, MOCO hält fest, wohin unsere Arbeitszeit tatsächlich geflossen ist. Da wir überwiegend remote arbeiten, ist Slack der digitale Ort, an dem das Team sich im Arbeitsalltag abstimmt und lustige Memes postet (wichtig für die Motivation!). Für Meetings kommt bei uns Zoom zum Einsatz. Microsoft Teams läuft immer dann, wenn ein Kunde es so bevorzugt; dafür auf die Barrikaden zu gehen, lohnt sich nicht … ;-)

Bei Dokumenten und Präsentationen verlassen wir uns gern auf LibreOffice und Google Drive. Für die selteneren Fälle, in denen wir mit Bildern arbeiten, greifen wir zu Affinity, das vor allem bei Vektorgrafiken stark ist, und zu Krita.

Ein Toolset ist eine Momentaufnahme

Wir bleiben Tools treu, die sich im Hintergrund halten, und trennen uns schnell von jenen, die mehr Aufmerksamkeit verlangen, als sie an Wert zurückgeben. In Stein gemeißelt ist davon nichts: Die Hälfte dieser Liste sah vor zwei Jahren anders aus, manches ist nicht einmal auf unseren eigenen Schreibtischen gleich, und das meiste wird sich wieder ändern.

Am Ende ist es genau dieses Set an Entwickler-Tools, das einem kleinen, überwiegend remote arbeitenden Team erlaubt, Projekte zu stemmen, für die anderswo deutlich mehr Leute nötig wären. Wenn du starke, gut begründete Überzeugungen zu deinem Editor hast oder dir lieber ein eigenes Werkzeug baust, als ein schlechtes zu ertragen: Wir suchen regelmäßig Verstärkung.