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.

This post is for founders, first data hires, and operators who keep seeing reference architectures with a dozen boxes and want to know which boxes they actually need. The argument is simple: the cost of a BI stack is not the software bill. It is the maintenance, the glue code, and the number of places a metric can be defined inconsistently. Lean teams win by keeping that count low for as long as possible.

The thesis: build the smallest stack that answers questions reliably

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

The useful way to think about a BI stack is 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 does not delete any of these jobs. 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 is not a stopgap. 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.

The one early addition worth considering is a read replica. The moment analytical queries start competing with product writes, point the BI tool at a replica instead of the primary. It is a configuration change, not a 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. Here is the progression most lean teams actually follow, and the signal that justifies each step.

The key insight: most lean teams should aim to sit at stage 1 or 2 as long as honestly possible. 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

These are the layers teams add too early. Each is genuinely useful at scale and genuinely unnecessary for most small teams.

• A standalone semantic layer. A separate semantic layer (a dedicated metrics service) earns its keep 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. The question of where to put metric definitions is worth thinking through once, 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. It is not a founding-stage layer.
• 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.

The pattern across all of these: do not add a layer to prepare for scale you do not have. Add it when the pain is concrete and named.

Build versus buy, layer by layer

A useful default for lean teams: buy the layers that are commodities, 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. This is the layer where building from scratch quietly consumes the most engineering time for the least durable result.

The buy bias on the BI tool itself matters most. A modern BI tool gives non-technical teammates a way to ask follow-up questions, often in plain English, without filing a request with engineering. That is the entire point of analytics for a lean team: fewer bottlenecks, not 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. A number in a SQL view, a different version 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 fine. Plan to re-evaluate at each stage trigger, not to build 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 valuable 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 actually need in one product: direct database connections, AI-assisted exploration, dashboards, reusable metrics, sharing, and scheduled reports. 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. That is the point of a modern lean BI stack: keep your data close to where it already lives, give the whole team a reliable way to answer questions, and only add separate infrastructure when a real constraint forces you to.