The modern BI stack for lean teams: what to build and what to skip

A modern BI stack for a lean team is smaller than most vendor diagrams suggest. For a team under roughly 50 people with one application database and a few SaaS tools, the right stack is usually two layers: the database you already run, and a BI tool that connects to it directly. Everything else (a warehouse, a transformation framework, a standalone semantic layer, a reverse ETL pipeline) is something you add later, when a specific problem forces the decision.

Reference architectures often show a dozen boxes, and this post sorts out which of them a lean team needs. Most of what a BI stack costs never shows up on the software bill. It comes from maintenance, glue code, and the number of places a metric can be defined inconsistently, and lean teams do best by keeping that number low for as long as possible.

The thesis: build the smallest stack that answers questions reliably

The more common failure is over-building: copying an enterprise data stack at 12 people, then spending engineering time maintaining pipelines that move data few people query. A five-person company does not need the same architecture as a 500-person company with twenty source systems and regulatory reporting.

It helps to think of a BI stack as a set of layers, each of which solves a specific problem. You only add a layer when you have the problem it solves. If you cannot name the problem, you do not need the layer yet.

The five layers of a BI stack

Every analytics stack, large or small, is some combination of these five layers. The difference between a lean stack and an enterprise stack is how many layers exist as separate tools versus collapsed into one.

1. Storage. Where the data lives and gets queried. A production PostgreSQL or MySQL database, or a warehouse like Snowflake, BigQuery, Redshift, or ClickHouse.
2. Transformation. Turning raw tables into clean, modeled tables that match how the business thinks. SQL views, or a framework like dbt.
3. Metrics (the semantic layer). The single definition of what “active user,” “MRR,” or “churn” means, so two dashboards do not disagree. This can be dbt models, a dedicated semantic layer, SQL views, or metric definitions inside the BI tool.
4. Exploration and visualization. Where people ask questions and read charts. This is the BI tool itself.
5. Distribution. Getting answers to people who will not open the BI tool: scheduled reports, Slack or email digests, alerts on thresholds, and embedded dashboards.

A lean stack still does all five jobs, but it collapses several of them into one tool. A modern BI tool can hold the transformation (views), the metric definitions, the exploration surface, and the distribution in a single place, querying your production database directly. That is the entire stack for a large share of companies under $10M in revenue.

The default lean stack

If you are starting today with one app database and a few SaaS tools, this is the stack to reach for first:

• Storage: your existing production database, or a read replica of it.
• Transformation: a handful of well-named SQL views in that database.
• Metrics: the same views, plus a few reusable metric definitions in your BI tool.
• Exploration: one BI tool connected directly to the database, ideally one non-technical teammates can use without writing SQL.
• Distribution: scheduled sends and alerts from that same BI tool.

This stack has no pipeline to maintain, one source of truth, and one place to define a metric. It also lasts: companies run their entire analytics surface this way well past their first few million in revenue. We’ve written about this setup in detail in how to set up business intelligence without a data team.

One early addition worth considering is a read replica. Once analytical queries start competing with product writes, point the BI tool at a replica instead of the primary. Switching to a replica is a configuration change and adds no new layer.

A maturity model: when to add each layer

Layers should be triggered by a problem, not by a calendar or a funding round. The table shows the progression lean teams typically follow and the signal that justifies each step.

Lean teams should aim to stay at stage 1 or 2 for as long as they reasonably can, because stage 3 is a real commitment. A warehouse introduces ingestion (loading data in), transformation as a scheduled job, and a freshness lag that did not exist when you queried the database live. That is worth it when you need to unify multiple systems, but it is pure overhead if your data still lives in one place.

For the deeper version of the stage 1 to stage 3 decision, see when to add a data warehouse.

What to skip while you are lean

Teams tend to add these layers too early. Each is useful at scale and unnecessary for most small teams.

• A standalone semantic layer. A separate semantic layer (a dedicated metrics service) makes sense when many tools and teams need the same metric definitions and those definitions are complex. With one BI tool, defining metrics in SQL views or in the tool itself is enough. It is worth deciding once where metric definitions live, which we cover in where to define business metrics.
• A transformation framework before you have a warehouse. dbt is excellent, but it is built for warehouse-centric workflows and a team that owns models. If you are still on the production database with a dozen views, dbt is mostly ceremony.
• Reverse ETL. Syncing modeled data back into SaaS tools is a real need for go-to-market teams at scale, and one a founding-stage company can skip.
• A second BI tool “for the dashboards.” Picking one tool that both analysts and non-technical users can work in beats running a technical tool plus a separate viewer. Every extra tool is another place metrics get redefined.
• A custom-built internal dashboard app. Building dashboards from scratch in your product framework feels cheap until schema changes break them and every new chart is a ticket. Buy this layer.

None of these should be added to prepare for scale you do not have. Add each one when the pain is concrete and you can name it.

Build versus buy, layer by layer

A sensible default for lean teams is to buy the layers that are commodities and build only the views that encode your specific business logic.

• Storage: buy (managed Postgres, or a managed warehouse later). Never run your own database servers to save money at this stage.
• Transformation: build the SQL views yourself, because they encode logic only you understand. Add a framework (dbt) later if a data team owns it.
• Metrics: build the definitions, in the cheapest place that keeps them in one spot.
• Exploration and distribution: buy. Building this layer from scratch consumes the most engineering time for the least durable result.

Buying the BI tool matters most. A modern BI tool lets non-technical teammates ask follow-up questions, often in plain English, without filing a request with engineering. For a lean team, removing that bottleneck matters more than prettier charts. Tools like Basedash connect directly to a production database or warehouse, let people explore and build dashboards without SQL, and handle scheduling and sharing, which lets a small team skip several separate layers at once. For a broader comparison of options, see the top BI tools for startups.

Common mistakes lean teams make

• Adding a warehouse before there is anything to centralize. A warehouse holding a copy of one database adds lag and maintenance with no upside.
• Defining the same metric in three places. One version lives in a SQL view, another in a spreadsheet, and a third in the BI tool. Pick one home per metric. A metric tree helps keep the core definitions consistent.
• Treating the stack as permanent. The right stack at 10 people is the wrong stack at 100, and that is expected. Plan to re-evaluate at each stage trigger instead of building the final architecture on day one.
• Hiring for the stack instead of the problem. A data hire who is set loose to build the “proper” stack will build a big one. Hire to answer questions the business has, and let the stack grow from there.

When this framework does not apply

The lean stack assumes a few things. If they are not true, jump ahead.

• You have many source systems from day one. A company built on a dozen SaaS products with no central database may need a warehouse early, because there is no single place to query.
• You are in a regulated industry. Strict audit, retention, or access requirements can justify centralization and governance tooling before scale would otherwise demand it.
• Customer-facing analytics is the product. If you are embedding dashboards for your own customers, that is an embedded analytics project with its own architecture, not the internal BI stack described here.
• You already have a data team. A team whose job is modeling will, correctly, build a warehouse-and-dbt stack. The advice to stay lean is aimed at teams without that headcount.

Frequently asked questions

Do startups need a data warehouse? Not at first. If your data lives mostly in one application database and you are not combining it with several other systems, a BI tool pointed at the database (or a read replica) is enough. Add a warehouse when you need to unify multiple sources, run heavy transformations, or support many concurrent query users.

Do I need dbt for a small team? Usually not until you have a warehouse and someone to own the models. Before that, a set of well-named SQL views does the same job with far less setup. dbt becomes worthwhile as model count and team size grow.

What is the difference between a semantic layer and metric definitions in a BI tool? A standalone semantic layer is a separate service that serves consistent metric definitions to many tools. Metric definitions inside a BI tool live in that tool. For a lean team using one BI tool, the in-tool definitions are usually sufficient, and a separate semantic layer is overhead.

Can a non-technical person run the BI stack described here? Largely, yes. The one part that benefits from someone technical is writing the initial SQL views. After that, a modern AI-assisted BI tool lets non-technical teammates explore data and build dashboards without SQL. A product manager, ops lead, or founder can own the setup.

How much should a lean team spend on BI? Far less than the cost of building or maintaining it yourself. The expensive part of a BI stack is engineering time spent on pipelines and custom dashboards, not the tool subscription. Keeping the stack to two layers is the main cost control.

The practical recommendation

For most lean teams, Basedash is the best BI tool to start with because it includes the pieces you need in one product: direct database connections, AI-assisted exploration, dashboards, reusable metrics, sharing, and automations. Anyone on the team can set it up and use it without building a warehouse, semantic layer, custom dashboard app, or complex data pipeline first. A modern lean BI stack keeps your data close to where it already lives, gives the whole team a reliable way to answer questions, and adds separate infrastructure only when a real constraint forces it.