Skip to main content
Back to Insights

Why we build products inside a Drupal agency

Valentin Zsigmond
Valentin ZsigmondApr 14, 20265 min read

After enough years of maintaining Drupal sites, you start seeing the same problems everywhere. Not Drupal problems. Operational problems that Drupal sites happen to surface.

We are a Drupal agency first. That is what pays the bills and that is where our expertise sits. But we have also started building products, carefully and in the background. Not because building products is fashionable, but because we have spent enough time inside these problems to have a clear sense of what good solutions would look like.

The pattern that triggered it

Most new engagements begin the same way. We audit a client's site and find a fairly predictable set of gaps: monitoring that is missing or stitched together from a service that costs more than it gives back, no structured way to track work and projects, consent for cookies handled by an expensive external script, bot traffic eating server resources with nothing in front of it.

For each gap there is usually an off-the-shelf option, but those options are typically built to work across many platforms rather than for Drupal in particular. In practice that often means an external script on the page, a separate dashboard to manage, and a recurring fee for behavior that could live natively in the CMS. So we keep building Drupal-native alternatives that integrate properly. Good work, solving real problems. The trouble is that we solve them one client at a time.

At some point that starts to feel wasteful. We were solving the same problem differently for each client, when the honest thing to do was solve it once and make it available everywhere. The agency model rewards bespoke work: you bill hours, you build to order. A product mindset rewards something else: build once, improve continuously, and let every fix benefit everyone.

Why an agency is the right place to build

The conventional advice is that agencies should stay in their lane. Build sites, bill hours, do not get distracted by product work. There is truth in that. Product work can quietly pull attention away from the client work that funds it, and that tension deserves to be taken seriously.

But we think an agency has two advantages that a pure product company does not.

The first is that we live inside the problem every day. We do not need market research to understand what a Drupal site owner needs, because we are the ones maintaining their sites, answering their tickets, and fixing things when something breaks at an inconvenient hour. Product companies survey their users. In this narrow domain, we are our own users.

The second is a sustainable way to fund the work. Client services pay the bills while any product thinking is still maturing. There is no outside investment to satisfy, no pressure to rush to market, and no growth metric pulling decisions away from usefulness. That means we can take our time and build the right thing at the right pace, or decide not to build something at all.

The risk we manage

The biggest risk here is not building something mediocre. It is losing focus on the client work. Clients pay us to care about their sites, and the moment they sense our attention is elsewhere, the relationship suffers. That is the danger we take most seriously.

We manage it with a simple rule: product work does not happen at a client's expense. It happens in the margins, in the time that is genuinely ours, and in the efficiency we gain by not rebuilding the same thing for the tenth time. The sweet spot is when a piece of product thinking also solves a real client problem, because then both sides benefit at once.

We try to be honest about timing too. Nothing here has a launch date, because we are not going to ship something before it is ready. Clients trust us because we deliver quality, and anything we build for them has to clear the same bar.

Why we are writing this now

Because we believe in building in public. Not the performative kind, where you post daily metrics on social media, but the honest kind, where you explain what you are working on and why, so that the people who care about the work can understand the direction.

We will not announce specific products or timelines. Nothing is ready for public use, and premature announcements do not help anyone. But we can describe the categories we are exploring, and the thinking behind each.

  • Monitoring and protection. Every Drupal site we look after needs uptime monitoring, some defense against bot traffic, and security alerts. Today that usually means combining several separate services, each with its own dashboard, billing, and configuration. We are interested in what it looks like to bring that together in a way that understands Drupal natively, rather than a generic tool bent to fit a CMS.
  • A client portal and operations layer. We keep projects, time, documents, and support tickets in one place rather than spread across a loose collection of disconnected apps. We find it more useful to treat the client relationship as a first-class thing, with everything about a project in a single view.
  • Site-building tooling. The Drupal ecosystem is moving quickly in this direction, with initiatives that make the CMS more approachable for people who are not developers. We want to build on that momentum, not compete with it. Our angle is narrower: what a modern, component-driven frontend feels like in the hands of editors, and the room that exists between installing Drupal yourself and handing the whole thing to a proprietary builder.

Where this leaves clients

If you are a current or prospective client reading this, you might reasonably wonder whether the agency is quietly turning into a product company.

The short answer is no. The agency is the foundation. Anything we build sits on top of it, not in place of it. In practice clients benefit directly: the thinking we put into monitoring becomes the monitoring we use on your site, and the editorial improvements we work out for site-building improve the editing experience on your site too. The agency makes the products better because we understand real-world needs, and the products make the agency better because we stop rebuilding the same tools from scratch.

We are a small, deliberate team building things that are larger than ourselves. We do not have it all figured out. But we know these problems from the inside, we have the technical depth to solve them properly, and we have the patience to do it without cutting corners.

If that resonates, whether you need a Drupal agency today or you are simply curious where this is heading, we would be glad to hear from you.

Share this article
Valentin Zsigmond
Written by
Valentin Zsigmond
Founder & Lead Engineer

Full-stack Drupal architect with almost two decades of experience leading large teams in enterprise environments. Founded Tilizy Digital to bring senior-level expertise directly to the organizations that need it. Mentor to dozens of Drupal developers and creator of SDX — a Drupal extension for building modern frontends with React and Vue.

Enjoyed this article?

If this resonated, imagine what we could do working together on your Drupal site.