Like most agencies, Resonanz Digital has accumulated an extensive set of tools over time. Most of them stay invisible until something breaks or someone new asks, “Hang on a sec, why’d you use that?” You can learn a lot about a team from the developer tools they use, as well as the ones they stopped using.
We mostly work from home offices, spread across our own machines and our own habits, which means our toolset isn’t perfectly uniform. Here’s a tour of what we reach for every day, as well as one or two things we tried, liked the idea of, and then let go.
The dev tools we rely on
When it comes to code, PhpStorm remains our workhorse: reliable, extensible, and especially strong for the PHP-heavy work we do. It has a large number of plugins that cover almost everything, including useful ones for Svelte and some specific content management systems and frameworks. The downside is that it sometimes becomes a bit bloated: an update often fixes this; in some instances, we need to re-evaluate the installed plugins and remove the ones we no longer need.
Lately, some of us have been spending real time in Zed, especially its agentic view: having the AI agent, the editor, and a sidebar of git history and project structure all in one coherent workspace turns out to be a genuinely interesting way to work. While AI will never replace a human, it is a great tool for speeding up at least some of the programming chores, and Zed makes it very convenient to work with AI on large projects in particular.
WordPress is core to our business, but when a website outgrows its plugins and themes and for the development of web applications, we reach for Laravel. If content management is important for the client, we use Statamic to manage the frontend. For the backend, we tend to rely on Laravel Nova. Nova allows us to build admin panels quickly, which frees the time for the parts of a project that are actually interesting.
We all work on our projects locally on our own computers (mostly MacBooks, but also a Windows laptop). This means we need a convenient way to simulate a server. Some of us run Laragon, others swear by Local WP. The goal isn’t to have matching setups; the important thing is not to lose an afternoon to your own machine. Work with whatever gets you results.
A lot of our work these days concerns the back-end: APIs, data imports, integrations, and the plumbing behind the visible parts. Bruno does the API work without nagging us about features we’ll never use: more about that further below. Docker comes into play whenever a project needs a predictable environment, which doesn’t happen very often, but it’s good to keep in the back pocket.
For the frontend stuff we do, we’ve slowly moved away from Webpack and now use Vite as a build tool almost exclusively – bar some legacy projects – for compiling Svelte and JavaScript. As the name suggests, Vite is fast and also allows compiling on the fly whenever you make a change to your codebase. Of course, npm keeps the whole thing up-to-date.
Nothing we build lives outside version control: it’s Git for everything, with some of the larger sites managed through GitLab. The one faintly funny wrinkle is that publishing a plugin to the WordPress.org directory still means wrangling SVN in 2026, which feels like a brief trip back in time every time we do it; it feels quite archaic compared to Git.
The developer tools we put aside
The tools you stop using often say as much as the ones you keep. And again, these are our own personal choices: if something works for you, stick with it.
For API work, Postman was the default for a long time. Two things ended the relationship: the pricing crept past what made sense for how we actually used it, and a move from Linux to Windows mangled the collections badly enough to force us to look elsewhere. We switched to Bruno and it’s been great: it doesn’t nag us about paid features or account tiers, it’s much lighter and quicker to run, and – perhaps most importantly – it stores its collections as plain files we can keep in Git.
We used to keep our useful bits of code in dedicated snippet software. This meant that the shared library had to be kept up-to-date across multiple workstations. We made a conscious effort to avoid this by building a custom ProcessWire website to keep snippets and references in one place for the whole team, alongside our Atlassian Confluence wiki for the longer-form institutional memory.
The rest of the toolbag
Plenty of dev tools just do their job and are not particularly exciting, but we’ll briefly mention them here for the sake of completeness. OpenVPN Connect gets us onto the office IP, since a fair amount of what we access is deliberately gated behind it.
Asana is used to manage projects and tasks, and MOCO records where the time actually went. Because we’re mostly remote, Slack is where the team really lives day to day, with Zoom for meetings. Microsoft Teams is used whenever a client prefers it, because that particular hill isn’t worth dying on.
BrowserStack lets us test against the real spread of browsers and devices people actually use, rather than the three sitting on our own desks. For the jobs where nothing off-the-shelf did quite what we needed, we built our own testing tool in Node.js. We call it Argus, after the hundred-eyed figure from Greek mythology. It tests websites end to end, covering both frontend and backend.
For the unglamorous everyday work, we rely on LibreOffice and Google Drive for documents and presentations. For the relatively rare times that we have to work with images, we rely on Affinity, which is especially great when it comes to vector images, and Krita.
Closing remarks
We’re pretty loyal to tools that get out of the way, and quick to drop the ones that demand more attention than they give back. None of it is settled, either: half of this list looked different two years ago, some of it isn’t even the same across our own desks, and most of it will no doubt change again.
Our tools are what allow a small, mostly-remote team to take on work that often requires a larger number of people. And if you’re the sort of person who has strong, well-argued feelings about your editor – or who’d sooner build their own tool than tolerate a bad one – we’d very likely get along.
