Launch post

Meet Catapulse: the founder brief for subscription businesses

Catapulse is a founder-facing brief built on top of RevenueCat’s Charts API. Instead of giving you a wall of charts, it gives you a single operating table that tells you what changed, how much it changed, and why it matters.

The problem Catapulse is solving

There is a particular kind of disappointment that comes from opening a subscription dashboard right before a weekly review. The numbers are there. The charts are there. The filters are there. And yet the answer you actually need is still missing.

Not what are all the metrics? Not what does the curve look like? But: what changed in the business this week, and what matters first?

That is why Catapulse exists. The goal is not to impress a founder with more analytics UI. The goal is to make a founder faster.

The core idea

Most analytics products are optimized for exploration. Catapulse is optimized for a moment: the moment when a founder, growth lead, or operator opens the business and needs to understand whether acquisition is weakening, conversion is holding up, revenue quality is improving, or churn is becoming dangerous.

In that moment, more chart surface area is not always more helpful. Sometimes the best product is the one that removes the burden of interpretation. Catapulse does that by turning live RevenueCat subscription data into a compact founder brief that can be scanned in seconds.

What you actually get

Catapulse presents one operating table with four columns: Metric, Current, Change, and Current situation. That means each row gives a founder the raw value, the period-over-period movement, and a plain-language interpretation in the same place.

The current brief focuses on a selective set of founder-relevant subscription metrics, including active subscriptions, active trials, customers active, MRR, ARR, revenue, transactions, new customers, paying customers, conversion to paying, churn, refund rate, and a few recurring revenue movement signals.

The app also compares the selected window against the previous matching window. So if you are on 28d, you are seeing the current 28-day view versus the previous 28 days. That makes the interface answer not only “what is the metric?” but also “is it improving?” and “what does that movement mean?”

Why charts are out

The early versions looked more like what people expect from analytics products: multiple modules, chart blocks, cards, and sections. They worked technically, but they were forgettable. Once the charts came out, the product got sharper.

Founders do not need a prettier way to hesitate. They need a clearer way to decide. At the top level, a lot of founders do the same mental loop every time they open analytics: see the number, compare it mentally, decide whether it matters, guess what might be driving it, and then decide what to inspect next.

Catapulse compresses that loop. The product is not “here are your metrics.” It is: here are your metrics, here is how they moved, and here is the first interpretation.

What the brief surfaced on a live subscription app

The default Catapulse demo runs on a real subscription app dataset rather than on a fabricated mock. Because the app is driven by live RevenueCat responses, the exact values continue to change over time. That is part of the value: the brief reflects the state of the business right now.

During testing, the 28-day view surfaced a pattern that feels very realistic for a subscription app: revenue was roughly flat, new customers were down much more sharply, conversion to paying was up, churn had worsened, and refund rate had also worsened.

That is a meaningful founder read. It suggests a business that is not collapsing, but is under pressure in ways that a topline-only view could easily hide. A chart-heavy dashboard would let you discover that eventually. Catapulse tries to make it obvious faster.

Why this matters

If you are an indie founder or small team running a subscription business, there are usually only a few questions that matter every week: are we growing, is acquisition feeding the funnel, is the funnel converting, are we retaining what we win, and is recurring revenue quality getting better or worse?

Catapulse is built around those questions. It is not trying to replace a full analytics stack. It is trying to become the fastest high-signal read inside that stack. Not everything needs to be a platform. Sometimes the best tool is a strong lens.

What makes Catapulse different from a normal dashboard

There are plenty of products that can show you metrics. What makes Catapulse different is the combination of one-table clarity, real period comparison, interpretation instead of passive display, live project switching, and a deliberate founder-first prioritization of the signals that matter most.

A lot of internal tools get worse as they get more comprehensive. Catapulse is trying to be useful by being opinionated.

Why this is a compelling use case for RevenueCat’s Charts API

What makes Catapulse especially interesting is not only the tool itself. It is what the tool suggests about RevenueCat’s Charts API. The obvious use case for a charts API is to build charts. The more interesting use case is to build products that think in metrics, not in chart components.

Catapulse exists because the API already gives enough structure and signal to support founder briefs, weekly operating reviews, AI-generated subscription summaries, internal growth copilots, investor update generators, and compact workflow-specific reporting tools.

That matters because adoption is rarely driven by endpoints alone. It is driven by seeing what kinds of products suddenly become possible. If Catapulse makes another builder think, “this could power a Slack weekly brief or a founder review assistant,” then it is doing more than demonstrating implementation. It is demonstrating a category.

How Catapulse works

Catapulse is built as a Next.js app with a deliberately thin client and a more opinionated server-side data layer. That architectural choice matters for two reasons. First, RevenueCat keys stay on the server. Second, the messier logic — project resolution, live chart fetching, retries, period aggregation, and row interpretation — lives in one place instead of being spread across the UI.

Founder opens Catapulse
Next.js app
Local API route
RevenueCat data layer
Resolve project from key
Fetch live chart data
Aggregate windows and generate founder brief rows

The browser only needs one payload: a normalized founder brief. That lets the frontend stay simple while the server does the heavier work of turning raw chart output into a sharper operating read.

For example, the local API route accepts a pasted RevenueCat key and rebuilds the brief for the newly resolved project:

TypeScript
export async function POST(request: Request) {
  const body = (await request.json().catch(() => ({}))) as {
    apiKey?: string;
  };

  const dashboard = await getDashboardPayload({
    apiKeyOverride: body.apiKey,
  });

  return NextResponse.json(dashboard);
}

Under the hood, Catapulse then fans out across the RevenueCat chart endpoints it needs, including actives, trials, MRR, ARR, revenue, conversion, churn, refund rate, and movement-related signals.

TypeScript
const [
  actives,
  mrr,
  arr,
  revenue,
  customersNew,
  customersActive,
  conversionToPaying,
  churn,
  refundRate,
] = await Promise.all([
  revenueCatGet(`/projects/${projectId}/charts/actives`, { start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/mrr`, { resolution: "0", start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/arr`, { resolution: "0", start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/revenue`, { start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/customers_new`, { start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/customers_active`, { resolution: "0", start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/conversion_to_paying`, { start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/churn`, { start_date, end_date }),
  revenueCatGet(`/projects/${projectId}/charts/refund_rate`, { start_date, end_date }),
]);

From there, Catapulse does the more important product work: it decides how each metric should behave in a founder brief. Some values are averaged across the selected window, like active subscriptions, customers active, MRR, and ARR. Others are summed across the window, like revenue, transactions, new customers, and trial starts. Rate metrics such as conversion, churn, and refund rate are treated as rates rather than totals.

The final row shape is intentionally simple:

TypeScript
{
  metric: "Revenue",
  current: "$5,127",
  change: "-1.5% vs previous 28d",
  situation: "Revenue is essentially flat versus previous period."
}

That row tells the story much faster than a dashboard that forces the founder to inspect multiple visual modules and synthesize the answer manually. The most interesting technical shift is that the Charts API is doing more than feeding a dashboard. It is acting as the substrate for a product that feels closer to a weekly operator memo than an analytics surface.

Using Catapulse is deliberately simple

Open the app and you immediately see the project ID, the project name, the date coverage, and the founder brief table. Then you do one thing: switch between 7d, 28d, and 90d.

That is enough to understand whether the business is experiencing short-term momentum, medium-term softness, or longer-term improvement or decline. If you want to run the same brief on another project, click Change, paste another RevenueCat V2 key, and the app rebuilds the brief for that project.

That is the whole loop. Simple in the UI. Strong in the output.