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.
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_queryor 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
| Build | Buy (standalone) | Embed | |
|---|---|---|---|
| Time to v1 | 4–6 months | 0 | 1–3 weeks |
| Engineering load | High, perpetual | None | Low, one-time |
| Customer UX | Best | Worst | Native-feeling |
| Cost at 10 customers | Very high | Low | Medium |
| Cost at 1000 customers | Spread thin (good) | Low | High (per-seat) |
| Differentiation | Yes if your data model matters | None | Modest (your branding) |
| Roadmap control | Total | None | Partner-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:
- One-time setup: you get an API key. Your backend exchanges it for short-lived JWTs scoped to a customer.
- Connector once: you OAuth / connect the customer’s database (or yours) on their behalf.
- Iframe or component: drop the analytics pane into your UI. JWT auths the user; tenancy is enforced server-side.
- Theming: colours, fonts, logo. Three lines of CSS variables.
- 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
-
4 May 2026
Writing SQL with AI in 2026: what works, what does not
An honest review of LLM-generated SQL after two years in production: where the models are excellent, where they still fail, and the engineering patterns that close the gap.
-
1 May 2026
Auto-generate charts from any SQL database: patterns that actually work
How to go from an arbitrary SQL result to the right chart: column-shape rules, a default-picker algorithm, when to override, and the common traps.
-
28 Apr 2026
Talk to your PostgreSQL database in plain English: a developer's guide
How natural-language-to-SQL actually works on PostgreSQL: schema introspection, retrieval, prompt design, sandboxing, and the failure modes that don't show up in demos.
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