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. Not commission them — run them, or watch someone run them, start to finish. 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

Not “revenue from the analytics tool.” The number your pipeline reports, compared against what Stripe or your billing system says for the same period, to within rounding. 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. It’s off by 2–4%, persistently: refunds counted as revenue, a webhook retry that double-wrote invoices, a timezone boundary that drops the last day of each month into the wrong month. 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, not 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 isn’t about the product; it’s about whose chart is lying, and it repeats every month until the definition lives in exactly one versioned place.

3. Retention by monthly cohort

Not a blended retention number — a table: for each signup month, what fraction 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, not 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 — invisible for as long as marketing data lives in ad platforms, revenue lives in Stripe, and no table joins them. Teams routinely discover their “best” and “worst” channels swap places the first time this query runs.

5. Freshness: when did each source last land

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 exactly why it needs a dedicated query, and ideally 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, 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. The CAC-to-retention join failing means your sources were never joined anywhere. Unknown freshness is an operations problem — nobody owns the pipeline. None of these are solved by a bigger engine or a prettier BI tool; they’re solved by tested models, 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.