There's a genre of architecture diagram that haunts startup engineering channels: warehouse, ingestion pipelines, transformation layer, orchestrator, BI tool, reverse-ETL — a beautiful "modern data stack" recommended to companies with forty customers. It's the data equivalent of buying a semi-truck to deliver one pizza.

Here's the stage-by-stage version instead: the minimum that works at each phase, the concrete triggers that tell you to upgrade, and the traps at every step.

Stage 0 — Pre-launch to first customers: tools' own dashboards + one spreadsheet

Stack: Stripe's dashboard for revenue, GA4 for traffic, your database for user counts, and a single spreadsheet where, once a week, a founder types 8–10 numbers by hand.

That manual step is a feature, not a hack. Typing the numbers forces you to look at them; the spreadsheet becomes your metric history and your definitions document at once. Weekly rows, monthly cohort tab, nothing else.

Trap at this stage: building anything. Every hour on data plumbing is an hour not spent finding product-market fit, and your event schema will be obsolete in two pivots anyway.

Upgrade trigger: questions that require joining sources ("do users from this channel retain?") come up weekly and go unanswered.

Stage 1 — Early traction: instrumented events + a growth dashboard

Stack: deliberate product event tracking (a lean taxonomy of 10–20 events), GA4 configured properly for your funnel, Stripe as revenue truth, and a dashboard layer that joins acquisition and revenue views — bought, not built.

The decision that matters here isn't a tool; it's the tracking plan: a one-page document listing each event, when it fires, its properties, and its owner. Teams that skip this spend Stage 2 doing archaeology on their own data ("what does 'session_new2' mean and why did it stop firing in March?").

Buy vs. build: at this stage, building dashboards in-house costs weeks and rots instantly. A product analytics tool or a founder-focused cockpit covers 90% of questions for the price of a lunch per month.

Traps: tracking everything "just in case" (200 events, none trusted); three tools each computing MRR slightly differently (crown Stripe-derived data as the single truth and make every other tool defer to it).

Upgrade trigger: you have real revenue, more than ~10k users' worth of events, and recurring questions that pre-built tools can't answer — genuinely custom joins across product, billing, and support data.

Stage 2 — Growth: the small warehouse

Stack: a cloud warehouse (pick any major one; at startup volumes they're equivalent and nearly free), managed ingestion connectors for Stripe / product events / CRM, SQL transformations with a lightweight framework, and a BI tool on top.

What changes philosophically: the warehouse becomes the single place where definitions live. "Active user," "MRR," "churned" get defined once, in version-controlled SQL, instead of re-implemented in every tool's UI.

Cost reality check (illustrative): a seed/A-stage company typically lands at a few hundred dollars a month across warehouse and connectors — the expensive part is the human. Which leads to the real trigger:

Don't build Stage 2 without an owner. A warehouse without someone responsible for it (a data-inclined engineer at 20% time is enough initially) becomes a swamp: broken pipelines, stale dashboards, and less trust in data than you had with the spreadsheet.

Traps: modeling everything before answering anything (start with the 5 tables that answer this quarter's questions); dashboard sprawl (every ad-hoc query becomes a permanent chart nobody reads); real-time pipelines nobody asked for (daily refresh is fine for almost every startup decision).

Stage 3 — Scale: the full stack, added on demand

Orchestration, data quality testing, reverse-ETL back into sales and marketing tools, maybe streaming for product features, a real data team. Each piece gets added when a specific pain justifies it — never as a package. If you're reading a startup blog for this stage, hire someone who's done it.

Who runs this, at each stage

Tools are the visible half of the stack; the invisible half is ownership, and it's where most failures happen.

Stage 0–1: a founder owns the numbers. Not "the technical co-founder owns the pipeline" — a founder owns the weekly reading and the definitions. Delegating attention this early means nobody's watching.
Stage 1–2 transition: the accidental data person emerges. Usually an engineer or ops hire who likes queries. Make it official at ~20% of their time, with a one-line mandate: keep the numbers trustworthy. Unofficial ownership evaporates under sprint pressure.
Stage 2: first deliberate data hire — typically a pragmatic analytics engineer who can own pipelines and talk to the business, rather than a specialist on either extreme. One good generalist here outperforms two specialists arguing about tooling.
At every stage: the consumers of data — founders, sales, product — retain responsibility for acting on it. A data owner keeps numbers correct; they can't make anyone look.

A quiet test of stack health, whatever the stage: ask three people "what was activation last month?" If you get three numbers, fix ownership and definitions before buying anything else.

The upgrade triggers, condensed

Symptom	It's time for
Cross-source questions weekly, unanswered	Stage 1: events + joined dashboard
Numbers differ between tools and meetings	A declared source of truth + definitions doc
Reporting eats > half a day/week of someone's time	Automation of exactly that report
Pre-built tools can't express your recurring questions	Stage 2: warehouse
Warehouse exists, nobody trusts it	Not a tool — an owner
Ops teams re-export the same lists weekly	Reverse-ETL, Stage 3

The pattern behind all of them: upgrade when a named, recurring pain costs more than the infrastructure — never because a diagram looked professional.

Knowing when the spreadsheet is genuinely done

Founders often feel embarrassed about the spreadsheet phase and upgrade out of shame rather than need. The spreadsheet is genuinely done when one of three things happens: the manual entry gets skipped two weeks in a row (attention has outgrown the ritual), a wrong decision traces back to a copy-paste error (stakes have outgrown the medium), or the questions you care about require row-level joins the sheet can't express (complexity has outgrown the tool). Until one of those occurs, the spreadsheet isn't technical debt — it's the correct architecture for your stage, and the discipline it enforces is worth more than any pipeline.

Principles that hold at every stage

Billing data is sacred. Whatever the stack, revenue numbers trace back to Stripe with no manual steps in between.
Definitions are the asset. Tools are replaceable; the agreed meaning of "active," "activated," and "churned" is what compounds. Write them down at Stage 0 and carry them forward.
Fewer numbers, more looked-at. A stack's value is measured in decisions changed per month, not rows ingested.
Every layer needs an owner or it decays. Unowned data infrastructure doesn't stay neutral; it rots and misleads.

The bottom line

The minimal viable data stack is almost embarrassingly small: tool dashboards and a spreadsheet, then a tracking plan and a joined dashboard, then — only when named pains demand it — a small, owned warehouse. Each stage earns the next.

Growth Pilot is built to be that Stage 1 layer: GA4 and Stripe joined into one AAARRR cockpit with consistent definitions, so you can defer the warehouse until your questions — not your diagrams — require one.