Skip to main content
How We Grow

How We Put Our Whole Growth Funnel in One Dashboard

Issue #006 of How We Grow: Jim built an analytics hub that pulls every channel, sign-up, activation and cost metric into one dashboard we can question in natural language. Why we built instead of buying, and where it can go wrong.

9 min read

Key Takeaways

  • Your funnel lives in tools that don't talk to each other. Traffic in Plausible, ads in Google, product events in Amplitude, revenue in Paddle, impressions on LinkedIn. Reading one user journey means a tab-hopping session, so nobody does it often.
  • Since late 2025, building a dashboard beats configuring one. AI got good enough at understanding data and writing code that asking an LLM is faster than assembling charts in Metabase or Retool. So we built our own.
  • The dashboard is the facade. The pipeline is the product. Everything is API-connected inside our repo, so an LLM answers natural-language questions end to end: ad click, sign-up, feature usage, payment.
  • Verify every metric against its source of truth before you trust it. Pull the wrong data once and every decision downstream inherits the error. This is the one place Jim says you cannot cut corners.
  • Same time spent, much deeper answers. Monthly reporting still takes Jim a day and a half. It used to produce one report; now it produces a report plus every follow-up question he can think of.

Introduction

This is How We Grow, our weekly log of what we're doing to grow Kai. This week is Jim's story, and I mostly asked the questions. When we started working together at Morgen, Jim showed up to a daily meeting with a dashboard that genuinely impressed the whole team: the entire growth funnel, from traffic to revenue, in one centralized view. Over the past days he rebuilt that for Kai, and in this episode he walks through it. Here's what we cover:

  • Why we built our own analytics hub instead of adding another tool
  • The tour: a pirate-funnel dashboard where every stage splits by channel
  • How "just ask Claude" replaced building charts
  • Where this approach can go badly wrong

Prefer to watch or listen? Here's the full episode

Why we built our own analytics hub

One journey, four tools. Kai's data was scattered the way every startup's data is scattered. Traffic lives in Plausible. Ad performance lives in Google Ads. Once someone signs up, product events live in Amplitude, and Amplitude barely connects to anything that happened before the signup. Revenue in Amplitude is a proxy at best; the source of truth is Paddle, which has its own analytics for MRR, churn and lifetime value. Add LinkedIn impressions and Google Search Console, and answering a basic question like "traffic is growing but sign-ups are not, what's happening?" means hopping across 5 tabs and reconciling them in your head.

The thing Jim kept coming back to on the call: the moment you centralize everything in one view, you start seeing what you'd been overlooking. Not because the data changed, but because nobody cross-reads 5 tools on a Tuesday afternoon.

The October 2025 shift. We're not the first team to want this. The classic answers are Metabase, a data lake with custom dashboards, or an internal tool builder (we've used both Metabase and Retool). Jim's design decision was to drop all of them, and his reasoning is a date: those tools were great until roughly October 2025. After that, AI got good enough at understanding data and generating code that manually assembling a dashboard, with its filters, date ranges, charts and colors, takes longer than asking an LLM to build or query the thing directly. So the project had 2 goals: centralize all the data in one place, and set up what Jim calls a data analyst as a service. Someone you ask in your own words, no SQL, no filters, and who comes back with answers. In our case that someone is Claude, but any LLM plugged into the pipeline does the job; ChatGPT would answer the same questions.

Data hygiene came first. None of this works on top of a messy event layer. When Jim joined, we had around 15 Amplitude events sharing the same name, and nobody could say for sure which "signups" metric was the real one. Before building anything, he did the unglamorous pass: define the source of truth for each metric, align the team on it, and write it into the documentation so both humans and Claude pull the same numbers. Now a sign-up is a sign-up and revenue is revenue, which sounds trivial until you've worked somewhere it wasn't.

The tour: a pirate funnel with deep dives

The dashboard has 3 sections: growth, product analytics, and a health view that shows when each metric was last pulled.

The 30-second tour.

The map: every stage, its source.

Kai's growth funnel stages, each connected to its data source: LinkedIn, Instagram, TikTok, YouTube and Search Console feed awareness; Plausible feeds traffic; MongoDB sign-ups, the Neon landing DB and Google Ads feed acquisition; MongoDB and ClickHouse feed activation; Paddle feeds revenue. Below, the flow: a nightly ETL into one warehouse, the dashboard, and an LLM (Claude, in our case) for natural-language questions.

Growth is the pirate funnel, adapted. Awareness, acquisition, activation, revenue, plus 2 changes for our use case: traffic is split out of awareness as its own stage, and the referral stage is renamed virality (that pipeline comes later). The entry view is the funnel itself: visitors in the last 30 days, how many expressed interest on the landing, signed up, activated, retained, started paying. One glance gives you the shape of the funnel.

The same funnel, split by channel. This is the view Jim cares most about. Every stage breaks down by acquisition channel, so you can see that organic search brought 33 sign-ups and 55% of them activated, while paid search has a different volume and a different activation rate. That's how you spot the channels that bring sign-ups who actually stick, versus the ones that just bring traffic. These cross-tool funnel views are exactly the thing that normally takes a data analyst weeks to wire together, and it's where centralizing pays for itself.

The funnel and the channel grid, on the demo copy.

The /growth page of the dashboard: the end-to-end funnel from 26,923 visitors down to 9 paying, then the same funnel split by acquisition channel with showed-up, activated, retained and paying rates per channel. Demo copy with fake data.

Awareness pulls every social pipeline into one place. I create content on Instagram and TikTok, the whole team posts on LinkedIn, and Danny is taking over YouTube for long-form. Each source has a dedicated API pipeline feeding the dashboard, and each one has a drill-down: you can go from total LinkedIn impressions down to who on the team posted what, and which post drove the reach. We rarely need that resolution. The point is the 30-and-90-day read: we're investing effort across channels, and whether that effort produces 10,000 impressions or a million is a signal we want to measure, not guess.

One honest note about what you saw on screen. The dashboard in the episode is a full copy of the real one running on fake, generated data, because we can't share all the real numbers publicly. The structure, pages and pipelines are exactly what we use every day.

The part Plausible can't do. Plausible is GDPR-friendly by design: it counts visitors without remembering them, which means it can never link a website visit to an app user. To connect the funnel end to end we built our own tracking into the backend. When someone clicks an ad they carry a cookie ID, and when they sign up we write that ID next to the user. From then on, the link between acquisition and product behavior is permanent, and we still keep Plausible for the aggregate website view.

A data analyst as a service

Everything is API, deliberately not MCP. The dashboard repo lives in our knowledge base, and Claude reaches every data source through hardcoded Python scripts rather than MCP servers. Jim's reason is tokens: an MCP returns data as text for the model to re-read, and fetching a year of daily rows that way burns an enormous amount of context. A script returns exactly the aggregation you asked for. (Hallucination risk on long text tables is his second, softer reason.)

The question test. Here's the level of specificity this supports, in Jim's own example. Say we bet $500 on the keyword "executive assistant" in Germany for 20 days. You can ask: how many people clicked that ad, what did it cost, how many of them signed up, how many used feature X in the app, and how many still paid after 5 days. Every step is connected, so the answer comes back in one shot. Jim runs Morgen's reporting this way and, in his words, it nails it every single time.

What you can't connect. Google Search Console queries are a hard block: Google won't let anyone link a search query to what happens after the results page, whatever tool you use. What centralization buys you is good proxies. Organic clicks on a page from GSC, organic traffic in Plausible, and our own record of which page a user visited first line up well enough to reason about SEO without pretending the join exists.

Analytics next to the work. The quiet superpower is that the pipeline lives in the same repo as our sprints, tasks and commits. That means Claude can look at what we did over the past 8 weeks and what the metrics did, and start matching cause to consequence: did the homepage redesign move conversion, did my week of Instagram posts move impressions. It has access to both sides of the question, and that mapping is only going to get better as models do.

The scooter report. For 4 years, Jim's monthly reports followed the same ritual: pull numbers from several places, screenshot them into Notion, write the commentary. A day to a day and a half, every month. Now it's a skill, and the last time he ran it he was on a scooter, asking Claude from his phone. He still spends the same day and a half on reporting; it just goes into follow-up questions and interpretation instead of assembly. Faster answers didn't shrink the work, they deepened it.

Where this goes wrong

Jim's answer to "what's the downside?" was that there isn't one, if you build it right. The honesty lives in that "if":

  • Wrong data is worse than no data. If you think you're pulling metric A and you're actually pulling B, or A from 7 days ago, nothing looks broken until you check. Every metric in the dashboard was verified against its source of truth before we trusted it: GSC clicks against GSC, sign-ups against the database, revenue against Paddle. Skip that once and, as Jim put it, you're screwed for life.
  • Reconciliation gets harder as you grow. We're a small team with one product, which makes this the easy case. Add a B2B motion with a CRM, outbound sequences and open deals, and squaring that layer with B2C traffic and sign-ups is genuinely hard. Jim's previous company, at 50 to 100 people, was still fighting exactly this. His estimate for a company that size: about 2 weeks of build plus 4 weeks of hygiene and cleanup. Not nothing, but cheap for solving the data problem for good.
  • Track the right moments, or drown. The dashboard is only as good as what the site and the app capture. Track everything and you get noise; miss the moments that matter and your north-star metric is built on sand. And if the events keep moving month to month, you lose the ability to compare periods at all, which is half the value.
  • This is a v0.1. The Kai dashboard has the first charts that were immediately useful, and that's it. Our Morgen dashboard is far ahead, with deep cohort views and month-over-month funnels. The revenue section here is mostly untouched, because we're pre-revenue and there's nothing to wire yet.

What's next

The dashboard keeps growing: more charts, smart filters so common splits don't need an LLM round-trip, and the revenue pipeline once there's revenue to pipe. The team focus for the next weeks is acquisition and activation, so more content across channels, continued SEO, and a lot of product iteration on onboarding and the first actions a new user takes.

Also next week: our third hackathon, this time in Lisbon with the whole team together. Expect a very different episode. All of it is the run-up to the public launch on September 1st.

If you want to follow along, the whole series lives at How We Grow, and the changelog is the receipts of what we ship week to week. Sign up and each issue lands in your inbox, along with early access to what we're building.

About the author
Lambert Le Court de Béru
Lambert Le Court de Béru
Growth Engineer at Morgen

Growth at Morgen / Kai. I write about what I ship: free tools, SEO, CRO, the AI-native way of working.