At $1M ARR, most analytics stacks are “good enough.” At $10M, they start creaking. At $50M, they become the reason your data team can’t sleep.
This isn’t a failure of tools—it’s a failure of architectural assumptions made early that were never revisited. Here’s what we’ve learned from watching companies hit those inflection points.
The Three-Layer Problem
A mature analytics stack needs three distinct layers, and most early-stage companies collapse them into one:
- Ingestion: Getting data in
- Transformation: Making data useful
- Serving: Getting data out
When you’re small, this might all be “a Postgres database with some SQL views.” That works fine. The problem comes when each layer needs to scale differently—and you’ve built them as one monolithic system.
Ingestion: Your Foundation Is Your Ceiling
The single most costly mistake I see is building custom ingestion pipelines for every data source.
Your team writes a Salesforce sync. Then a Stripe sync. Then a custom event tracker. Each one has slightly different error handling, retry logic, and monitoring. When something breaks at 2am, you’re debugging artisanal code you barely remember writing.
The rule: use commodity ingestion for commodity sources. Tools like Fivetran, Airbyte, or—yes—Nexus’s native connectors exist specifically so you’re not maintaining a Salesforce API wrapper. The engineering time you save compounds across every hire you make.
Reserve custom ingestion for sources that are genuinely proprietary: your production database, your mobile event stream, your internal tools.
Transformation: dbt or Chaos
If you’re not using a transformation layer with version control, column-level lineage, and automated testing, you don’t have a data warehouse—you have a pile of tables held together by institutional knowledge.
dbt has won this layer for most teams, and for good reason. SQL as code. Documentation that lives next to the logic. Tests that run before anything hits production.
The mistake teams make is when they adopt it. I’ve seen companies try to bolt dbt on after two years of undocumented SQL views. That migration is painful. The calcification is real.
The right time to add a transformation layer is before your analytics queries get complex. Usually around the time your second analyst joins, or when you start having “whose numbers are right?” conversations.
Serving: Match the Tool to the Audience
Your CEO and your data scientist have fundamentally different needs from the same underlying data. Trying to serve both from a single BI tool is the fastest way to end up with a tool neither of them actually uses.
I broadly recommend three tiers:
-
Executive layer: Live dashboards. KPIs. Minimal filtering. Clear period-over-period comparison. Zero SQL required.
-
Operational layer: Team-specific views. Configurable filters. Automated alerts. Where analysts spend most of their time.
-
Exploration layer: Full query access. Notebook-style investigation. Where your data scientists live.
Most BI tools try to be all three and end up as none of them. Be explicit about which tool serves which audience—and accept that you might need two.
The Mistake That Kills Roadmaps
The biggest architectural antipattern I see: treating your analytics stack as a reporting system rather than a platform.
A reporting system serves today’s questions. A platform makes it cheap to answer questions you haven’t been asked yet.
The distinction matters because one of them has a roadmap and one of them is permanently reactive.
Building a platform means standardizing event naming conventions before you have event data. It means building a semantic layer before your analysts have time to appreciate it. It means doing architecture work that shows no visible output for weeks.
That’s uncomfortable. It’s also the only way to stay ahead of growth instead of chasing it.
What Good Looks Like
After working with 200+ analytics stacks across industries, the healthiest ones share a few properties:
- New data sources can be added without touching existing pipelines
- Any metric can be traced back to a raw source in under 10 minutes
- Every critical metric has an automated test that fails before users notice a problem
- The stack can be explained to a new engineer in one hour
If any of those feel aspirational rather than current, you’re not alone. They’re achievable—but only if you treat them as engineering requirements, not nice-to-haves.
Your data infrastructure is as strategic as your product infrastructure. It’s just easier to neglect, until it isn’t.