If you need analytics inside your SaaS product, you have four real options: build charts yourself with Chart.js or D3 against your own API (full control, 3-6 months of dev time), iFrame-embed a BI tool like Metabase (fast, but looks bolted on), buy a white-label SDK like Luzmo or Sisense (branded, but $250-1,000+/mo and a real integration project), or go API-first — expose your data as query endpoints and build a thin UI on top (most flexible, most engineering-light). Which one is right depends on how many customers are actually asking and how much of your roadmap you're willing to spend finding out.
Why customers expect this now
Ten years ago, "export to CSV" was an acceptable analytics story. It isn't anymore. Customers who pay you $200-2,000/mo expect to see their own usage, spend, or performance data inside your product, not in a spreadsheet they have to build themselves.
Three things happen when you ship in-product analytics well. Retention goes up, because a dashboard is a reason to log in even when nothing is broken. Support tickets go down, because "can you pull me a report on X" turns into "click the reports tab." And it becomes a real upsell lever — plenty of SaaS companies gate their best analytics behind a Pro or Enterprise tier and it converts, because the data was already valuable, you just made it visible.
The catch: none of that requires you to build a general-purpose BI product. Most teams overbuild this. You're solving "show my customer their data," not "compete with Looker."
The four approaches, compared honestly
Build from scratch (Chart.js/D3 + your own API). You own the whole stack: query layer, aggregation, chart rendering, filters, exports. Full design control, no per-seat licensing, and it feels native because it is native. The cost is real engineering time — 3-6 months for a first version that covers filtering, date ranges, and a handful of chart types, and then ongoing maintenance every time a customer wants a new cut of data. Most teams underestimate the long tail: the initial bar chart is easy, the "let me filter by three dimensions and export to PDF" requests are what eat the roadmap.
iFrame embed (Metabase, Preset, Redash). You stand up a BI tool, build dashboards in it, and iframe them into your app with a signed URL per customer for row-level filtering. This is the fastest path to "something is now in the product" — often a day or two. The tradeoff is visible: it looks like someone else's software living inside yours. Fonts don't match, there's a visible loading flash, and customization is limited to what the BI tool's theming supports. Metabase in particular is a reasonable choice here since its embedding is free on the open-source version — see our Metabase comparison if you're considering it. Fine for an internal-facing MVP or a low-stakes "customers asked, we shipped something" move. Riskier as your primary analytics UX if customers are paying a premium tier for it.
White-label SDK (Luzmo, Sisense, ThoughtSpot Embedded). These are purpose-built for this exact problem — branded, embeddable, with SDKs that let you match your product's look closely. The output quality is genuinely good. The cost is real money and real integration work: expect $250-1,000+/mo depending on data volume and seats, plus weeks of integration to wire up authentication, data modeling, and theming. At $10-20k MRR, a $500/mo embed tool is 20-50% of your entire margin on the feature — that's a bet you need real customer pull to justify, not a hunch.
API-first / headless (Fastero, GoodData, Cube). Instead of embedding someone else's UI, you expose your data as query results over a REST API and build your own lightweight UI — a table, a couple of charts, whatever your customers actually asked for. You get maximum control over UX (it's your React code) without owning the query infrastructure, auth, or scheduling layer. The tradeoff is you're still writing frontend code, just less of it than the from-scratch path, and you're dependent on whatever query/API surface the vendor exposes.
Decision framework
| Approach | Time to ship | Monthly cost | Customization | UX quality | Maintenance burden |
|---|---|---|---|---|---|
| Build from scratch | 3-6 months | $0 (your eng time) | Full | High (if done well) | High, forever |
| iFrame embed | 1-3 days | $0-50/mo | Low | Low-medium | Low |
| White-label SDK | 2-6 weeks | $250-1,000+/mo | High | High | Medium |
| API-first / headless | 1-3 weeks | $0-50/mo | High (it's your UI) | Depends on your frontend | Low-medium |
There's no universally correct row here. A seed-stage SaaS with two customers asking for dashboards should not be signing a Sisense contract. A Series B company with 500 customers demanding parity with their old BI tool probably shouldn't be hand-rolling D3 charts.
The "just enough" approach for early-stage SaaS
Most early-stage teams should not start with any of the heavy options. Here's the sequence that actually matches how customer demand grows:
- Start with query-as-a-service. Expose the SQL result your customers actually want as a REST endpoint —
GET /api/customer-usage?range=30dreturning JSON. No chart library, no dashboard framework. You're validating that customers want the data, not that they want your charts. - Build one simple table or chart on your frontend. A sortable table and a single line chart cover 80% of what customers ask for in the first six months. Recharts or a plain HTML table is enough. Do not build a chart library.
- Add webhook subscriptions so your app reacts to data changes, not just displays them. This is the step teams skip and then wonder why their "analytics" feature feels passive. If a metric crosses a threshold, your product should be able to notify the customer, not just wait for them to check a dashboard. See API + webhooks for what this looks like as a pattern.
- Graduate to a white-label SDK only when 100+ customers are demanding parity with a real BI tool — filtering, drill-down, custom date comparisons, exports. That's a signal, not a guess. Before that point, you're buying capability nobody asked for.
Common mistakes
- Building charts before validating customers actually want them. "Wouldn't it be nice if customers could see X" is not the same as a customer asking for it in a support ticket three times this month.
- Choosing a $500/mo embed tool at $10k MRR. That's 5% of revenue before you've confirmed the feature retains anyone. Start with the free/cheap option and upgrade when the math changes.
- Exposing raw database access instead of curated query results. Giving a customer (or their BI tool) a live connection to your production database because it was faster than building an API is a security incident waiting to happen, not a shortcut.
- Ignoring multi-tenancy from day one. Row-level security and tenant isolation are much cheaper to build in from the start than to retrofit once three customers have iframed dashboards pointed at data that isn't strictly theirs.
Most SaaS companies add embedded analytics too early, with too much polish, before they know which three metrics customers actually care about. Ship the ugly table first.
Where Fastero fits
Fastero lets you save a SQL query (or generate one from natural language) and expose it as a REST endpoint with API key auth, so you can pull the result into your own frontend. It also supports shareable dashboard links if you want something you can hand a customer without building a UI at all, plus scheduled delivery and webhooks if the analytics should trigger something rather than just sit there waiting to be viewed.
Best fit: developer-led teams who are happy to build their own UI (even a simple one) but don't want to stand up and maintain query infrastructure, connection pooling, scheduling, and access control themselves. If you already know you want option 4 above — build the query layer once, own the frontend — this is that layer.
Where to go from here
If you're actively comparing vendors across all four approaches, the best embedded analytics platforms comparison has honest pricing and tradeoffs for the white-label and API-first options side by side. If you've landed on API-first specifically, /solutions/embedded-analytics-api walks through the pattern in more depth.
Either way, don't start with the SDK contract. Start with one endpoint and one table, and let customer demand tell you whether you need more.