How We Turned Digital Gorilla’s Client Chaos Into One Operating Console

Published 7 July 2026 · Updated 17 July 2026 · Client engagement · Published with Digital Gorilla’s permission

The problem: the founder was the bottleneck

Before the console, the agency ran on a patchwork: a spreadsheet that tried to track who owed what, client notes scattered across email and a couple of chat apps, and no single place that showed what stage anything was at. Every review and every change request ran through the founder in person, one message at a time, so on a busy week the whole team effectively waited on one inbox.

Digital Gorilla is a creative and marketing agency, and like most agencies it lives or dies by client feedback loops. Designs go out, clients respond, revisions come back, work gets reassigned, over and over, all day. Before we worked with them, every one of those loops passed through a single person: the founder.

The pattern was always the same. A client sent feedback by email or message; the founder read it, worked out which editor it belonged to, forwarded it, then chased to confirm it got done. Nothing was timestamped, nothing was logged, and when a client asked “did you get my change?” the only way to answer was to go digging through threads. The founder wasn’t running the agency so much as being its communication layer, manually, from morning to night. That’s the cost most agencies never put a number on: the owner’s day quietly spent as a human router.

What we built: an operating console, not a CRM

The easy thing to say is “they needed a CRM.” They didn’t. A CRM stores contacts and deals; what Digital Gorilla needed was something that actually runs the work. So we built an operating console shaped around how the agency really operates, not around how CRM software wishes it did.

Four pieces carried most of the weight. Each client got their own portal, a space where they see their deliverables and approve or reject work themselves, instead of feedback vanishing into an email thread. When a client rejects something or asks for a change, it no longer lands in the founder’s inbox; it routes straight back to the right editor, timestamped, with a clear record of what was asked and when. New projects create their own file structure automatically, no manual setup, no inconsistent naming, nothing forgotten at 11pm. And underneath it all, leads, clients, campaigns, tickets, and team workload live in one console rather than scattered across a dozen tabs and inboxes.

The whole thing runs on EU-based infrastructure, built to be GDPR-appropriate from the start, because the moment you centralise client communications and files, you’re processing personal data at scale, and that’s not something to bolt on afterwards.

The result: the founder stepped out of the middle

The change was structural rather than cosmetic. The founder is simply no longer the middleman for every message. Approvals and rejections happen directly between client and system, revisions reach the right person on their own with a timestamped trail, and folders exist before anyone remembers to make them.

Two things came from that. The obvious one was time, a great deal of daily back-and-forth just evaporated. The one the founder told us mattered more was harder to see coming: with the day-to-day chaos finally handled, they could step back and see where to actually push the business, instead of spending every hour firefighting messages.

In their words

“Dabster built us an operating console, not just a CRM. Our clients get their own portals where they approve or reject work themselves, and every rejection routes straight back to the right editor, timestamped, with folders created automatically. I’m no longer the middleman for every message. It saved us countless hours, and for the first time I can see clearly where to focus to grow.”

, Digital Gorilla, Creative & Marketing Agency

And it keeps improving. The console is a living system, not a one-time build. The most recent addition is an automatic email to editors the moment a change request comes in, so the right person hears about a revision without anyone chasing it. We would rather show you where it is still growing than pretend it arrived finished.

Could your business work like this?

If you’re the person every message passes through, that isn’t a workflow, it’s a bottleneck with your name on it. The kind of console we built here isn’t only for agencies; any business where work bounces between clients, reviewers, and a team can run this way.

Book a free discovery call and we’ll tell you honestly whether an operating console fits how you work, or whether something simpler gets you most of the way there.

How it works

The console runs as a single monorepo split into three parts that ship together: a Next.js front end (the console and the per-client review portals), a NestJS API over PostgreSQL, and a background worker built from the same API image. Every state-changing action on the API emits a domain event onto one internal event bus, and two consumers read from it. The first is an audit handler that writes an append-only record to PostgreSQL. The second is an automation handler that matches enabled rules and enqueues background jobs on a Redis-backed queue. Client portals, per-editor feedback with timestamps, and team chat all update live over Server-Sent Events, so an editor sees a client’s note the moment it lands, no page refresh, routed to the person who owns that deliverable. Files follow the same discipline: each deliverable gets its own folder, created once and idempotently across two folder trees, one client-facing and one internal for editors, so the project file structure builds itself as work moves through the pipeline.

• Console and portals: a Next.js (App Router) front end serving both the internal console and each client’s review portal.
• API: a NestJS service with Prisma over PostgreSQL 17, sharing one typed request-and-response contract with the front end.
• Worker: background jobs run on a Redis-backed queue from the same image as the API, so build and behaviour stay in lock-step.
• Event bus and audit: every change emits a domain event; an append-only audit record is written and locked in place by a database trigger.
• Automation engine: in-app rules match those events and enqueue the resulting actions.
• Connector framework: each integration is a stored connection plus an encrypted secret that is decrypted only at the point of use.
• Real-time layer: notifications, client feedback, and team chat delivered over Server-Sent Events.

Built with

• TypeScript end to end, in a pnpm-workspaces and Turborepo monorepo.
• Next.js (App Router) front end with Tailwind CSS and a shared design system.
• NestJS API with Prisma, and one shared schema-validated contract between front end and back end.
• PostgreSQL 17 with Row-Level Security and immutable, append-only audit records.
• Redis-backed job queue for automations and scheduled agent runs.
• Self-hosted, S3-compatible object storage for uploads and deliverables.
• Caddy for automatic HTTPS, in front of a single internal Docker Compose network where only the web edge is published on 80/443.
• A real-time layer over Server-Sent Events for notifications, feedback, and team chat.
• A frontier large language model for the human-in-the-loop assistant and the editor-notes agent, called only through a PII sanitizer so raw personal data does not leave the box.
• EU-hosted infrastructure throughout.

Security and compliance

• Row-Level Security in the database: the app connects as a non-superuser role that cannot bypass row-level rules, so tenant and portal isolation is enforced by PostgreSQL itself, not just application code.
• Immutable audit trail: the audit log is append-only, with database triggers that block updates and deletes outright.
• Sealed connector secrets: every integration credential is encrypted with AES-256-GCM, decrypted only at the point of use, and never returned by the API. Passwords are hashed with bcrypt.
• Session hardening: token verification is pinned to a single algorithm, refresh tokens can be revoked, and each account has a fail-closed login lockout backed by Redis.
• Outbound request guard: a server-side fetch guard blocks private-range and cloud-metadata addresses, requires HTTPS, and re-validates on redirect and DNS rebind, covering connectors, email account tests, and model calls.
• Injection defense: parameterized queries, schema validation on every input, and a sort-field allow-list, checked against live time-based database payloads.
• AI guardrails: a PII sanitizer wraps all model flows including tool-call payloads; agents run under a service-account permission ceiling with an allow-list, and sensitive actions require human approval (aligned with GDPR Article 22).
• Upload safety: executable file types are blocked and confirmed by server-side magic-byte inspection rather than trusting the declared type.
• Container hardening: app containers drop all Linux capabilities, run non-root, and forbid privilege escalation; the database, cache, and object store are never published to the host.
• Automatic HTTP threat banning: the web-edge access log feeds a threat collection covering 19 HTTP attack scenarios, which drops offending IP addresses at the firewall.
• CI security gates: every change runs a dependency audit, static analysis, and secret scanning before it can ship.
• GDPR data-lifecycle module: right-to-erasure (Article 17), data export (Articles 15 and 20), and a daily retention purge (Article 5(1)(e)) are built in.
• Off-site encrypted backups: a daily database dump is encrypted, taken off-box, and pruned to the last 14, with each run recording a durable-outcome status.
• Adversarially tested: an automated fuzzing sweep exercised 255 API operations with 0 exploitable findings, and an internal AI red-team surfaced 2 critical and 5 lower issues that were all fixed and re-attacked.
• Live and clean: in production since 2026-06-19 after a full security campaign closed to 0 critical and 0 high findings, with a later re-verification finding a single medium issue that was fixed and deployed.

Related service: CRM Integration