Developer

Natural-language query layer for your SaaS: build, buy or embed

If you run a B2B SaaS and customers want to ask questions of their own data, here is the build-vs-buy-vs-embed analysis, with the architecture sketches for each path.

By Ramanuj Laddha · 10 May 2026 · 5 min read

A typical SaaS roadmap conversation in 2026:

“Customers keep asking for a chat interface over their data. They want to type ‘how many active users last month’ and get an answer. Should we build it?”

Three options on the table: build, buy, embed. Each has a real architecture and a real cost. Here is the honest comparison.

Option 1: Build

You staff a small team (one backend engineer, one ML/LLM engineer, one designer) and you ship in 3–6 months.

The architecture:

[customer query]
→ [tenant context resolver]
→ [schema retrieval (RAG over your DB schema)]
→ [LLM prompt: schema + few-shots + question]
→ [SQL validator + tenant predicate injection]
→ [read replica execution]
→ [result → chart picker]
→ [streamed answer to UI]

What you actually own:

  • A schema embedding index per customer (or shared, with tenant filtering).
  • A few-shot example library that needs curation as your product grows.
  • A SQL parser/validator (use libpg_query or equivalent).
  • A chart picker.
  • LLM cost management.
  • A semantic layer of views encoding your product’s business definitions.
  • Multi-tenant security with RLS or AST predicate injection.
  • An eval harness with golden questions.

Real cost: 4–6 months to v1, 1 FTE thereafter for maintenance and accuracy improvements. ₹70 L–1.5 Cr (~$80k–180k) including LLM costs at scale.

When to build: your data model is the differentiator, you have strong ML engineering, customers are paying enterprise prices and want extensive customisation.

Option 2: Buy (use a standalone analytics product)

Your customers go to a separate SaaS, connect their own data, and use it there. You don’t change your product.

This is the lowest engineering cost. It is also the worst customer experience: customers have to context-switch, manage another login, train another tool, pay another vendor.

When to buy: you have low ARPU customers, low analytics demand, and the analytics need is incidental rather than core.

Option 3: Embed

You partner with an embedded analytics provider, and the AI chat / dashboard / reports surface appears inside your product via iframe, SDK, or “powered by”. Your customers don’t leave your app.

The architecture:

[your SaaS UI]
├── [your existing app]
└── [<analytics-pane>] ← iframe / SDK / npm package
[embed provider]
[customer's data source, connected once]

What you own:

  • The connection to the data source (customer’s, or theirs-in-your-product).
  • Auth handshake (JWT-based usually, with tenant claim).
  • Theming.
  • A bit of layout.

What the provider owns:

  • LLM pipeline.
  • Schema retrieval.
  • SQL validation.
  • Chart picking and rendering.
  • Multi-tenant security guarantees.
  • Roadmap (new chart types, new connectors, model upgrades).

Real cost: 1–3 weeks of integration. Per-customer or per-org licensing.

When to embed: you want this feature live within a quarter, the analytics layer is not your core differentiation, and customers will pay you for the feature without caring who powers it.

The decision matrix

BuildBuy (standalone)Embed
Time to v14–6 months01–3 weeks
Engineering loadHigh, perpetualNoneLow, one-time
Customer UXBestWorstNative-feeling
Cost at 10 customersVery highLowMedium
Cost at 1000 customersSpread thin (good)LowHigh (per-seat)
DifferentiationYes if your data model mattersNoneModest (your branding)
Roadmap controlTotalNonePartner-dependent

Two crossover points:

  • Volume crossover: at very large scale, building becomes economical because per-seat embed pricing adds up.
  • Differentiation crossover: if your analytics layer encodes industry-specific business logic that nobody else has, building protects that moat.

If neither applies to you, embed is usually the right call for the first 18 months. You can always build later, and by then you will know exactly which 20% of features actually matter.

What “embed” looks like in practice

A typical embed path:

  1. One-time setup: you get an API key. Your backend exchanges it for short-lived JWTs scoped to a customer.
  2. Connector once: you OAuth / connect the customer’s database (or yours) on their behalf.
  3. Iframe or component: drop the analytics pane into your UI. JWT auths the user; tenancy is enforced server-side.
  4. Theming: colours, fonts, logo. Three lines of CSS variables.
  5. Done.

This is the path most B2B SaaS that ships “AI analytics inside” took in 2025–26.

Doing this with AnalytAI

AnalytAI offers all three of: iframe embed, an NPM SDK, and a “powered by” / white-label path for ERP, vertical SaaS and accounting platforms. If you have B2B customers asking “can I just chat with my data?” we can sit on top of your existing app in a sprint.

See partner options or start a partner conversation.

Related reads:


More on Developer

See all Developer posts →

See AnalytAI on your data

Bring one Tally company or one SQL database. We will turn it into a live dashboard on a 20-minute call.

Book a demo