Stack Decisions & 30/60/90

Build vs buy as employee-zero

The instinct that separates a good first hire from one who builds an unmaintainable pile in six months:

• Buy the undifferentiated heavy lifting: ingestion connectors, the warehouse itself, BI rendering, scheduling. Maintaining a Salesforce connector is not why they hired you.
• Build what's specific to the business: the metering/usage models, the metric definitions, the reconciliation logic, the data model. That's your value and nobody can buy it off the shelf.
• Managed over self-hosted by default when you're one person — you can't be on-call for your own Airflow cluster and also ship models. Re-evaluate when scale or cost forces it.
• Avoid resume-driven architecture. Kafka + a lakehouse + a feature store for a company with three data sources is a red flag, not a flex.

Choosing a warehouse

Have a default and the reasons. The honest interview answer is "any of the big three is fine; here's how I'd decide."

First-hire framing: "I'd pick the warehouse that matches their existing cloud and team familiarity — usually Snowflake or BigQuery. The decision is reversible-ish via dbt portability, so I wouldn't over-deliberate; I'd optimize for getting to trusted metrics fast." Mention cost control upfront — it's a usage-based business, they'll respect cost awareness.

Ingestion

• Managed connectors (Fivetran / Airbyte) for standard sources (app DB, Stripe, Salesforce). Buy this — it's solved.
• CDC for the app DB if you need updates/deletes captured reliably (chapter 04).
• Custom only for the differentiated, high-volume telemetry/metering stream — that's worth owning because it's core and bespoke.
• Cost lens: Fivetran prices on rows; for very high-volume sources, Airbyte/self-managed or a direct pipe may be cheaper. Know the tradeoff.

Transformation & BI

• Transformation: dbt, near-universally. Versioned SQL, tests, docs, lineage, layered models — it gives a solo hire structure and a paper trail for free. This is the one tool to be opinionated about.
• BI: meet people where they are. A lightweight tool (Metabase, Lightdash, Looker Studio) early; heavier (Looker, Tableau) when modeling and governance demand it. Don't let tool choice block delivering the first trusted dashboard.
• Orchestration: start with dbt Cloud's scheduler or Dagster; defer Airflow until DAG complexity earns it (chapter 04).

A defensible starter stack

Not the only answer — a defensible one you can justify line by line:

Ingest:        Fivetran/Airbyte (standard sources) + custom pipe (telemetry)
Warehouse:     Snowflake or BigQuery (match their cloud)
Transform:     dbt (staging / intermediate / marts, tested + documented)
Orchestrate:   dbt Cloud scheduler or Dagster (no Airflow yet)
Quality:       dbt tests + source freshness + Elementary (anomalies)
BI:            Metabase / Lightdash early
Total ops burden for one person: low — which is the point.

The meta-point to state: "This is intentionally boring and managed. As one person, boring-and-reliable beats clever-and-fragile. I'd add complexity only when a real need pulls it in."

First week — listen before you build

• Stakeholder discovery: talk to founders/leads. What decisions are they making blind? What numbers do they re-check in spreadsheets today? Those spreadsheets are your roadmap.
• Inventory sources: what systems exist, who owns them, how to access them.
• Find the one painful, high-value question you can answer fastest, and answer it — even crudely — to build credibility in week one.

First 30 days — centralize + one trusted metric

• Stand up the warehouse and managed ingestion for the 2-3 most important sources.
• Initialize dbt with the layer structure and conventions (chapter 06).
• Model one end-to-end metric leadership cares about (likely revenue or utilization), tested and documented, in a dashboard they'll actually open.
• Outcome: a single number leadership trusts and stops re-checking. Trust beachhead established.

30–60 days — expand the trusted core

• Add the next 3-5 core metrics (active customers, retention, gross margin, fill rate).
• Add freshness/volume/uniqueness tests and the metering↔billing reconciliation.
• Establish the metrics layer / canonical definitions so words mean one thing.
• Set up basic alerting so you find breaks before stakeholders.

60–90 days — make it durable & self-serve

• Documentation and a light data catalog (dbt docs/exposures) so the company isn't hostage to your memory.
• Enable self-serve for common questions so you're not a query bottleneck.
• Lineage/observability proportional to the stack (start with dbt's graph + Elementary).
• A prioritized backlog and a written POV on what's next (streaming? ML features? data hire #2?) — and what you'd not do yet, and why.

Presenting the plan in the loop

If asked for your 30/60/90, deliver it as a story with a spine, not a feature list:

1. Principle first: "I optimize for trust and my own time as a team of one."
2. Listen → centralize → one trusted metric → expand → durability. Name the sequence and why it's ordered that way.
3. Concrete first deliverable: "By day 30, revenue is in a dashboard the founders trust enough to stop maintaining their spreadsheet."
4. What you'd deliberately defer (streaming, ML, heavy tooling) and the trigger that would change that.
5. How you'd measure success: trust earned, decisions enabled, time-to-answer dropping, you finding issues before others.