Anyone can build a dashboard.
Almost nobody builds it right.
The question isn't whether your dev team can build embedded analytics. It's what it actually costs — in engineering time, architecture decisions, and permanent maintenance burden — to build it securely for multi-tenant at scale. That's a fundamentally different problem.
What your dev team's time actually costs
Engineering time isn't free. Before you decide to build, put a number on it.
Estimates based on industry averages. Your numbers will vary. The point isn't precision — it's that the math almost always favors buying once you include ongoing maintenance.
Five problems that compound the longer you wait
Sprint one is the easy part. These are the problems that surface at month four and never fully resolve.
Multi-tenant data isolation
Tenant A must never see Tenant B's data — not under any error condition, query edge case, or caching scenario. This is an architecture you design from scratch and audit continuously, not a feature you add later. One mistake is a breach. Complexity scales with every customer you onboard.
Per-customer white-label & branding
Your customers want analytics that feel native to your product — not a bolted-on tool with someone else's logo. Per-tenant logo, colors, domain, and navigation. Multiplied by every customer you add. This isn't a CSS file. It's a theming engine and a tenant configuration system.
Performance at scale
One customer running a report is fine. Fifty customers running dashboards simultaneously — across separate database connections, with separate caching contexts — is a different problem. You need in-memory caching per user per tenant, query optimization, and connection pooling. This is an ongoing engineering investment, not a one-time fix.
The maintenance never ends
The dev who built the reporting layer leaves. Now someone else owns it. Six months later, nobody fully understands why the multi-tenant caching works the way it does. Meanwhile the backlog of reporting tickets keeps growing. This is how 25–35% of engineering capacity gets permanently allocated to keeping the lights on.
Customers always want more
You ship version one. Customers log in and ask for drill-down, then pivot tables, then scheduled email delivery, then Excel export, then ask why the numbers differ from their other system. None of these are unreasonable. But each one adds to a maintenance surface your team owns forever. You're now running a BI product inside your product.
"Can't your team just vibe-code this?"
Yes — and that's exactly the problem. AI tools can scaffold a chart component in an afternoon. Anyone can prompt their way to something that looks like embedded analytics. The demo looks great.
What AI doesn't give you is the architecture underneath: multi-tenant isolation that doesn't collapse under edge cases, per-customer security policies that propagate correctly through AI-generated queries, or performance that holds when 50 customers load dashboards simultaneously. Those aren't UI problems. They're architecture problems. And AI accelerates building the wrong version faster.
Yurbi's approach to AI is deliberate: build on top of a semantic layer that already understands your data model, your tenant structure, and your security policies — so AI-generated queries are safe to put in front of customers. That's the only way this works in a multi-tenant product. The downside of getting it wrong isn't a broken chart. It's a data breach.
Build vs Yurbi — the full picture
Not just cost. Timeline, risk, ongoing burden, and what your engineers do instead.
When building it yourself actually makes sense
We're not going to tell you every company should buy. There are real scenarios where building is the right call — and pretending otherwise wastes your time and ours.
Build if:
- Analytics is your core product — you're selling a BI tool, not embedding one inside something else
- You have deeply proprietary visualization requirements no platform can serve
- You have a dedicated BI engineering team with sustained runway to maintain it indefinitely
- Your data architecture is so unique that no existing embedding model fits
Buy if:
- Analytics is a feature of your product, not the product itself
- You need it working in months, not years
- You have a multi-tenant architecture with per-customer databases
- Your engineers should be shipping your core product
- You want predictable cost that doesn't grow as your customer base scales
Most ISVs fall squarely in the "buy" column. The ones who build tend to discover that 18 months later — after two engineers have spent the better part of two years on it — and then they switch anyway.
Build vs buy questions, answered directly
A basic dashboard that looks good in a demo: 2–4 weeks. Production-ready embedded analytics for a multi-tenant SaaS product — with real tenant data isolation, per-customer branding, role-based access, performance under load, and scheduled export: 6–12 months minimum for experienced teams. Often longer for teams that underestimate the architecture requirements.
The difference between a demo and a production system is almost entirely in things that don't show up in a screenshot: security, isolation, performance, and the ongoing maintenance surface you're committing to.
Open-source charting libraries (Recharts, D3, Chart.js) give you the visualization layer. They don't give you multi-tenant security architecture, a semantic layer, per-tenant branding configuration, scheduled delivery, row-level security, dynamic data source routing, or any of the platform-level features that make embedded analytics work for ISVs at scale.
You're still building everything except the charts themselves — which is roughly 20% of the actual problem.
It depends on how much is built and how much pain you're experiencing. If your team is spending significant sprint capacity on reporting maintenance, if customers are churning over missing analytics features, or if you're losing deals to competitors with better built-in analytics — those are signals that what you have isn't keeping pace with what you need.
Switching from a partial custom build to Yurbi is a real migration project — we won't pretend otherwise. But the calculation is: how much will you spend continuing to maintain and extend what you have, versus a one-time migration cost — and then never maintaining it again. For most teams that do that math, migration wins by year two.
Tell us what it is. Yurbi's visualization layer is HTML/JS/CSS — custom chart types can be built and shipped rapidly, often in days. We ship weekly. Enhancement requests from embedded partners get real responses, not a ticket queue. You're talking to the engineers who built the platform, not a support tier.
We'll also tell you honestly if something isn't feasible or isn't on the roadmap. We'd rather have that conversation before implementation than after.
Yurbi handles multi-tenant isolation at the platform level — not as a configuration option you set per tenant. It supports two primary architectures: shared database with row-level security (tenant filter enforced at query time), and dynamic data source routing (each tenant has their own database, Yurbi routes each session to the correct connection). Both are supported out of the box. Most ISVs use a combination depending on their deployment model.
The key point: tenant boundaries are enforced by the platform, not by your application code. You're not writing tenant filters and hoping they hold. See the security page for the full architecture.
A few things worth knowing upfront: Yurbi embeds via iframe and API — there's no JS SDK for deep in-page programmatic interactivity. SSO is session-token based via our DoLogin API, not SAML/OIDC; if your enterprise customers require checkbox SAML compliance, that's a current gap (full SAML is on the roadmap). Mobile is functional but not a differentiating selling point. Dashboard interactivity is parameter and global-filter driven — there's no associative click-through filtering between widgets the way Tableau handles it.
We'd rather tell you this now than have you discover it after you've built on top of us. If any of those matter for your use case, let's talk through fit in a demo.
Download the trial, connect it to your database, configure your tenant structure, and you can have a working embedded dashboard in your product within days. Full production deployment — with your branding, your SSO integration, and your customer data — typically takes 2–6 weeks depending on the complexity of your data architecture and how much customization you want at launch.
That's the entire initial build, not a sprint estimate. After that, Yurbi runs, your team doesn't maintain it, and your customers get analytics that feel native to your product.
Self-hosted means Yurbi runs on your servers — whether those are on-premise machines, your own cloud VMs (AWS, Azure, GCP), or a hybrid. Your data never leaves your infrastructure. Yurbi doesn't run in our cloud and we have no access to your data. This matters for ISVs whose customers have data residency requirements, security policies, or enterprise compliance mandates.
Yurbi runs on Windows Server, Linux, or Docker (x86/amd64). See self-hosted deployment for full architecture options and system requirements.