The question every data lead asks after the first month on Claude Code is the same one: is the Max plan actually paying for itself, or are five people just burning weekly limits in parallel?
In This Article
We have been running Claude Code as the daily driver across two teams, one inside a $6M marketplace (Sniffspot) and one inside the consulting practice (Valiotti Data). Five engineers, one personal Max plan each, roughly $100 per seat per month at the Max 5x tier. No shared workspace, no API routing, no clever per-task arbitrage. Same setup for everyone. After two months the answer is “yes, it pays,” but only because we made specific choices about what we ship through it. This post is the accounting: three real rollouts with numbers, the per-seat economics, and the onboarding playbook we’d run if we hired a new data engineer tomorrow.
This is the team-level view: where the spend lands, why, and how a new hire ramps onto it. The mechanics of model selection, effort levels, and prompt caching live in the per-tool guides on the blog.
Three rollouts, three line items
The case for Claude Code on a data team is not “AI writes code faster.” It is that specific recurring tasks collapse from days of human attention into bounded sessions with concrete outputs. Three from the last sixty days, each with a number that did not exist before we ran it through Claude Code.
Fivetran connector setup: 4 hours to 20 minutes
The job was wiring HelpScout into BigQuery for a marketplace client. Customer support lead had sent over a written shortlist: 11 parent tables to keep, around 15 children to skip, because HelpScout’s child tables are noisy and the wrong choice would blow the MAR budget.
In the pre-Claude workflow this is a 30-minute Fivetran UI session, 26 manual schema checkboxes (no diff view, no undo), hours of validation queries, and a separate Notion writeup. The docs get written from memory after the fact and read like guesses.
With Claude Code wired to Fivetran’s official MCP, the working session was five sentences typed into a terminal. Claude found the destination, ran the schema reload, applied the keep-list as a JSON patch, kicked off the sync, validated 1.4 million rows against twelve queries it generated, and wrote the Notion page from the actual row counts. Sonnet 4.6 at medium effort handled the whole flow; Opus stayed in the holster. Total hands-on engineering time: under twenty minutes.
The win is not “AI replaced the engineer.” The win is that the docs are now written from the real data, the schema config is in version control as JSON, and the next connector setup is a copy-paste of the prompt with the table list swapped.
Metabase question audit: a week to an afternoon
A different client, three years on Metabase, 500-plus saved questions, 60 dashboards, three teams’ worth of legacy nobody had inherited. The brief was the standard one: figure out what matters, what’s dead, what to archive.
The pre-Claude version of this audit was a solid week of work. Pull a CSV of all questions, talk to three team leads, cross-reference the activity log by hand, build a spreadsheet of used-versus-unused, map surviving questions back to source tables, spot patterns. The kind of project nobody wants to staff, which is why the audit gets postponed for two quarters.
With Claude Code and the Metabase MCP, the working session was three prompts. Prompt one: rank all questions by 90-day view count, group by collection, surface top 50 and bottom 100. Prompt two: pull the SQL for the top 50, parse out the source tables, build a frequency map. Prompt three, the one no spreadsheet would have caught in time: identify duplicate questions where two or more cards return effectively the same result with minor variations. Claude flagged 47 near-duplicate pairs across the instance and grouped them so the analyst could pick canonicals in 20 minutes. Top 50 questions accounted for 78% of all views. Three of the five most-queried tables had been flagged for deprecation in the previous quarter’s data engineering review, and nobody on the BI side had been told.
Sonnet 4.6 at high effort, one session, no Opus needed. The audit that used to be a week was effectively done in an afternoon, and the deliverable was cleaner than the hand-built version because every claim was tied to a query Claude had actually run.
MetaLens build: $200 of compute against a $50K consulting baseline
The third rollout is the one we ran on ourselves. MetaLens is the agent platform we built to automate the Sprint engagement, the diagnostic-plus-strategy work we used to deliver manually as fractional Head of Data. The baseline price for that engagement, market rate, is $50K and four to six weeks of consultant time.
The MetaLens build was three months of one operator (Nick) shipping at three to five times the previous solo pace. Stack is Next.js 16, React 19, Postgres with pgvector, Claude API for the agents themselves, Claude Code as the development environment. The output is a production platform with eight agents shipped (X-Ray, Catalog, Search, Chat, Builder, Review, Gap, Metric Tree), live on a real client’s Metabase, with the audit that used to take two weeks running in 90 seconds.
The dollar number that matters: compute cost to deliver one Sprint through MetaLens runs roughly $200 against the $50K manual price. That is the margin shift from consulting (35%) to software (95%) with the same buyer paying the same number. It is not a benchmark and we are not going to pretend it is portable to every team. But the operating ratio is the case for AI-native delivery: one operator with Claude Code running the development environment ships what used to require a four-engineer team and a six-week timeline.
Team economics: where the $100 per seat actually goes
The setup across our two teams is deliberately uniform. Every engineer gets one personal Claude Max 5x plan, roughly $100 per month per seat. No shared workspace, no API routing for analysts, no clever team-level pooling. We considered the alternatives and chose simplicity. The reasons:
A shared API key with usage routing sounds efficient on paper. In practice it adds operational overhead (per-user budgets, per-task cost monitoring, finance reconciliation) that costs more than the seats it saves. For a team of five, the math doesn’t work. For a team of fifty it might, but that’s a different problem.
The Max plan is not “API credits with a friendly wrapper.” It is a usage cap measured in five-hour windows and weekly buckets. Treat it as an all-you-can-eat plan with a Thursday-night ceiling and the math gets simple: as long as the engineer is using Claude Code daily, the seat pays for itself by Wednesday. Sporadic users (an analyst who fires up Claude Code twice a week) would be cheaper on metered API. But our team uses it as a daily driver, so Max wins.
The trap we walked into early: the Opus weekly budget on Max is a separate, smaller bucket than the Sonnet bucket. A team that defaults to Opus runs out of Opus by Thursday and spends the rest of the week debating whether to escalate or wait. The fix is a team default written into the shared CLAUDE.md: Sonnet 4.6 is the daily driver, Opus 4.7 is for architecture and hard debugs, Haiku 4.5 is for bulk routine. Without that line, every engineer makes the choice differently and the Opus budget gets allocated by who clicks fastest.
There is a related failure mode worth flagging because it is the standard one, not the rare one. The cache discipline that keeps a session cheap depends on not blowing it up mid-session. The most common way to blow it up is to paste a long document into context and forget to /compact before continuing. We did this with a long Notion document early on and burned the remaining session tokens in one shot. Lesson: /compact before any large paste, or split sessions when you know a heavy context load is coming. This is not a rare edge case. It is how most session-cost spikes happen in practice.
Onboarding playbook: the harder problem is absorbing the codebase, not writing code
When Boris joined Sniffspot as a data engineer in March, the temptation was to think about Claude Code as a productivity tool: “use the AI to write code faster.” The first three weeks of conservative AI use confirmed the boring truth, which is that on a brand-new codebase, writing code is not the bottleneck. Understanding the codebase is. The unlock came in week four, and it was not “Claude wrote a parser for me.” It was using Claude Code to read and explore Sniffspot’s existing infrastructure, which is the harder problem for any data hire in week one.
Reframe the playbook accordingly: Claude Code’s biggest contribution to onboarding is helping a new engineer absorb an unknown codebase, not write new code faster. With that frame, the four-week ramp looks like this.
Week 1: bulk routine on Haiku, no Opus. Give the new hire the things every codebase has, the tasks that don’t require business context: rename a misnamed table across the warehouse, normalize the date format on a legacy column, format twenty SQL files to the team’s style. Haiku 4.5 handles all of it at three times the speed and a third the cost. The point isn’t the output. The point is teaching the new hire what a clean Claude Code session feels like before the work gets ambiguous.
Week 2: codebase reading on Sonnet, light writing. This is the unlock week. Have the new hire use Claude Code to explore the existing infrastructure: “read these three repos and explain how data flows from Aurora to BigQuery”; “summarize what each table in this schema is for and which downstream models touch it”; “find every place in the codebase where revenue is calculated and tell me whether they agree.” Sonnet 4.6 at medium effort, single session, with /context checked once after the MCPs load. This is the work that used to take a senior engineer two weeks of pair programming with the new hire. With Claude Code reading alongside them, the new hire compresses it into days and the senior engineer gets their afternoons back.
Week 3: introduce effort and context discipline. By week three the new hire is hitting the cache and the weekly Max limit. This is the moment to teach the three habits that survive contact with real work: /context once after MCPs load to find anything bloating the window; /compact proactively at natural breaks (not under pressure); never switch model mid-session unless you’ve decided the rest is cheap. Pair this with a CLAUDE.md update so the new hire’s defaults match the team’s.
Week 4: graduate to multi-file work on Sonnet, reserve Opus for the hardest problem. By week four the new hire should be shipping multi-file refactors, debugging cross-system data flows, and writing the kind of code that needs real reasoning. Sonnet at high effort handles all of it. Opus 4.7 comes out for the one or two problems per week that are genuinely architectural: “design the partitioning strategy for this 600 GB table” or “the two dashboards disagree and Sonnet has given up.” Reserve it, don’t default to it.
What this article deliberately does not cover
This is the team-level view. The mechanics of how Claude Code actually works (model differences, effort levels, prompt cache lifecycle, context discipline) live in a separate body of writing. For the day-to-day operating manual, the existing guides cover the per-tool decisions: dbt MCP, Fivetran MCP, BigQuery MCP Toolbox, and Metabase MCP. Read them in the order your stack hits them: the warehouse and the BI tool first, the EL tool next, the transformation layer last.
The economics scale linearly with team size up to about ten engineers. Past that, the operational case for a shared API workspace gets stronger and the case for one-Max-per-engineer gets weaker. If you’re rolling out to twenty engineers, the math is different and the failure modes are different. That’s a separate post.
If you’re a data lead reading this and wondering where to start, the answer is not “buy seats and hope.” Pick one of the three rollout types above (a connector setup, an audit, or a build) and run it through Claude Code end to end. Note the time, note the model, note where it failed. The first run is the calibration. The second run is the one that pays.
