The Digital Royalty client dashboard

Most agencies operate from email and meetings. A client wants to know what’s happening on their project, they ask. Someone fishes for the answer in Slack, in tickets, in someone’s head. The answer takes a day. The next time they want to know, the cycle repeats.

That works at a few clients. It collapses past that.

The original problem

Digital Royalty was running into the same wall every services business hits. As soon as we were running more than two or three engagements simultaneously, “what’s happening on the X project?” was a question I was answering several times a day. Each answer required me to actively re-construct the state from notes, repos, time tracking, and memory.

Two things were going wrong:

1. Clients were paying for visibility that didn’t exist. Engagement quotes promised reporting and progress tracking. The reporting and progress tracking were me typing in Slack.
2. Nothing about the system was repeatable. A new project manager couldn’t pick up an account because the project’s state wasn’t anywhere extractable; it was in my head.

The first half of the answer was process — written scope, ticketing standards, time tracking discipline. The second half was a piece of software clients could log into and see for themselves.

What was built

The Digital Royalty client dashboard. A multi-tenant Laravel + React application, sitting on the same platform as the Beacon products and using the same auth, billing, and permissions infrastructure.

What it shows clients, per project:

• Scope of work. The signed scope is loaded into the project so clients can see exactly what was agreed, with each feature flagged as not started, in progress, or done.
• Recent shipped work. Every release is logged with a one-line summary, a timestamp, and a link to the relevant artefact (deployed feature, repo branch, document). Clients see what landed in the last week without anyone telling them.
• Time and spend. Hours tracked against the engagement, broken down by area of work. If we’re 60% through the budget on a feature scoped at 20 hours, the client sees that too.
• Outstanding questions. Anywhere we’re blocked on client input — credentials, copy, decisions — surfaces here as a queue, so nothing waits in someone’s inbox indefinitely.

What it shows internally:

• All projects on one screen. Status, last delivery, time burned, questions outstanding.
• Time entries that flow into invoicing. No double-entry, no end-of-month panic.
• Beacon alerts inline. If a monitored job tied to a client’s project goes silent, the flag shows up in the project’s health view.

Key design decisions

A few things that mattered more than the rest:

• Multi-tenant from day one. Each client sees only their projects, but the same codebase serves all of them. New clients don’t get a new deployment; they get a new tenant.
• Same platform as Beacon. The dashboard isn’t a separate product. Auth, billing, real-time updates, integrations — all from the platform layer. New features built for the dashboard often become available to Beacon products and vice versa.
• Reporting as an artefact, not just a screen. Time and progress get exported to a clean PDF on a schedule, so clients who don’t want to log in still get the answer in their inbox.
• Scope-as-data. The signed engagement scope isn’t stored in a Word doc somewhere; it’s loaded into the dashboard as a list of items with state. That’s how the “what’s done vs not done” view stays accurate without anyone updating it manually.

What this case shows

Two things worth pulling out:

1. The platform pays for itself. Building the dashboard from scratch would have cost roughly four times what it actually cost — auth, billing, permissions, real-time, hosting, monitoring, all of which already existed. The marginal cost was the dashboard’s specific feature surface, not the operating envelope around it.
2. Visibility is a product, not a courtesy. Treating “client can see what’s happening” as a real piece of software, not a Slack habit, is the difference between an agency that scales past three or four clients and one that gets stuck.

If “what’s happening on the X project?” is a question you’re currently answering manually, the fix is structural. The cheapest version is a written reporting cadence on a calendar. The full version is a dashboard. Either way, it’s a piece of operating infrastructure, not an extra deliverable.