Skip to content
wojciech.io
All insights
AI Systems AI Ads GTM Operator tooling

I replaced the Google Ads UI with a dashboard that tells me what to do next

The native Google Ads interface is optimized for Google's revenue, not for operator decisions. So I built AdsAI: budget, ROAS, ICP fit, and next actions in one view.

Wojciech Łuszczyński

Wojciech Łuszczyński

GTM Architect & Growth Operator · Now · 22 March 2026

TL;DR · Key insights

  • The Google Ads UI is optimized for Google's revenue, not for operator decisions
  • AdsAI surfaces budget, ROAS, ICP fit, alerts, and next actions in one workspace
  • Built with React + a lightweight backend that polls the Ads API on your behalf
  • Operator sees what to pause, analyze, or scale. No hunting through reports

The Google Ads interface is not built for decision-making. It’s built for configuration. There’s a difference.

You go into Ads to see how things are performing. You end up clicking through five tabs, comparing numbers in two browser windows, and building a mental model that evaporates by your next session. The actual question: “what should I do right now?”: is never answered.

AdsAI is my attempt to answer it.

The operator gap

Google Ads UI

Five tabs, two browser windows, mental model that evaporates. Optimized for Google's revenue, not for operator decisions.

Configuration interface

AdsAI

Budget, ROAS, ICP fit, alerts, and next actions in one workspace. One click to act, one click to defer.

Decision interface

The problem with ad dashboards

Most ad dashboards (Supermetrics, Looker Studio) give you more data in nicer charts. That’s not the gap. The gap is between “here is your ROAS by campaign” and “here is what you should do about it.”

The decisions that matter in paid performance are repetitive and mostly logical:

  • Which campaigns are burning budget without ICP-fit traffic?
  • Which keywords have high CTR but low conversion: and why?
  • Where is there room to scale without diminishing return?
  • What’s broken that I haven’t noticed yet?

These questions have answers. The answers live in the data. Getting them requires either a skilled analyst running daily checks or a system that does it automatically.

What AdsAI looks like

The interface has three sections:

The ICP layer

The part that took longest to build was ICP matching. Not all traffic is worth buying even at a profitable ROAS: if you’re in B2B SaaS, QSR franchise, or any segment where the buyer profile matters, raw conversion volume is a misleading signal.

I added a simple ICP definition layer: industry, company size, role. The system cross-references campaign-level signals (search terms, landing page, converting job titles where available) against the ICP definition and flags misalignment. This catches campaigns that look profitable but are pulling in the wrong segment.

Architecture

  1. Ads API poller

    Lightweight Node service, scheduled pulls. Handles OAuth refresh for multiple accounts.

  2. Postgres history

    Small instance for trend data. No data warehouse, no Snowflake. Just enough history to detect breaks.

  3. Rule-based scoring

    Threshold violations, trend breaks, ICP mismatch signals. Simple logic applied consistently beats expensive models applied inconsistently.

  4. React frontend

    Tight data contract. Each view maps to a specific operator question. No unnecessary abstraction.

No ML model. The “intelligence” is encoded rules. That is a deliberate choice.

What I’d do differently

The biggest thing I underestimated was the Ads API auth complexity. OAuth refresh handling for multiple accounts is genuinely annoying. I’d abstract that earlier.

I’d also start with the alert rail as the MVP, not the full cockpit. The highest-value action is catching bad things early. The optimization queue comes second.

The takeaway

Operator-grade tooling for paid performance doesn’t have to be expensive or complicated. The Google Ads UI won’t change: they have no incentive to help you spend less efficiently. Build the layer that serves your decisions, not their interface. I wrote about when to build vs. buy GTM tools and the broader revenue system design principles that this approach follows. See AdsAI in action on my work page.


Related: B2B Revenue System Design: how operators think about growth differently · How to Build a GTM AI Agent for Outbound Research and CRM Enrichment

// About the author

Wojciech Łuszczyński

Wojciech Łuszczyński

GTM Architect and Growth Operator building AI-native revenue systems for B2B SaaS and technology companies. I connect positioning, SEO, content, paid acquisition, CRM, automation, analytics and AI workflows into practical growth infrastructure.

Newsletter

Get the next one first.

When I publish a new article on AI systems, GTM architecture, or growth operating models, you'll be the first to know.

Subscribe