Data is worthless until it becomes a data product - a decision, a report, an answer, or something you can sell. Building the pipeline that gets you there used to need a whole team. If you're the only data person in the building, it doesn't any more.

---

Introduction

Analytics engineer. Data analyst. Insights lead. BI developer. Or just "the data person". We have so many different labels, but if you're the only data person in your company, they all mean the same thing - you're a data team of one. Forget the label, I prefer to focus on the wine value we add.

I often like to use the analogy that raw data is like oil - it's inert and not valuable or useful until it's been refined into petrol, which is used to power cars. It's an old (if somewhat dated) analogy, but gets the point across. In our world, it's the refined data that powers a data product - a dashboard someone acts on, a piece of analysis that answers a real question, an API powering a saleable product, etc.

Getting to that refined product is the hard part, and as a data team of one it's where you can end up spending nearly all your time. That's exactly what's changed.

The barrier to entry has dropped so far that companies who would have previously been priced-out of hiring (or outsourcing) a fully-fledged data team can now afford it by using the people (i.e. you) they already have. AI hasn't made the thinking cheaper, it's made the doing cheaper. Knowing what to build is still on you. But delivering on it? That's the cost that's gone through the floor.

This is not an "AI can replace your data team with one person" post. I'll say it plainly, because it's the lazy and just wrong conclusion. It's closer to the opposite. It's not about fewer people, it's about taking the existing data teams of one (i.e. most data people in most small/mid size companies) and turbo-charging them into someone who makes a genuine business impact.

1. Getting the data

Step one is to get at your data. Without it, we're a little bit stuck. This type of work is traditionally called data engineering, but that's just another label not too relevant to solo data teams.

We need our data somewhere central, I generally use Google's BigQuery for this as it's cheap and well adopted. And as I work mostly with marketing teams, common tools such as Google Analytics, Ads and Search Console all connect straight into BigQuery for free - you mostly just switch it on.

The hard part comes when the tools you use don't have native warehouse connections. For example TikTok Ads, LinkedIn organic, and your CRM stats. We could look at buying a solution that connects and manages API connections to these tools (i.e. Fivetran, Funnel or Supermetrics), but that could cost hundreds per month and only increase as we use it more.

Let's not forget the monitoring component which should be baked in from the first line. If a data source stops, an API breaks or a data set is delayed - we should know before a stakeholder does.

What used to need a data engineer

Standing up ingestion was once a specialist's whole job. Now most of it is either free via Google's Data Transfer Service, or we can use open-source and well-documented ETL frameworks such as Airbyte. Point Claude at your list of data sources and it'll walk you through wiring them into BigQuery and write the config alongside you.

Ask Claude how to set up automated alerts and it'll guide you step-by-step through the process too! We shouldn't need to monitor this as part of our weekly to-do list, it should tell us if there's something to investigate.

2. Making the data useful

Next up is turning that oil to petrol. Or rather, the analytics engineering part that turns your data lake into useful business-specific reporting tables. Your KPIs, your targets, your customer segments, your definition of a "qualified lead".

The industry converged on a standard way to do this years ago - clean the raw data, model it into core business tables, aggregate those into reporting tables - but the convention isn't the point (just more labels). The business logic and context you pour into it is. AI will happily write the models but it can't tell you what a "qualified lead" is for your business, or if a 5% drop in revenue is an anomaly or just a standard Wednesday in January. AI is not a substitute for knowing what good looks like.

Alongside the data models, two additional things get baked in here.

• Validation: Assertions that fail loudly on impossible values, plus checks for the silent failures that don't throw errors, like a broken 'pay now' button. Without this, no one will trust the data, and thus it won't be used. It's the least sexy but most important part of this whole thing.
• Documentation: documenting what each field in your reporting tables means. This used to be a tedious and very manual afterthought. For reasons that land in the next stage, this will be the most useful thing you do.

What used to need an analytics engineer

This is the stage AI is strongest at, precisely because the shape is so conventional. Thousands of teams have built it the same way and written about it publicly for over a decade, which is what these models trained on. You bring the business logic and Claude builds the models to express it, the tests to check it, and the field descriptions to document it.

Ask Claude to build out the modelling layer in Dataform via a GitHub repo and it's like any other coding project. Claude will walk you through the scheduling, alerting and testing/dev processes too, just ask it to teach you as you go and it's the best learning partner you could have (i.e. infinitely patient and doesn't charge by the hour!). Check out this post from Anthropic on analytics with Claude for a bit of further reading on this component.

Regarding documentation, I have yet to meet anyone who enjoys writing it. And most people (me included) tend to leave this to the very end... It used to be a genuine time-suck, but now it's generated as you go. And with the right connectors/MCPs, Claude will push your data dictionary, table schemas and 'non-data person' version of what it all is straight into Confluence, Notion, Drive, etc. It simply exists automatically, rather than sitting on the to-do list.

3. Turning the data into products

For twenty years the end of this pipeline was a dashboard, and we mistook the dashboard for the goal. It never was. The goal is whatever the data lets someone do.

Sure, a dashboard is one kind of data product. But so is a piece of analysis - a proper answer to a real question, still the highest-value thing most of us data people produce. So is an automated update or alert pushed into Slack or a presentation, where the decision gets made. As my mate Bhav Patel put it on a recent episode of our podcast: "fish where the fish are".

Remember those field descriptions from the last stage? This is where they pay off. When an LLM answers a question against your warehouse, well-described tables are the difference between a right answer and a confident wrong one. The documentation automated upstream is exactly what stops our AI-based data products (i.e. building an MCP) from hallucinating.

An under the radar shift most people haven't clocked yet is that the same data infrastructure that powers the internal decisions can, with barely any more work, become a product you monetise. The warehouse stops being a reporting destination and becomes infrastructure for saleable products for your customers.

What used to need its own team

Every one of those formats was once a separate skill set - a BI developer, a back-end engineer, an ML person. Now they're mostly well-documented libraries, which is exactly what AI is good at helping you wire together. For example, I built a live GA dashboard on this very site by pointing Claude at the Google Analytics Data API and letting it do its thing.

Self-serve analytics was once an impossible pipe dream, but is now firmly within reach. As a data team of one, you cannot be everyone's reporting monkey, data wrangler or pivot table fixer. By focusing on the well-documented infrastructure, you could build an MCP on top of your reporting tables for your teammates to ask their own questions, do their own analysis and build their own dashboards. This becomes trivial when pointing Claude to FastMCP and in no time at all you can have an MCP your colleagues can install and use. Or how about pointing Claude to FastAPI and then you can have an API your developers can use in a client-facing dashboard.

Remember that building things is now the easy bit, but knowing what to build comes from you.

The barrier just came down - for everyone

Three very different skill sets. That used to mean hiring three or more people, or contracting a third party, or (for most companies) simply going without.

For most of my career I could tell you exactly what the tables and the end data product should be, I just couldn't build them, and I certainly couldn't build the automation joining them all up. Now I can, and I'm learning as I go.

That's the real shift, and it's bigger than "AI writes SQL now". The time-and-cost wall between raw data and a valuable data product has come down - and furthest for exactly the people locked out before: the small/mid-sized companies that could never justify hiring a full data team.

What hasn't changed is the hard part - knowing what to build, and knowing when your numbers are lying to you. So if you're a one-person data team, this is genuinely within reach - more than you probably think.

Honestly, being a one-person team is great in some ways but also lonely. I've worked with many solo data people in various different companies over the years, and the companionship is genuinely the most valuable part. Getting to bounce ideas back and forth, get excited about a cool data model, and even vent about non-data people from time to time! This doesn't happen in data teams of one.

If you want some company from someone who can get you there faster and more efficiently, then get in touch. From getting my hands dirty with you in the trenches, to advising/mentoring you from the barracks. I can help.