How to run analytics without a data team

Analytics without a data team is a real thing to want, and plenty of teams type exactly that into a search bar. Usually it means this: you have a Postgres database, maybe a warehouse, and one person everyone messages when they need a number. That person has better things to do. You can run real analytics, dashboards, reports and governed numbers included, with or without a dedicated data person, and this is how.

The "can you pull this" problem

At most startups under 50 people, analytics works like this: someone needs a number, they message an engineer, the engineer writes a query, pastes the result into Slack, and goes back to what they were doing. This happens five to ten times a day.

The engineer loses the thread of their actual work. The person who asked waits hours or days. And the answer dies in a Slack thread nobody will ever find again, which means the same question gets asked again next month.

The obvious solution is to hire a data person. But you are competing with every other startup for the same small pool, the hire takes three to six months, and even once they start they will spend the first quarter building pipelines and dashboards before anyone gets a faster answer.

What Tilt did instead

Tilt is a live-auction marketplace. They had the same problem in a slightly different shape: one data person, and everyone in the company queued behind them for every question.

Rather than growing the data team, they connected their warehouse to Contextflo. Setup took about ten minutes. No data model to build, no dashboards to configure, no training. People started asking questions through Claude.

Founder: what's our gross merchandise value this week compared to last week?

Ops lead: which sellers had the most returns in the last 30 days?

Marketing: how many new buyers came from the Instagram campaign last month?

Each of those gets answered in a couple of minutes, without the data person being involved and without a ticket.

It is not only ad-hoc questions in a chat window. The same setup does the jobs you would stand up a BI tool for: dashboards, scheduled reports, governed metric definitions so revenue means the same thing every time, table-level access control over who can query which tables, and a per-user audit trail of every query that runs. You drive it from Claude or ChatGPT, and the dashboards are there when you want to open one.

Where it got to

~6,000	queries a month from the team
Most of the company	asking questions directly
1	data person, unchanged
0	additional data hires

That third row is the important one, and it is worth being precise about. Tilt did not run their analytics with nobody. They had one data scientist before and they have one now. What changed is what that person spends their day on: the ad-hoc queue moved off their desk, and they went back to actual data work.

That is the honest version of the phrase people search for. It does not mean nobody owns the data. It means the whole team gets answers without queuing behind the one person who does, whether that person exists yet or not.

How to do this at your company

A database. Postgres, BigQuery, Snowflake, ClickHouse, Redshift or Databricks. If your product has users and stores data, you already have this.

Ten minutes to connect it. Contextflo generates the business context, the table relationships, column descriptions and metric definitions, so the model understands your data without someone mapping it by hand.

A team that has questions. No training needed. If someone can type a question in English they can get an answer: the founder asking about revenue, the ops lead checking supplier performance, the marketer measuring campaign ROI.

The honest fourth item is that someone has to care when an answer is wrong. It is not a full-time job, but it should have a name attached, and it is usually whoever owns the data today.

When to actually hire a data person

This does not mean you will never need one. Once you are processing millions of events, building models, or running real-time pipelines, you want dedicated data engineers and no amount of self-serve replaces that.

But if you are early and your main data problem is that people cannot get answers without asking an engineer, that is not a hiring problem. It is an access problem. Solve the access problem first, and hire for data engineering when you need data engineering, not when you need someone to run SELECT queries.