Home / Guides

Guide

Your first data hire vs a consultancy: how to decide

Most seed to Series B companies hit the same wall: the board wants numbers, the dashboards disagree, and nobody owns the data. You can hire, bring in outside help, or do both in sequence. Here's how to think it through.

The real question: what has to be true in 90 days?

Before comparing options, write down what "done" looks like: which metrics must be trusted, by whom, and by when. Board-ready revenue and retention numbers in one quarter is a very different brief from "build us a data team".

End-to-end data stack: sources to BI and AIFour sources (Stripe for payments, HubSpot CRM, the Postgres app database, Google and Meta ad platforms) feed an ingestion step, Fivetran (managed) or Airbyte (open source). Both load raw schemas into the warehouse. Inside the warehouse dbt builds staging, then intermediate, then marts models. Marts feed a semantic layer where MRR, churn and CAC are defined once, and the semantic layer feeds BI tools, AI and LLM tools, and exports such as the board pack. An orchestrator, Dagster or Airflow, schedules ingestion and dbt runs (control, shown dashed). The highlighted key path is marts to semantic layer to consumers.Data flowControlKey pathSourcesIngestionConsumersWarehouseStripepaymentsHubSpotCRMPostgresapp databaseAd platformsGoogle · MetaFivetranmanaged ELAirbyteopen source ELrawlanded as-isstagingrename, castintermediatejoins, logicmartsfct_ · dim_Semantic layerMRR · churn · CACBI toolsdashboardsAI + LLMstrusted metricsExportsboard packOrchestratorDagster or Airflow · schedules runsEnd-to-end data stack: sources to BI and AIFour sources (Stripe for payments, HubSpot CRM, the Postgres app database, Google and Meta ad platforms) feed an ingestion step, Fivetran (managed) or Airbyte (open source). Both load raw schemas into the warehouse. Inside the warehouse dbt builds staging, then intermediate, then marts models. Marts feed a semantic layer where MRR, churn and CAC are defined once, and the semantic layer feeds BI tools, AI and LLM tools, and exports such as the board pack. An orchestrator, Dagster or Airflow, schedules ingestion and dbt runs (control, shown dashed). The highlighted key path is marts to semantic layer to consumers.4 sourcesStripe, HubSpot, Postgres, adsFivetran or Airbyteloads raw datarawlanded as-isstagingstg_ · rename, castintermediateint_ · joins, logicmartsfct_ · dim_Warehouse · dbtSemantic layerMRR · churn · CAC defined once3 consumersBI tools · AI + LLMs · exportsRuns scheduled by Dagster or Airflow
Figure 1. One direction of flow and one definition per metric, so the dashboard and the AI give the same answer.

Side-by-side

Before and after: a messy stack vs a clean data foundationBefore: spreadsheets, the production Postgres database and monthly Stripe CSV exports all feed the BI tool directly. Three dashboards (board deck, sales, finance) each compute revenue in their own SQL, so there are three numbers for revenue, dashboards load production, and nothing is tested or versioned. After: Stripe, HubSpot and the app database load into the warehouse and dbt builds staging models, which feed both marts, fct_revenue and dim_customers. Both marts feed the semantic layer, where the revenue metric is defined once, and the board, sales and AI all read that metric. The highlighted key path is fct_revenue to the semantic layer to every consumer.Before · typical first-year stackAfter · data foundationSpreadsheetsmanual exportsProd Postgreslive app DBStripe CSVsmonthly exportBI toolBoard deckrevenue #1Sales dashrevenue #2Financerevenue #3Which revenue is right?three dashboards, 3 answersStripeHubSpotApp DBstg_ models1:1 with sources, renamedfct_revenueaccount × monthdim_customersone per customerSemantic layermetric: revenue · defined onceBoard · Sales · AIread the metric, same number× Three numbers for “revenue”× Dashboards load production× No tests, docs or version control✓ One number for “revenue”, everywhere✓ Consumers read the semantic layer✓ Tested, documented, in your Git repoBefore and after: a messy stack vs a clean data foundationBefore: spreadsheets, the production Postgres database and monthly Stripe CSV exports all feed the BI tool directly. Three dashboards (board deck, sales, finance) each compute revenue in their own SQL, so there are three numbers for revenue, dashboards load production, and nothing is tested or versioned. After: Stripe, HubSpot and the app database load into the warehouse and dbt builds staging models, which feed both marts, fct_revenue and dim_customers. Both marts feed the semantic layer, where the revenue metric is defined once, and the board, sales and AI all read that metric. The highlighted key path is fct_revenue to the semantic layer to every consumer.Before3 sourcesspreadsheets, prod DB, CSVsBI toolqueries production3 dashboardsthree answers for “revenue”After3 sourcesStripe, HubSpot, app DBstg_ models1:1 with sources, renamedfct_revenue + dim_customersmarts, built by dbt, testedSemantic layermetric: revenue · defined onceBoard · Sales · AIread the metric, same number
Figure 2. The fix isn't more dashboards: it's one tested definition of revenue, in the semantic layer, that every dashboard and AI tool reads.
CriterionHiring a senior analytics engineerConsultancy / fractional
Monthly costSalary, benefits and recruitingFixed fee or monthly plan; varies widely by provider
Time to startMonths (search, notice period, onboarding)Days to weeks once access is set up
Who does the workYour new hireDepends on provider; ask who exactly
CommitmentOngoing employmentFrom one-off projects to month-to-month
Knowledge retentionStays in-houseOnly if code and docs live in your repo

This is a qualitative comparison; your own numbers will vary.

Who owns what: consultancy first, then your first data hireA Gantt-style timeline over about six months. Your company owns the repo, cloud account, data and code from day one, throughout. The consultancy runs the audit in weeks 1 to 2 and the foundation build in weeks 3 to 8, then optional ongoing support. The first data hire starts around week 7, receives a handover at week 8 (docs, runbook and tests), ramps up on a working, tested project and then owns the roadmap. The highlighted key path is the handover into the hire's lane.Week 0Week 4Week 8Week 12Week 16Week 20Your companyowns everythingConsultancybuilds, hands overFirst data hireowns + extendsRepo, cloud account, data and code: yours from day oneAuditFoundation buildOptional: ongoing supportRamps up on a tested project, then owns the roadmaphandover: docs · runbook · testsWho owns what: consultancy first, then your first data hireA Gantt-style timeline over about six months. Your company owns the repo, cloud account, data and code from day one, throughout. The consultancy runs the audit in weeks 1 to 2 and the foundation build in weeks 3 to 8, then optional ongoing support. The first data hire starts around week 7, receives a handover at week 8 (docs, runbook and tests), ramps up on a working, tested project and then owns the roadmap. The highlighted key path is the handover into the hire's lane.Your company, throughout:repo, cloud account, data, codeAuditweeks 1–2 · consultancyFoundation buildweeks 3–8 · consultancyHandoverweek 8 · docs, runbook, testsFirst data hire owns itmonth 2+ · extends the roadmapOptional supportongoing, as needed
Figure 3. You own everything from day one; the consultancy's work ends in a handover the hire can build on, not a dependency.

When hiring first makes sense

When outside help first makes sense

The hybrid most teams end up with

Get a foundation built first (warehouse, tested dbt models, shared metric definitions, one trusted dashboard), then hire someone to own and extend it. Your hire starts on day one with a working, documented project instead of spending months on cleanup.

First data hire: a 30/60/90-day planA Gantt chart over 90 days in three phases: days 1 to 30 foundation, 31 to 60 trust, 61 to 90 ownership. Access and inventory, days 1 to 10. Sources and ingestion, days 6 to 30. dbt models and tests, days 16 to 60. Core metric definitions, days 26 to 55. One trusted dashboard, days 46 to 75, highlighted: it ships only after models are tested and metrics agreed. Docs, runbook and backlog, days 61 to 90, after which the hire owns and extends the project.Days 1–30FoundationDays 31–60TrustDays 61–90OwnershipDay 0Day 15Day 30Day 45Day 60Day 75Day 90Access + inventoryleast privilege, every source1–10Sources + ingestiondeclared, freshness on6–30dbt models + testsstaging → marts, keys tested16–60Core metric definitionsrevenue, MRR, churn: once26–55One trusted dashboardon the shared definitions46–75Docs, runbook, backlogthen the hire owns it61–90First data hire: a 30/60/90-day planA Gantt chart over 90 days in three phases: days 1 to 30 foundation, 31 to 60 trust, 61 to 90 ownership. Access and inventory, days 1 to 10. Sources and ingestion, days 6 to 30. dbt models and tests, days 16 to 60. Core metric definitions, days 26 to 55. One trusted dashboard, days 46 to 75, highlighted: it ships only after models are tested and metrics agreed. Docs, runbook and backlog, days 61 to 90, after which the hire owns and extends the project.Access + inventorydays 1–10Sources + ingestiondays 6–30dbt models + testsdays 16–60Days 1–30 · FoundationCore metric definitionsdays 26–55One trusted dashboarddays 46–75Days 31–60 · TrustDocs, runbook, backlogdays 61–90 · hire owns itDays 61–90 · Ownership
Figure 4. Trust comes before dashboards: the first one ships around day 45–75, on tested models and agreed definitions.

What to insist on, whichever route you pick

  1. All code in your repository and your cloud
  2. Every change shipped as a reviewed pull request, with tests and docs
  3. Written metric definitions your team and BI tools share
  4. Least-privilege, read-only-by-default access, revoked the same day work ends
  5. A runbook a future hire can pick up

Use the 30-point dbt project health checklist to assess what you have today.

How Baked Labs fits

Baked Labs is built for companies that need trustworthy metrics now, before or alongside their first data hire. The usual first step is a fixed-price Data Foundation Audit (7–10 days) that ends in a 90-day roadmap, including a "DIY" option if hiring is the right call.