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.

✓ Check yourself

Answer from memory before opening each one.

1. Compare what makes a warehouse bill run up on BigQuery on-demand versus Snowflake. Name one habit that causes it on each.

   Show answer

   BigQuery on-demand charges for bytes scanned, so SELECT * over an unpartitioned table is the classic cause. Snowflake charges for warehouse running time, so an oversized warehouse left running is. Partition and cluster on BigQuery; size and auto-suspend on Snowflake. See choosing a warehouse.

2. Your sources are Salesforce, the app database and a telemetry stream of five billion events a day. Which do you buy, which do you build, and why does the connector price matter for the stream?

   Show answer

   Buy a managed connector for Salesforce and the app database, because they are solved problems. Own the telemetry pipe, since it is core and bespoke. Fivetran prices by monthly active rows, so a stream that large would cost far more than a direct pipe or a self-managed tool. See ingestion.

3. It is the end of your first week and the founders keep their numbers in spreadsheets. What should you have produced, and what is the output not?

   Show answer

   A list of the decisions they make blind, an inventory of the sources and owners, and one painful question answered quickly, even roughly. The output is not a warehouse or a dashboard yet; those come after you know which numbers matter. See first week.

4. For day 30 you can choose: ten sources loaded, one revenue metric modelled, tested and shown in a dashboard the founders open, or a self-hosted Airflow cluster. Rank them.

   Show answer

   Revenue metric first, because it delivers the trust the role exists for. Loading the two or three sources it needs comes with it. Ten sources adds coverage without trust, and the Airflow cluster adds operations work for one person. See first 30 days.

5. Your CTO wants Kafka and Airflow now because "we will need them eventually". How do you respond without sounding dismissive?

   Show answer

   Agree they may be right later and ask what decision or load would trigger them. Show the plan that defers both and names that trigger. Since dbt makes much of the stack portable, the cost of adding them later is low. See build versus buy.

6. Your 30/60/90 plan is done. Name what you defer at day 90 and how you decide when to stop deferring.

   Show answer

   Defer streaming, ML features and heavy lineage tooling. Revisit each when a named trigger appears: a decision that needs sub-minute data, a model that needs features, or an incident that existing lineage cannot explain. Write the triggers into the backlog. See 60 to 90 days.

Takeaway

• As a team of one, buy undifferentiated work such as connectors, the warehouse, BI and scheduling, and build what is specific to the business: metering models, definitions and reconciliation.
• Pick the warehouse that matches your existing cloud and skills, and set cost controls on day one because each one bills differently.
• dbt is the one tool to be opinionated about: layered, tested and documented models give a solo hire structure.
• The plan is: week one listen, by day 30 one trusted metric, by day 60 a wider tested core, by day 90 durable and self-serve.
• Say what you defer and the trigger that would end the deferral.
• Boring and managed beats clever and fragile when you are the only engineer.

The plan is set; the last chapter rehearses all of it as questions and answers. → Interview Q&A + Day-Of

Further reading

• BigQuery pricing — Google Cloud, 2026. On-demand and capacity models, and what counts as bytes processed.
• Understanding overall cost — Snowflake docs, 2026. Compute, storage and data transfer as separate cost lines.
• Fivetran pricing — Fivetran, 2026. The monthly active rows model that drives the cost lens in the chapter.
• Airbyte documentation — Airbyte, 2026. The open-source alternative and how connectors are run.
• How we structure our dbt projects — dbt Labs docs, 2026. A concrete layout for the transformation layer.
• Assets — Dagster docs, 2026. The asset model behind the orchestration recommendation.
• Metabase documentation — Metabase, 2026. A light BI tool of the kind the chapter suggests early on.