Insights · 13 min read
What it costs to build an analytics platform, the semantic layer and architecture behind a trustworthy BI product, and how to sequence the work so it ships.
By GGP Editorial
An analytics platform takes raw data from a company's systems and turns it into charts, tables, and reports that people can act on. That sentence hides most of the work. The hard part is not drawing a bar chart. It is getting the right number, with the right definition, to the right person, fast enough that they trust it.
Companies build these platforms for three reasons. Some founders are building an analytics or business intelligence product to sell to other companies. Some want to embed dashboards inside a product they already run. Some just need internal reporting that no longer depends on spreadsheets emailed around on a Friday afternoon. The build looks different in each case, but the backbone is the same, and that backbone is where projects go wrong.
This guide covers what the platform actually contains, the features that matter at launch, the architecture in plain terms, where AI fits, what it costs, and how to sequence the work so it ships instead of becoming a two-year data project.
Get the three scenarios straight before you budget, because they change the scope more than any feature decision.
| Scenario | What you build | Who uses it | Typical shape |
|---|---|---|---|
| Standalone BI product | A platform you sell to other companies | Your customers' analysts and managers | Multi-tenant, many connectors, self-serve |
| Embedded analytics | Dashboards inside a product you already sell | Your own end users | Narrower, deeper, white-labeled |
| Internal reporting | Reporting for one company | Your own teams | Fewer connectors, less polish, more speed |
A standalone BI product is the hardest to build well because it has to work with data you have never seen, in warehouses you do not control, for people who will leave if the first dashboard is slow. Embedded analytics is more contained: you know your own data model, so you can pre-build the metrics and keep the surface simple. Internal reporting is the smallest scope and the fastest to pay off, which is why a lot of teams start there and grow outward.
Whatever the scenario, the platform has five parts that have to work together. Skip any one and the product falls apart the first time a real user asks a real question.
The five parts are connectors that pull data in, a place to store and model it, a semantic layer that defines what every metric means, a query layer that turns questions into fast results, and a front end that shows the results. I will walk through each below.
Most teams start with the visualization layer because it is the part everyone can see, and that is backwards. The features that decide whether people trust the product are the ones nobody sees.
Connectors. Your platform has to read from the systems your users already have: a data warehouse like Snowflake or BigQuery, a database like Postgres, a SaaS tool like a CRM or billing system, sometimes a CSV someone uploaded. Every connector you support is ongoing maintenance, so start with one warehouse and one or two databases and add more on demand.
The semantic layer. This is the single most important feature and the one most first-time builders skip. The semantic layer is where you define what "revenue" means, or "active user," or "gross margin," in one place, so every chart and every person gets the same answer. Without it, two dashboards will show different numbers for the same metric, and once a user notices that, they stop trusting the whole product. Tools and patterns like dbt and LookML exist for exactly this reason.
Row-level security. Who can see which rows of data, enforced in the query rather than the front end. If you build for multiple tenants or multiple departments, this is a launch blocker, not a nice-to-have.
A fast query layer. Users judge analytics in seconds. If a dashboard takes twenty seconds to load, they go back to the spreadsheet. You need caching, pre-aggregation, and a query engine that does not scan the whole warehouse every time someone opens a page.
Export and alerts. People do not just look at dashboards. They export to CSV or PDF, subscribe to a weekly email, and set an alert when a number crosses a line. These features look small and each one eats real engineering time.
You can defer a lot: custom theming, saved report libraries, natural-language search, forecasting, collaboration comments, mobile apps. Ship the trustworthy core first, then layer the rest.
A production analytics platform is a pipeline with four stages. Here is what each does and why it matters.
There is a newer fifth stage worth a note: a natural-language layer that lets users ask questions in plain English and get a chart back, powered by a language model that writes the SQL. More on that below.
The main architecture lesson is this: the semantic layer is the asset. The charts are just a view over it. Teams that build the charts first end up redoing the whole thing the first time a definition changes.
Natural-language analytics is the part every founder asks about now. The idea is simple: a user types "revenue by region last quarter" and the platform returns a chart. Under the hood, a language model converts the question to SQL against your semantic layer and runs it.
It is genuinely useful for two audiences. It lets executives and non-technical managers get answers without learning a query tool, and it speeds up analysts who would rather describe a question than write it. The catch is trust. Language models make mistakes, and in analytics a wrong number presented confidently is worse than no number at all.
The design that works in production keeps the model on a tight leash. The model only writes queries against the semantic layer, never free-form SQL over raw tables. It shows the generated query so the user can see what was asked. It refuses questions that cannot be answered from the data instead of guessing. And it cites the definitions it used, so a wrong answer usually means a wrong definition, which you can fix once.
If this part interests you, we wrote a longer piece on integrating an LLM into existing software, and the same evaluation discipline we describe for AI copilots applies here. My advice is to build the semantic layer first and bolt the natural-language layer on later. It is a thin feature over work you needed to do anyway.
Cost follows the same logic as any custom software build: team size times duration. Here is a realistic view based on how these projects actually scope.
| Scope | What you get | Typical range |
|---|---|---|
| Embedded analytics | A handful of dashboards over your own data model, white-labeled, with row-level security | $30,000–$70,000 |
| Internal BI / reporting | Connectors, warehouse modeling, semantic layer, self-serve dashboards for one company | $50,000–$120,000 |
| Standalone BI product | Multi-tenant, many connectors, semantic layer, query engine, permissions, natural-language layer | $120,000–$350,000+ |
These ranges assume a senior team and a real production bar. They move with three things: how many data sources you connect to, how strict the security and governance requirements are, and whether you build or license the semantic and query layers.
The money does not go where people expect. The visualization layer is the cheap part. The expensive parts are the semantic layer, because definitions are a product in themselves; the query performance work, because "fast enough" is a moving target as data grows; and the connectors, because each one is a long tail of edge cases. Licensing a warehouse and a BI framework costs a fraction of the engineering time, which surprises founders who assumed the software licenses would dominate the budget.
For a full breakdown by team and stage, the AI development cost guide and the custom software development cost guide cover the numbers in detail. The short version for analytics: budget for the semantic layer and the query engine, not for pretty charts.
There are three honest paths, and the right one depends on what you are selling.
Embed an existing BI tool if you just need dashboards in your product and the default look and behavior are acceptable. Embedding Looker, Power BI, or Metabase gets you to launch in weeks, but you pay per user or per view, you lose control of the experience, and per-seat pricing hurts when your user count grows.
Build on your stack when analytics is the product, or when you need deep control over the semantic layer, security, and cost at scale. This is where most BI founders and most SaaS companies with real data volumes land.
Build on an open-source core when you want a middle path. Starting from Metabase, Superset, or a headless layer like Cube and building your semantic layer and experience on top saves months while keeping ownership. You trade some flexibility for speed.
We wrote a longer comparison in Build vs buy software. My advice is usually this: if analytics is a feature, embed. If analytics is the product, build, and start from an open-source core if you can. That gets you to real users fastest with the least rework later.
Analytics projects do not fail on technology. They fail because the team scoped the whole product on day one, or because they built the charts before the definitions. This is the sequence that has worked for us.
| Phase | What happens | Typical time |
|---|---|---|
| 1. Pick one use case | One audience, one set of metrics, one data source | 1 week |
| 2. Build the semantic layer | Define the metrics and dimensions that audience needs | 2–3 weeks |
| 3. Wire one data source | Ingest and model the data end to end | 2–3 weeks |
| 4. Build a first dashboard | A few charts over the semantic layer, with row-level security | 2–3 weeks |
| 5. Add performance work | Caching, pre-aggregation, index tuning | 2–3 weeks |
| 6. Pilot and expand | Put it in front of real users, fix trust gaps, add connectors | ongoing |
That puts a first useful analytics product at roughly three to four months for a small team. The sequence matters more than the dates. Get one use case right, with definitions users trust, and every later use case rides on the same semantic layer and gets much faster.
If you build in-house, hire for data modeling and query performance experience, not for "dashboard design" on a resume. If you outsource, look for a team that has shipped an analytics or data product into production, and ask them to walk you through how they built the semantic layer, because that is where the real skill shows. The questions are the same as for any software development company, with one addition: ask what happened the last time a dashboard showed the wrong number and how they traced it.
GlobeSoft is a China-based engineering team with a global client base, founded in 2018, with 40+ engineers and 300+ delivered projects. Analytics work sits inside our custom software development and AI development practices. We have built reporting-heavy systems before, including a multi-market trading system where accurate, real-time numbers were the whole point of the product. If you are weighing a build, we are happy to look at your data and your use case and tell you whether to embed, build, or start from an open-source core.
How much does it cost to build an analytics platform?
Embedded analytics over your own data runs roughly $30,000 to $70,000. Internal BI and reporting for one company typically lands between $50,000 and $120,000. A standalone multi-tenant BI product can run $120,000 to $350,000 or more. The spread depends on data sources, security requirements, and whether you license or build the query layer.
Should I build or buy an analytics platform?
If analytics is a feature inside a product you sell, embedding an existing BI tool is usually the fastest and cheapest path. If analytics is the product you are selling, build it, and consider starting from an open-source core like Metabase, Superset, or Cube. See Build vs buy software.
What is a semantic layer and why does it matter?
The semantic layer is where you define what each metric means in one place, so every chart and every user gets the same answer. Without it, different dashboards show different numbers for the same metric, and users stop trusting the product.
Can I add natural-language queries to my analytics platform?
Yes. You keep a language model on a tight leash so it only writes queries against your semantic layer, shows the generated query, and cites its definitions. Build the semantic layer first and add the natural-language layer on top.
How long does it take to build an analytics platform?
A first useful analytics product takes roughly three to four months with a small team, from picking one use case to a piloted dashboard set. Later use cases go faster because they reuse the same semantic layer.
What is the most common reason analytics projects fail?
Building the charts before the definitions. Teams invest in the visualization layer first, then realize two dashboards disagree, and have to rebuild. Start with the semantic layer.
If you are planning an analytics platform or want reporting inside your product, talk to us about your project. Tell us your data sources and the question your users need to answer, and we will map out the scope, architecture, and budget.
Tell us what you are building and where you are today. We typically reply within 24 hours.
