Scriptly Helps Pharmacies Identify Trends in Real Time with Reveal
Decision Guide
Embedded Analytics: Build vs Buy
The right one depends less on feature lists than on who the dashboards are for and how the cost behaves as you grow. If the analytics is for your own customers and the user count will rise with your business, both a per-seat BI license and an in-house build get expensive, in different ways. This guide sets out the criteria that separate the three approaches, and a proof-of-concept scorecard for testing any vendor against your own application rather than against their demo.
What are the three ways to add analytics to a product?
Embedded analytics puts dashboards, reporting, data exploration and — in some products — AI-assisted insights directly inside a software application. The goal is not simply to display charts. It is to help end users answer questions and take action without leaving the product.
Choosing an approach is a product, engineering, security and commercial decision at the same time. Most teams are deciding among three options, and the practical question is not "buy versus build" in isolation — it is which approach delivers the intended customer experience at an acceptable long-term cost and level of risk.
-
Build internally
What it means
Develop the analytics UI, semantic logic, data access, visualization layer and operational capabilities in-house.
Best fit
Analytics is a core, unique competitive advantage and the team can sustain a long-term analytics engineering investment.
Main trade-off
Highest control, and also the highest ongoing engineering and maintenance burden.
-
Embed a standalone BI tool
What it means
Integrate a general BI product into an application, often through embedding, links or frames.
Best fit
Internal users, or simpler customer-facing reporting needs.
Main trade-off
May introduce a separate product experience, constraints on branding or workflow, and licensing complexity.
-
Use an embedded analytics platform
What it means
Adopt a platform purpose-built to place analytics inside a host application through SDKs and APIs.
Best fit
Product teams that need customer-facing dashboards, self-service exploration and application-level control.
Main trade-off
Requires vendor evaluation and an integration effort, even when implementation is faster than building from scratch.
Building can provide maximum control, but it transfers responsibility for analytics features, performance, security, data connectivity, upgrades, usability and support to the product team. Buying can reduce time to market, but teams should examine whether a purchased product can be made to feel native to their application rather than like a separate analytics tool bolted on.
What should you evaluate in an embedded analytics platform?
A comprehensive evaluation should go beyond screenshots, visualization counts and analyst-review scores. These eleven criteria are the ones that determine whether embedded analytics succeeds after launch rather than during the demo.
Criterion
Questions to ask
Why it matters
Native integration
Does the platform use SDKs and APIs that fit the host application? Is the experience rendered in-product or dependent on iFrames, redirects, or a separate portal?
The integration model shapes performance, UX continuity, authentication, and how much product control the team retains.
Front-end compatibility
Does it support the client frameworks used by the product, such as React, Angular, Vue, Blazor or plain JavaScript?
A mismatch can increase custom integration work and make upgrades harder.
Server-side compatibility
Can it work with the team's existing back-end environment, such as .NET, Java, Node.js or another supported stack?
Data access, authentication, tenancy and governance often depend on server-side integration.
White-label control
Can the team control branding, layout, navigation, themes, interaction patterns and the placement of analytics in product workflows?
Customer-facing analytics should reinforce the product experience rather than advertise the analytics vendor.
Data connectivity
Which cloud, database, API and file-based sources are supported? Can the product connect to the existing data architecture without unnecessary duplication?
Connectivity affects implementation time, data freshness, cost and data-governance design.
Multi-tenancy and security
How are tenant identity, row-level access, user roles, authentication and authorization enforced?
SaaS applications must prevent cross-tenant exposure and align analytics access with product permissions.
Self-service analytics
Can end users filter, drill down, create or edit dashboards, and explore data within defined guardrails?
A static dashboard often creates a backlog; governed self-service can reduce it.
Performance and scale
What happens when users, tenants, dashboard complexity or query volume grows? What caching and deployment controls are available?
An attractive demo is not proof of acceptable production performance.
Deployment model
Is cloud, on-premises, private-cloud or hybrid deployment available? What data leaves the customer's environment?
Deployment choices can determine feasibility for regulated or enterprise buyers.
Commercial model
Is pricing predictable as adoption grows, or does it require renegotiation? How are costs calculated, and what changes as usage scales?
Analytics economics can become material — and volatile — once a product is rolled out broadly.
Vendor dependency
How portable are dashboards, data models and customizations? How are versions, APIs, support and product changes managed?
Buying accelerates delivery but creates an ongoing vendor relationship that should be evaluated.
When does building analytics in-house make sense?
Building analytics in-house makes sense when the analytics experience itself is the company's core differentiator and cannot be achieved with configurable third-party components. If what you are building is genuinely novel — a proprietary modelling approach, an interaction nobody else offers — a platform will get in the way.
A full build generally includes considerably more than charts. Teams need to create and then operate:
- Data connectors and credential management
- A semantic or metrics layer
- Query generation and performance optimization
- Dashboard and visualization components
- Filtering, drill-down, exports, scheduling and sharing
- Authentication, tenant isolation, role-based access and audit controls
- Dashboard authoring, versioning and lifecycle management
- Documentation, support, accessibility and ongoing maintenance
The largest risk is underestimating the permanent cost. Initial dashboard delivery is usually manageable. It is the advanced capabilities — self-service creation, governance, cross-filtering, performance at scale, resilient data access — that turn analytics into a long-term platform programme competing with your actual product roadmap for the same engineers.
Can you just embed the BI tool you already have?
Embedding a general-purpose BI tool can be the right call when analytics is primarily for internal users, when the customer experience can accommodate a distinct BI environment, or when the organization already has a strong enterprise-standard BI investment it is not going to abandon.
Before committing, validate:
- Whether the user enters a separate analytics context
- The available branding and layout control
- How embedded users are licensed
- Whether external-user access affects cost or administration
- Whether the product can enforce the host application's tenant and role model
- The degree to which the UI can be adapted to product workflows
This approach can be effective. But a product team should not assume that a tool designed primarily for analyst-led BI will deliver a product-native embedded experience without significant additional work.
What does an embedded analytics platform actually give you?
A purpose-built embedded analytics platform is intended to reduce the amount of infrastructure and analytics functionality a product team has to build itself, while leaving the team in control of where and how analytics appears in the product.
The category is not uniform. Platforms differ most on the integration model — whether analytics renders inside your front end or is served as a hosted view — and on how the licence behaves as your own customer base grows. Those two questions separate the options faster than any feature comparison, and both are in the criteria table above.
How does the commercial model affect the decision?
This is where embedded analytics decisions most often go wrong after the fact. Vendors with near-identical feature sets can behave very differently as you scale, and the difference is structural rather than a matter of discount.
Cost that moves with your own growth
Most embedded analytics platforms price on monthly active users, concurrent-user licences, per-tenant fees, or a hybrid. Under any of those, adding customers, entering a new geography, or simply getting more of your existing users into the dashboards increases what you pay. The analytics line in your cost base is indexed to the success of your own product, which is the opposite of what you want from an infrastructure component.
Expansion becomes a procurement decision
When pricing is tied to adoption, each meaningful change in adoption sends you back to the vendor contract — a new customer segment, a new market, a feature rollout that drives substantially more analytics use. What should be a product decision becomes a commercial negotiation with its own timeline. Teams underestimate this because it does not show up in the first-year price.
The real cost is only visible after the evaluation
Two vendors with matching feature lists can produce very different bills at scale, and under sales-led pricing that difference is usually discovered after the pilot, the proof of concept and the internal alignment — at the point where switching is most expensive. The way to avoid it is to model the cost at your projected adoption before you shortlist, not after.
Four answers, in writing
What to ask every vendor about cost
You do not need a published price list to compare vendors on cost. You need four answers, in writing, from each of them:
- What is the license unit — per user, per tenant, per application, per unit of capacity, or something else? This single answer tells you how the bill will behave.
- Which of my growth numbers moves the price? Customers, end users, concurrent sessions, tenants, queries, compute, AI usage. Ask them to name the variables.
- Model the cost at my projected adoption in three years, not year one. A vendor unwilling to do this is telling you something.
- What triggers a renegotiation or a contract change, and what does not? Get the threshold in writing before you shortlist.
When usage-based pricing is a reasonable trade-off
Usage-based and per-user pricing is a perfectly sensible choice if you are a large enterprise where negotiation is already part of how you buy software, if analytics is a supporting capability rather than a core differentiator so modest cost swings do not affect your margins, or if you expect adoption to be relatively flat after launch. In those situations the flexibility is worth more than the predictability.
Predictable licensing matters most in the opposite case: a fast-scaling product where unit economics determine whether you hit profitability, where you do not want a procurement cycle standing between you and a feature launch, and where you expect analytics usage to multiply over the next couple of years.
Where does Reveal fit in this framework?
Reveal, an embedded analytics SDK from Infragistics, sits in the third category — a platform built for placing analytics inside a host application rather than a BI tool adapted for it. It provides developer-facing SDKs and APIs for embedding, while the host application keeps control of branding, data access and deployment.
On the commercial criterion above, Reveal is licensed to the application rather than to the people who view the dashboards, so the number of end users does not move the license cost. Reveal is quoted rather than sold from a published price list; what the quote depends on is set out on the Reveal pricing page.
Reveal is worth evaluating when a team needs:
- Analytics that appears inside a SaaS, web, desktop or mobile application rather than in a separate BI destination
- White-label control over dashboards and the surrounding workflows
- End-user exploration — filtering, drill-down, dashboard interaction and governed dashboard creation
- An alternative to building visualization, dashboarding and analytics interaction capabilities from first principles
- SDK-based integration across web frameworks and supported server environments
- Deployment flexibility for cloud, on-premises or customer-controlled environments
- A license whose cost does not change as end users are added
When is Reveal the wrong choice?
Reveal is built for one job: analytics inside an application your customers use. Several situations fall outside that, and it is worth naming them.
If your users are internal analysts who need to explore data freely and build their own visualizations, Tableau or Power BI is the stronger tool and Reveal does not try to compete there. If you need a governed semantic layer across a large data estate, Looker is built for that problem. If you want a fully open-source stack you host and modify yourself, Metabase is the honest answer. And if the analytics experience is genuinely your product's core differentiator — something no configurable component can express — then the first approach in this guide is the right one, and you should build.
Reveal is the better choice when the dashboard has to look like your product, live in your codebase, ship on your release cycle, and cost the same whether a hundred or a hundred thousand people open it. If that is not the problem you have, one of the options above will serve you better.
Proof-of-Concept Scorecard
How do you run a proof of concept that actually tells you something?
Use a short, scenario-based proof of concept rather than a generic vendor demo. Score every shortlisted vendor against the same use case, and require evidence for each score rather than an assurance.
If you have decided to buy but do not yet have a shortlist, start from our roundup of embedded analytics platforms. For the requirements to hold each one against, see what to require of an embedded analytics platform.
Test scenarioEvidence to requestDecision signal
Embed a dashboard in a real product screen
A working implementation in the team's own application framework
Confirms integration effort and UI continuity
Apply tenant-specific access
A demonstration using two tenants and restricted datasets
Confirms whether the security design maps to your SaaS model
Match product branding
A customized theme, layout, navigation and host-product controls
Reveals whether the experience can feel product-native
Enable user exploration
Filtering, drill-down, dashboard interaction and governed authoring
Measures end-user value beyond static reporting
Connect production-like data
A representative cloud, database or API source
Exposes connector, credential and performance constraints
Test operational behaviour
Concurrent usage, slow queries, errors and the monitoring approach
Indicates production readiness
Model commercial growth
A cost scenario for current and projected use, from every vendor on the shortlist
Avoids evaluating a low initial cost without scale economics
Operate and upgrade
Versioning, release process, support model and rollback plan
Assesses the ongoing ownership burden
Weight the criteria by what matters to your product. A multi-tenant B2B SaaS product will usually weight security, white-label control and commercial scalability far above the breadth of prebuilt chart types — and a scorecard that does not reflect that will pick the wrong vendor with great precision.
What should you ask every embedded analytics vendor?
Integration
- What does "embedded" mean in your architecture: SDK, API, iFrame, web component, redirect, or something else?
- Which front-end and server-side technologies are officially supported, and what is the upgrade policy?
Security and Data Access
- How do authentication, tenant context, row-level permissions and data-source credentials work?
- Can the platform use our existing identity and authorization model?
End-User Experience
- What can end users do: view, filter, drill down, export, create dashboards, edit dashboards, query in natural language?
- What branding, layout and interaction controls are available to the host application?
Deployment and Operations
- What are the deployment choices, and where are queries and data processed?
- How are performance, caching, concurrency, usage limits and monitoring handled?
Commercial Terms
- How does pricing change as the number of customers, tenants, applications or embedded users grows, and what triggers a contract change?
- Can you model the cost for our expected adoption curve over three years?
Portability and Proof
- What is portable if we change vendors later?
- Can you demonstrate the complete workflow — not just a dashboard — using our architecture and data model?
So which approach should you choose?
Choose
An internal build
When
Analytics is a strategic product capability requiring genuinely unique behaviour that no configurable component can express.
And be prepared for
A permanent analytics platform investment — infrastructure, visualization components, security controls and a self-service experience, maintained indefinitely.
Choose
A general BI embedding approach
When
The main requirement is to expose existing BI content or serve internal and analyst-oriented workflows, and a distinct analytics experience is acceptable.
And be prepared for
Additional engineering before it feels like part of your product, plus external-user licensing and tenant-isolation questions.
Choose
An embedded analytics platform
When
The priority is an application-native analytics experience delivered faster than a full internal build, while keeping control over UX, deployment, data access and tenant-aware security.
And be prepared for
A vendor evaluation and an integration effort — and an ongoing vendor relationship that needs to be assessed on commercial terms, not just features.
Whichever direction you lean, prove it with a scoped implementation using your actual application, user roles, data sources, expected production conditions and realistic commercial scaling scenarios. Every approach in this guide looks workable in a demo. The scorecard above is how you find out which one is workable in your product.
Common Questions
Should we build or buy embedded analytics?
Build when the analytics experience is your core differentiator and cannot be achieved with configurable components — and when you are prepared to own a permanent analytics platform, not just a first release. Buy when the priority is an application-native experience delivered faster, and you would rather spend your engineers on your actual product. The deciding factor is usually not cost at launch but who the dashboards are for: if they are for your customers rather than your own team, the long-term economics favour a platform.
Should we build or buy customer-facing dashboards?
Customer-facing dashboards are the case where building is hardest to justify. Beyond the charts themselves you take on tenant isolation, row-level security, dashboard authoring, versioning, exports, scheduling, mobile behaviour, accessibility and support — all of which your customers will expect and none of which differentiates your product. Unless the dashboard experience is itself the thing you sell, a platform built for embedding will get you there faster and keep costing the same as your customer base grows.
What should I look for in an embedded analytics platform?
Eleven criteria separate the options in practice: native integration, front-end compatibility, server-side compatibility, white-label control, data connectivity, multi-tenancy and security, self-service analytics, performance and scale, deployment model, commercial model, and vendor dependency. The two that most often decide the outcome are the integration model — whether analytics renders inside your front end or is served as a hosted view — and the licence unit, because that determines whether your analytics cost grows with your own customer base.
What does building analytics in-house actually involve?
More than charts. A full build means creating and then operating data connectors and credential management, a semantic or metrics layer, query generation and performance optimization, visualization components, filtering and drill-down and exports and scheduling, authentication and tenant isolation and role-based access and audit controls, dashboard authoring and versioning, responsive behaviour, and documentation and support. The first dashboards are usually manageable; it is the self-service, governance and scale work that turns it into a permanent programme.
Can we embed the BI tool we already use?
Often yes, and it can be the right answer for internal users or simpler customer reporting. Validate six things first: whether the user enters a separate analytics context, how much branding and layout control you get, how embedded users are licensed, whether external-user access changes the cost or the administration, whether the tool can enforce your application's own tenant and role model, and how far the UI can be adapted to your workflows. A tool designed for analyst-led BI will not become product-native without real engineering effort.
How do I run a proof of concept for embedded analytics?
Score every shortlisted vendor against the same scenario-based tests rather than watching their demo: embed a dashboard in a real product screen, apply tenant-specific access across two tenants, match your product branding, enable end-user exploration, connect a production-like data source, test operational behaviour under concurrency, model the commercial cost at projected adoption, and review the upgrade and rollback process. Require evidence for each, not an assurance. Weight the criteria by what matters to your product.
How does pricing affect the build-versus-buy decision?
It affects it more than most teams model. Per-user, per-tenant and usage-based licensing all link your analytics cost to your own growth, which means a successful product rollout increases the bill and each expansion can trigger a contract conversation. Licensing tied to the application rather than the viewer does not behave that way. Ask every vendor for the licence unit, which of your growth numbers moves the price, a three-year cost model at your projected adoption, and what triggers a renegotiation — in writing, before you shortlist.
When is building analytics in-house the right call?
When the analytics experience is genuinely your differentiator and a configurable platform cannot express it — a proprietary modelling approach, an interaction nobody else offers, a workflow that is the product. In that case the control is worth the permanent investment. It is the wrong call when the requirement is good dashboards delivered quickly, because you will spend years rebuilding capabilities that already exist while your competitors ship features.
Test It Against Your Own Application
A platform can be technically capable and still be a poor fit for a particular product. Whichever approach this guide points you towards, prove it with a scoped implementation against your real architecture and data before you commit. Reveal, an embedded analytics SDK from Infragistics, will run a proof of concept in your own stack — and if the framework above suggests a different approach is right for you, that is a useful outcome too.
Book a proof of conceptNext: Build vs Buy in the Age of AI — the webinar →
Also: Buy vs Build: the ROI of Embedded Analytics Solutions →
