Krembo Rebels

Building the reporting layer I spent twenty months needing

Twenty months at Krembo running client accounts taught me exactly what reporting was missing. Then I architected, built and deployed the multi-tenant analytics platform that fixed it, solo.

The monthly leads and budget monitor: one row per client, with columns for monthly target, actual leads, shortfall, leads required per day, pace against target, budget and target cost per lead. Client names and figures are redacted; the pace column is a ratio, so it is not.
Role
Product Manager, then Product, AI and Automation Consultant
Platforms
Web
Team
Solo build, after twenty months directing cross-functional agency teams
Year
2026

Krembo Rebels is a digital agency. I joined as a Product Manager in May 2024 and spent twenty months running client delivery; since January 2026 I have been a part-time product, AI and automation consultant there. This case study is about the analytics platform I built in the second role. It only exists because of the first.

Challenge

By the end of that stretch I owned delivery, account roadmaps and stakeholder communication across 12 concurrent client accounts spanning fintech, e-commerce and real estate, up from 8 under the previous manager. I absorbed the extra four by rebuilding how the work was planned and tracked, and by introducing Monday.com company-wide: the boards, the automations, the reporting views and the permissions, then onboarding non-technical staff onto all of it.

Running twelve accounts surfaces the same problem every month. Client reporting was assembled by hand from six separate sources that did not talk to each other: Meta, Google Ads, Google Analytics, Taboola, LinkedIn and the CRM. Nobody could compare one client's performance against another without rebuilding the comparison from scratch, and every account manager who wanted a number had to go and get it themselves. The work I most wanted to do, the funnel work, was the work the reporting overhead kept eating.

That funnel work is worth naming, because it is what the platform was built to protect. Owning Krembo's digital magazine end to end as a product, I instrumented the full path from ad impression to submitted lead, ran stage-level A/B testing to isolate where drop-off occurred, then redesigned ad creative, hook placement, questionnaire design and CTA visibility against the results, with client lead-quality feedback closing the loop. Every funnel I redesigned lifted conversion by approximately 20%.

On a client's secondary-shares trading platform I grew daily signups from 3 to 15 within a month, by redesigning onboarding, shortening the path, replacing open questions with structured options, adding process transparency and repositioning the primary CTA. The campaign changed in the same month, so I cannot split the credit between the product work and the acquisition work. Both moved, the result is real, and I would stagger them if I ran it again.

None of that is possible at twelve accounts if the reporting is manual.

What I did

I solved it twice, and the order matters.

First, an LLM automation. Rather than jump to a platform, I built something that pulled the numbers from Meta and Google and sent a daily report, the smallest thing that removed the manual assembly. It is still running today, which is the point: it earned its place before anything bigger was justified.

Then the platform, once the automation showed its ceiling. A daily report tells you what happened; it cannot be filtered, searched, or compared across clients, and it only covers two of the six sources. That gap is what the platform exists to close.

I architected, built and deployed a multi-tenant client-facing analytics platform solo, from a validated MVP to live production, directing Claude Code across Supabase, GitHub and Vercel. I do not write the code. I made every product and architecture call, specified it, reviewed it and tested what came back.

I consolidated all 6 live data sources, Meta, Google Ads, Google Analytics, Taboola, LinkedIn and the CRM, into a single comparative layer, with filtering, search and cross-client comparison, so performance could be read side by side rather than reassembled each month. It replaces the daily report with the full picture rather than a slice of it.

The admin-only connections screen. Meta and Google Ads each have a block for attaching a client’s ad accounts, chosen from a list or entered by ID, with a note that each account’s token is stored server-side and never exposed in the browser.
Attaching a client’s ad accounts, admin only. Meta and Google Ads here, the remaining four sources below the fold of this screenshot. Consolidating them was the easy half. Keeping them comparable, same date windows and same attribution assumptions, was the part that took the thinking. Client names and figures are redacted throughout.

Behind it sits a two-tier permission model, agency admin against scoped client views. The design constraint that mattered most was who operates it: non-technical teams had to be able to onboard a new client without engineering support. A reporting tool that needs a developer to add a customer is a reporting tool that stops being used.

The agency admin dashboard: a client switcher and add-client controls in the header, campaign-group filters, and a row of aggregate performance tiles. Client names and figures are redacted.
The agency admin view. The switcher, the add-client control and the campaign-group filters are all here, and performance is aggregated across the accounts rather than scoped to one.
The scoped client view: one client named in the header, six performance tiles and the campaign table, with no client switcher and no add-client controls.
The same platform as a scoped client sees it. The switcher and the add-client controls are gone, and the tiles change to the six measures that client is judged on. The permission tier is not a settings screen. It changes what the page is, and getting that boundary wrong is the failure mode that would end the product.

The reporting automation is one of two internal LLM-powered tools I built and deployed, both now used daily by non-technical teams. The second cut article publishing lead time by 75%. For both I wrote and tuned the prompts myself, and benchmarked their output against work the team had already published rather than against my own judgment of what looked right. The team's existing work was the only standard that mattered, and it was already sitting there to test against. Every generation was reviewed by a person before it went out, and there was no scored eval set.

Outcome

The reporting outcome I can point at is not a number. Clients used to ask for reports. The report now arrives on its own every day, and the requests stopped.

The platform is running in production with its first client on it. There is no feedback from that client yet, so there is nothing here about adoption or satisfaction, and I would rather say that than invent it. Remaining features sit in a prioritised backlog, held deliberately until there is evidence from current usage to rank them against.

6 data sourcesOne comparative layer, two permission tiers, built solo

Learning and reflection

The best specification I have written came from being the user for twenty months. I knew what the reporting layer had to do because I had spent twenty months working around its absence. That is not a repeatable advantage, and it is worth being honest that most product decisions do not come with it.

Directing an AI coding agent is a product skill, not an engineering shortcut. The platform exists because the scope was decided, sequenced and held. The model wrote code quickly in whatever direction it was pointed, which makes the pointing the entire job.

Delivering is not the same as being finished. The backlog is deliberately unbuilt. Having the ability to add features quickly makes it easier, not harder, to add the wrong ones, so the rule I set was that nothing else gets built until usage says which thing is missing.