TL;DR
You can have a working data stack in a single afternoon using three layers: a cloud warehouse to store raw data, a transformation tool to clean it, and a visualization layer to read it. The right combination for most early-stage startups in 2026 is BigQuery, dbt, and Looker Studio. Total cost for the first several months is often zero dollars if your data volume stays under a few million rows per month.
What You Need Before You Start
- A Google Cloud account with billing enabled (BigQuery free tier: 10 GB storage, 1 TB query/month at no charge)
- Your top five to ten business questions written down before touching any tool
- Basic SQL skills: SELECT, JOIN, GROUP BY, and WHERE
- dbt Core 1.8+ installed locally (
pip install dbt-bigquery==1.8.0) or a free dbt Cloud developer account - An Airbyte Cloud account (free tier covers most early-stage sync volumes) or a Fivetran free trial (14 days, 500K monthly active rows free after)
- A Google account for Looker Studio (completely free) or a Metabase Cloud trial (14 days free)
- Optional: a rough count of monthly rows per data source, which you can usually get from each tool’s admin panel
- Optional: a GitHub account if you plan to automate dbt runs via Actions (2,000 free minutes per month on private repos)
Step 1: Write Down the Questions You Actually Need to Answer
Before opening any tool, write five to ten specific business questions in plain text. Not “how is the business doing” but rather “what is the 30-day retention rate for users who signed up through paid ads vs. organic?” or “which pricing plan generates the most support tickets?”
The questions you write here determine every decision that follows: which sources to connect, which fields to transform, which metrics to expose in dashboards. Founders who skip this step build a stack that collects everything and answers nothing.
Open a Notion page, a Google Doc, or even a plain text file. Write each question on its own line. Group them by domain: product, revenue, marketing, support. Each group will become a set of source connectors and dbt models later.
Do not move to Step 2 until you have at least five questions written with a data source named next to each one.
You should now see a short, grouped list of specific questions with at least one named data source per group.
Step 2: Audit Every Data Source You Currently Have
Map every system that holds data you need to answer those questions. For each source, record three things: the tool name, how you can export or stream data out of it, and a rough monthly row estimate.
A typical early-stage SaaS startup has:
– Stripe for payment and subscription data
– A Postgres or MySQL application database
– Google Analytics 4 or Amplitude for product events
– HubSpot, Pipedrive, or a spreadsheet for pipeline data
Build a simple three-column table:
| Source | Export Method | Est. Rows/Month |
|-------------|----------------------|-----------------|
| Stripe | API / Airbyte | 5,000 |
| App DB | Postgres replica | 200,000 |
| GA4 | BigQuery native link | 50,000 |
| HubSpot | API / Airbyte | 2,000 |
If your total monthly rows are under two million, a free or near-free warehouse tier will handle you comfortably for the next 12 months. If a source has no export method listed, find one before you go any further.
You should now see a complete audit table with no blank cells in the Export Method column.
Step 3: Pick Your Data Warehouse
Your warehouse is where raw data from every source lands before any transformation happens. Three options cover almost every early-stage scenario in 2026:
BigQuery: The default choice if your team uses Google Workspace. Free tier gives you 10 GB of storage and 1 TB of query processing per month. Zero infrastructure to manage. Native integration with GA4, Looker Studio, and Vertex AI.
DuckDB: Best if you want to run everything locally or on a single server with no cloud costs at all. Handles hundreds of millions of rows on a laptop. Fully open source.
Snowflake: Best if you anticipate rapid data growth or need strong multi-team access controls from early on. Starts around $25 per month for a small warehouse.
For most startups with under 50 GB of data, BigQuery wins on cost and simplicity.
Go to console.cloud.google.com, create a new project, enable the BigQuery API under APIs and Services, navigate to BigQuery Studio, and create a dataset named raw_data in the region closest to your users.
You should now see an empty raw_data dataset listed in the BigQuery Studio left panel.
Step 4: Set Up Your Ingestion Pipeline
Ingestion moves data from your sources into the warehouse automatically. Set up your first connector in Airbyte Cloud:
Log in to Airbyte Cloud, click “New Connection,” select Stripe as the source, enter your Stripe secret key, then select BigQuery as the destination. Point the destination dataset to raw_data. Configure the sync like this:
Source: Stripe
Destination: BigQuery (raw_data dataset)
Sync Frequency: Every 6 hours
Normalization: Raw JSON (let dbt handle transformations)
Full Refresh Tables: stripe_customers, stripe_products
Incremental Tables: stripe_charges, stripe_invoices
Click “Save and Test.” Airbyte will validate both connections. Once the test passes, trigger the first sync manually by clicking “Sync Now.”
If you prefer Fivetran, the setup path is near-identical: Sources > Add Connector > Stripe > BigQuery destination > same dataset name.
You should now see raw Stripe tables like raw_data.stripe_charges and raw_data.stripe_customers in BigQuery with real row counts.
Step 5: Transform Your Data With dbt
Raw tables from Airbyte are messy. Column names use snake_case inconsistently, amounts are in cents rather than dollars, and joining Stripe customers to your app database requires careful key logic. dbt handles all of this in version-controlled SQL.
If you are new to dbt, see the beginner’s guide to dbt for startup analysts before continuing.
Initialize a project:
pip install dbt-bigquery==1.8.0
dbt init my_startup_project
Configure ~/.dbt/profiles.yml to point at your BigQuery project, then create your first mart model:
-- models/marts/revenue_monthly.sql
select
date_trunc(created, month) as month,
sum(amount) / 100.0 as revenue_usd,
count(distinct customer) as paying_customers
from {{ ref('stripe_charges') }}
where status = 'succeeded'
group by 1
order by 1
Run dbt run from the project root. dbt compiles the SQL and writes results to a new table in BigQuery.
You should now see a revenue_monthly table in your BigQuery dataset with clean monthly figures, no cents, no nulls.
Step 6: Add a Visualization Layer
Non-technical teammates should not need to write SQL to check revenue or retention. Connect Looker Studio to your BigQuery mart tables.
Go to lookerstudio.google.com, click Create, select Data Source, choose BigQuery, pick your GCP project, then select the revenue_monthly table. Click Connect. Build a time-series chart with month on the X axis and revenue_usd as the metric.
If you want more flexibility, including drill-downs, click-to-filter dashboards, and a question-and-answer interface for non-SQL users, Metabase is worth the setup time. It connects to BigQuery via a JDBC driver and gives you a point-and-click query builder.
For a detailed comparison of both tools with screenshots, see the best BI tools for startups guide on this site.
You should now see a live Looker Studio chart that reflects real Stripe data with a lag of no more than six hours.
Step 7: Automate Your dbt Runs
Running dbt run manually works for development but not for a production stack. You need a schedule that fires automatically after each Airbyte sync completes.
The simplest option at this stage is a GitHub Actions workflow on a cron schedule:
# .github/workflows/dbt_run.yml
name: dbt scheduled run
on:
schedule:
- cron: '0 */6 * * *'
jobs:
dbt:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dbt
run: pip install dbt-bigquery==1.8.0
- name: Run dbt
run: dbt run --profiles-dir .
env:
DBT_BIGQUERY_KEYFILE: ${{ secrets.GCP_KEYFILE }}
Store your BigQuery service account JSON as a GitHub Actions secret named GCP_KEYFILE. Commit the workflow file and push to your repo.
If you prefer a UI-based scheduler, the free dbt Cloud developer plan lets you set scheduled jobs with no YAML required.
You should now see green checkmarks in the GitHub Actions tab every six hours, confirming dbt ran without errors.
Step 8: Add Data Quality Tests
A stack with no tests is a stack you cannot trust. dbt ships a built-in test runner that catches nulls, duplicates, and broken relationships before they reach your dashboards.
Create a schema file alongside your models:
# models/marts/schema.yml
version: 2
models:
- name: revenue_monthly
columns:
- name: month
tests:
- not_null
- unique
- name: revenue_usd
tests:
- not_null
- name: paying_customers
tests:
- not_null
Add dbt test as a step in your GitHub Actions workflow, immediately after dbt run. If any test fails, the workflow stops and GitHub sends you an email before bad data reaches Looker Studio.
You should now see dbt test output showing “Finished running N tests” with every test status listed as PASS.
Step 9: Write a Minimal Data Dictionary
The definition of “active user” will mean different things to your head of product and your head of sales. The data dictionary is where you resolve that conflict once and store the answer in version control.
Create a docs/ folder in your dbt project and add one markdown file per mart model:
## revenue_monthly
- Definition: sum of successful Stripe charges per calendar month,
converted from cents to USD
- Source: stripe_charges table via Airbyte (syncs every 6 hours)
- Grain: one row per calendar month
- Key metric: revenue_usd (excludes refunded and disputed charges)
- Owner: @founder / data team
- Last reviewed: 2026-05-01
Commit this file with your models. Future team members, including contractors and new hires, can answer most metric definition questions without pinging you directly.
You should now see a docs/ folder in your repo with at least one markdown file per mart model, committed and pushed.
Common Mistakes To Avoid
- Connecting every data source on day one. Start with two or three sources that directly answer your top questions. Adding a new connector takes 20 minutes. Maintaining a connector nobody queries takes ongoing attention every time the source API changes.
- Querying raw tables directly in your BI tool. If you define “monthly revenue” inside a Looker Studio calculated field instead of a dbt model, that definition will drift across every dashboard that uses the same metric.
- Choosing Snowflake before you need it. Snowflake is excellent, but its minimum compute cost is real and ongoing. If your data is under 10 GB and your team is fewer than five people, BigQuery’s free tier does the same job.
- Skipping data quality tests. A failed Airbyte sync that produces zero rows will still update your dashboard to show $0 revenue unless a dbt test catches the empty table.
- Hardcoding credentials in code. Store all API keys, database passwords, and service account files in environment variables or a secrets manager. Rotating a leaked key is a painful afternoon that is easy to avoid.
- Setting sync frequency based on what feels right rather than actual reporting needs. Six-hour or daily syncs are right for most early-stage use cases. Real-time ingestion is expensive and almost never necessary before you hit Series A.
When To Level Up
The stack described above handles around 50 million events per month comfortably, supports a team of up to 15 people querying data, and manages a few dozen dbt models without issue.
It starts to show cracks when BigQuery query costs climb above $100 per month because analysts are running unoptimized exploratory queries. It also struggles when you have more than three people writing dbt models without a proper CI/CD review process, when stakeholders ask for real-time dashboards rather than six-hour refreshes, or when you need to run machine learning pipelines on the same data.
At that point, you should evaluate a proper orchestration tool like Dagster or Prefect to manage pipeline dependencies, a Redshift Serverless or Snowflake contract with predictable compute costs, and a semantic layer like dbt Semantic Layer or Cube to enforce metric definitions across multiple BI tools.
For a full breakdown of the tools available at that next scale, browse the data skills resource library and the comparison of data warehouse options for growing startups.
Frequently Asked Questions
Do I need a data engineer to set this up?
No. A technical founder with working SQL skills can complete all nine steps in a single day using the tools above. Airbyte Cloud and dbt Cloud are both designed for small teams without dedicated data engineering headcount. You do need someone who can read error logs and write SQL joins.
How much does this stack cost per month?
For a startup under two million rows per month, the total bill is often between zero and $50. BigQuery free tier, Airbyte Cloud free tier, dbt Core self-hosted, and Looker Studio are all free. Metabase Cloud is the only paid option in this stack, at $500 per month, and you can replace it with Looker Studio to keep costs at zero.
Should I use a lakehouse like Databricks instead of BigQuery?
Not at this stage. Databricks is powerful but adds significant infrastructure complexity and cost. It makes sense when you have unstructured data, active machine learning pipelines, or more than 100 GB of data flowing daily. Start with the simpler option and migrate when the limitations become real, not hypothetical.
How do I handle personally identifiable information (PII) in the warehouse?
Apply column-level masking policies in BigQuery before raw tables reach your dbt transformation layer. Keep email addresses, names, and payment details out of mart models entirely where possible. Getting this right on day one is far easier than retrofitting it after a security review or a GDPR request.
What if my primary data source is still a spreadsheet?
That is a perfectly valid starting point. Both Airbyte and Fivetran have Google Sheets connectors. Load the sheet into your warehouse as a source table, use dbt to normalize and join it with other sources, then replace the spreadsheet with a proper system when your volume or team size makes manual updates impractical.
Bottom Line
Choosing a data stack at an early-stage startup in 2026 is less about picking the most powerful tools and more about picking the smallest set that answers your actual business questions without requiring a dedicated data team to maintain. The nine steps above walk you through mapping your questions, auditing your sources, connecting a warehouse, building a transformation layer, adding a dashboard, automating the pipeline, adding tests, and documenting your decisions. Each step has a concrete sanity check so you always know whether it is working. The entire setup runs on free tiers for months. When this stack eventually shows its limits, you will understand it well enough to upgrade one layer at a time without starting over. For everything that comes next, explore the full data skills resource library at /category/data-skills/.