Why your data stack should be boring

Every early-stage team hits the same wall, usually somewhere between the seed round and the Series A board deck: revenue in the deck doesn’t match revenue in Stripe, activation is defined three different ways in three different dashboards, and the one script that held it all together was written by an engineer who left in March. Nobody is lying. The numbers are just built on sand.

The instinct at that moment is to buy something big — a warehouse, a BI platform, maybe a data hire. Most of the time that’s the wrong move, or at least the wrong first move. What you actually need is a small, boring, operated pipeline. Here is what that means concretely.

The trust problem is a process problem

Dashboards rot for predictable reasons, and none of them are about scale:

• Metrics live in chart configs. When “active user” is defined inside a Metabase query, a Mixpanel report, and a founder’s spreadsheet, they will drift apart. There is no single definition to be right or wrong.
• Ingestion is a cron job someone wrote once. It doesn’t alert when the source API adds a field, silently duplicates rows on retry, and nobody notices until a chart looks weird two weeks later.
• Nothing is tested. Application code gets a CI suite; the SQL that computes the number your board sees gets pasted into a console. Bad data doesn’t throw exceptions — it just looks plausible.

Notice that none of this is fixed by a bigger warehouse or a prettier BI tool. It’s fixed by treating the pipeline like production software: version control, tests, alerts, and one place where each metric is defined.

Most startups have small data

Under a few hundred gigabytes — which describes almost every company before Series B — you do not need Snowflake, Spark, or a platform team. A single-node engine like DuckDB will scan your entire history in seconds, and the money conversation changes completely: the stack below runs on roughly $100–300 a month of compute, against the $180k+ fully-loaded cost of the data engineer you were about to hire to babysit something heavier.

Our default build is deliberately unexciting, and every piece is open-source or near-free at startup scale:

• Ingestion with managed connectors (Airbyte or dlt) pulling your product database, Stripe, and the handful of SaaS tools that matter — on a visible schedule, with retries and schema-change detection instead of a silent cron.
• Storage and compute in DuckDB over object storage (or your existing Postgres, if that’s honestly enough). Columnar, fast, and cheap enough that you stop thinking about it.
• Modeling in dbt: every metric is a version-controlled SQL model with an owner, a description, and a git history. When someone asks “why did activation change,” the answer is a diff, not an argument.
• Orchestration in Dagster, so “did last night’s run succeed” is a page you can open, not a feeling.

What “tested” actually means for data

Data tests are cheap to write and catch the failures that actually happen:

• Shape tests — primary keys are unique and not null; a join didn’t silently fan out and double your revenue.
• Domain tests — status is one of the values your code can produce; currency amounts are never negative unless they’re refunds.
• Freshness SLAs — orders landed in the last 6 hours, or someone gets paged before the CEO opens the dashboard, not after.
• Reconciliation — the pipeline’s monthly revenue agrees with Stripe’s own reporting to within rounding. One query, run daily, ends an entire class of board-meeting surprises.

When a test fails, the run stops and the alert says which model and which assertion. That is the whole trick: bad data gets caught upstream of the chart, while it’s still an engineering ticket instead of a credibility problem.

When you don’t need any of this

Honesty matters more than a project fee: if you’re pre-product-market-fit, your questions are simple, and your data fits in Postgres, then a read replica and a lightweight BI tool are the correct stack. The signals that you’ve outgrown it are specific:

• Two dashboards disagree on a number that matters, and it takes days to find out why.
• Answering “which channel produces customers who retain” requires joining product, billing, and marketing data by hand in a spreadsheet.
• Analytics queries are slowing down the production database.
• An investor or enterprise customer asks for a metric you can’t reproduce two quarters in a row.

The part nobody budgets for: operations

A pipeline is not a project; it’s a small production system. Source APIs change fields. A connector update breaks a sync. A backfill needs to run without double-counting. Someone has to glance at the freshness dashboard in the morning and own the fix when it’s red. That ongoing operation — not the initial build — is where most in-house data efforts quietly die, because it’s nobody’s job.

It’s our job. We build the stack above in a few weeks, then run it on retainer: monitoring, break-fix, backfills, and a steady stream of new models and metrics as your questions evolve. Your engineers keep shipping product; your numbers stay boring. That’s the goal.