The five queries every founder should be able to run

There's a cheap diagnostic for any startup's data setup, and it doesn't involve auditing tools or interviewing engineers. Sit down on a Tuesday and try to run five queries. Run them yourself, or watch someone run them start to finish; commissioning them doesn't count. If each one takes minutes and you believe the answer, your stack is healthy, whatever it's made of. If any of them turns into a two-day archaeology project, you've found the real problem, and it's rarely the one on a vendor's slide.

The five aren't arbitrary. Each catches a different way numbers rot, and together they cover the questions a board, an acquirer or your own roadmap will actually ask.

The five queries

1. Revenue, reconciled against the billing system

Start with the number your pipeline reports, compared against what Stripe or your billing system says for the same period, to within rounding. Stripe's Balance summary report exists for exactly this kind of monthly reconciliation. This is the query that matters most, because every other financial metric inherits its credibility from it, and because it's the first number an investor or acquirer will check independently.

When it's wrong, it's rarely wrong by a lot. In the pipelines we've audited it's usually off by a few percent, persistently, and the causes are mundane. Refunds get counted as revenue. A webhook handler double-writes invoices, because Stripe says plainly that endpoints might occasionally receive the same event more than once and the handler never checked event IDs. A timezone boundary drops the last day of each month into the wrong month, since Stripe's reports default to UTC unless you pick a time zone and your warehouse may not. Small persistent drift is more dangerous than a big obvious break, because it survives long enough to reach a board deck.

2. Activation rate, with the definition inline

The query itself should contain the definition ("signed up, then created a project and invited a teammate within 7 days") as readable logic, instead of a pointer to a doc that may or may not match. Activation is the metric most likely to be defined three ways in three tools, because it's the one everyone wants to improve. Wrong looks like this: growth says 41%, product says 33%, the deck says 38%, and each is faithfully computed from a different definition nobody wrote down. The argument that follows is about whose chart is lying, and it repeats every month until the definition lives in exactly one versioned place.

3. Retention by monthly cohort

You want a table here, and a single blended number won't do. A cohort is a group of users who share a common characteristic, here their signup month, and the table shows what fraction of each one was still active one, three and six months later. Blended retention averages new customers with old ones, and growth inflates it: pile enough fresh signups on top and the headline number stays flat while every recent cohort quietly decays faster than the one before it. The cohort table is where that shows up first, months before revenue does. If your stack can only produce the blended number, that's the tell that events and billing were never joined at the customer level.

4. CAC by channel, joined to retention

CAC by channel alone is easy and mostly useless; the join is the point. Spend divided by signups rewards the channel that produces the cheapest customers, which aren't always the ones who stay. The question that matters is: for each channel, what did a customer cost, and what fraction were still paying at month three? Wrong looks like a paid channel that wins every budget review on CAC and turns out to supply most of your churn. It stays invisible for as long as marketing data lives in ad platforms, revenue lives in Stripe and no table joins them. In our experience, it's common for a team's "best" and "worst" channels to swap places the first time this query runs.

5. Freshness: when did each source last land

This is the meta-query that decides whether to trust the other four. For each source (production database, billing, ad platforms, support), when did data last successfully arrive, and is that inside the window you promised yourself? Wrong looks like nothing at all, which is the problem. The classic pattern is a billing sync that died nine days ago without alerting anyone: every chart still renders, every number is plausible, and all of them describe last week. Stale data doesn't look broken. That's why it needs a dedicated check, and tools like dbt let you declare warn_after and error_after thresholds for each source so it fails loudly. Ideally there's also a page someone glances at every morning.

If all five are easy, don't buy anything

Run them honestly. If each takes minutes, returns a number you'd defend to your board, and two different people get the same answer, your stack is fine. It does not matter that it's a read replica and some SQL in a shared doc, or that a vendor would call it immature. Don't buy a warehouse, don't hire a data engineer, and don't take the call with us. Revisit in two quarters.

If instead one of them takes days, requires the one engineer who still remembers the schema, or returns a different answer on the second run, the specific query that failed tells you what's actually missing:

• Reconciliation failing is an ingestion-correctness problem.
• Activation ambiguity is a definitions problem.
• A failed CAC-to-retention join means your sources were never joined anywhere.
• Unknown freshness is an operations problem: nobody owns the pipeline.

A bigger engine or a prettier BI tool solves none of these. What solves them is models with data tests on them, one definition per metric, and someone whose job it is to notice when a sync goes quiet.

That last part is the business we're in. We build the small, tested stack that makes these five queries boring to run, and we operate it on retainer so they're still easy to answer next quarter.

Sources

• Balance summary report, Stripe
• Receive Stripe events in your webhook endpoint, Stripe
• Cohort exploration, Google Analytics Help
• freshness, dbt Labs
• Add data tests to your DAG, dbt Labs