Digital Metrics

Where did Digital Metrics come from?

Not from me. My business partner came to me with an idea: digital marketing agencies are drowning in manual work, and there's a product in there somewhere. That was more or less the whole brief.

It wasn't a spec. It was a direction, plus an accurate instinct about a real market. Which is how most good ideas actually arrive — someone who understands the customer can see the problem clearly and has no idea what the software should be.

How do you turn an idea that broad into something you can build?

Mostly by asking questions until it gets smaller.

The first stretch was conversations, not code. What does an agency actually do on a Tuesday? Where does the time go? Which part of it would they pay to stop doing? Every answer narrowed it. A platform for agencies slowly turned into something I could draw on one page.

The listening isn't the hard part, though. The hard part is what comes after: deciding what not to build. The first version was far smaller than the one he described to me, and that is the only reason it ever got finished. Every feature we cut early was a month we didn't spend finding out it was wrong.

And some of what we did decide was wrong anyway. We put it in front of real agencies, watched what they ignored, and changed it.

What shipped first, and what came after?

The CRM and the Meta Ads dashboard. The unglamorous core — the thing an agency would have open every day.

Then automated client reporting, because the moment we watched someone use the dashboard it was obvious the real pain wasn't seeing the data. It was retyping it into a report once a month, per client.

Then the AI analysis inside those reports. Then the WhatsApp agent. Four products now, and each one got added because something we saw told us to — not because it was on a roadmap drawn up at the start.

That's also why the architecture matters here. It's a modular monolith behind a multi-tenant REST API: real boundaries between modules, one deployment. Not microservices — a solo engineer running a distributed system spends their life on infrastructure instead of on the product. But structured so each new product could be added without the previous one getting in the way.

What does the AI actually do?

Two things, and neither of them is a chatbot bolted onto a sidebar.

The first is the reporting. Campaign metrics and CRM pipeline data run through an LLM pipeline that writes the analysis and the recommended next actions straight into the client PDF. The chart says what happened; the text says what to do about it. That text is the product.

The second is the agent. It handles live WhatsApp conversations, scores intent and budget on every message, and hands off to a human at the moment it stops being useful. The lead gets a real answer at 11pm instead of a callback on Tuesday.

The hard part of both was never the model. It was deciding what the model is allowed to decide, and where a human has to take over.

What does running it teach you that building it doesn't?

That the interesting problems arrive after launch.

Building it is a known quantity — hard, but bounded. Operating it means being on the other end of Sentry at an awkward hour, discovering what real users do that you never designed for, and choosing between the fix that's fast and the fix that's right while somebody waits.

It also changed how I estimate. You price work very differently once you've been the person who has to live inside the shortcut.

Why does this one matter?

Because what I actually did here is the thing most people need and can't quite name.

They don't need someone who can write a CRM. They need someone who can sit with a half-formed idea, ask the right questions, disagree with them honestly, and come back with something real — and smaller than what they described. Then build it. Then keep going.

That's exactly what Week One is. This is the long version of it.