AI product strategy: embed AI or launch a separate product?

01The AI product strategy decision in five criteria

We use five criteria you can answer in one meeting. Each points toward embedded or separate, and the pattern makes the call. This is part of our larger guide, AI integration for SaaS: add AI without a rebuild.

The rule we apply is simple. If the buyer and the data criteria both point to embedded, build it into the product, whatever the other three say. Consider a separate product only when at least two of buyer, pricing and distribution point that way and the AI does not depend on your core data model. When the matrix splits, start embedded behind a feature flag and let real usage settle it.

The customer service market shows how closely pricing follows the product. Zendesk's own documentation describes the automated resolution as the unit it uses to bill AI agent usage. The allocation depends on the customer's Zendesk plan, so the AI is bought as part of the help desk relationship. Intercom moved early to outcome pricing, charging $0.99 per successful autonomous resolution, as co-founder Des Traynor explained to Kyle Poyar. A support agent needs only conversations and help articles, which every help desk has. Most vertical SaaS capabilities depend on records only your product holds, which is why embedded is usually the right default.

02Who is the buyer for the AI capability?

Start with the purchase order, not the model: who would approve spending on this capability, and from which budget?

If that person is the same one who renews your core contract, the capability is part of your product's value. Putting it in a separate product forces that buyer through a second evaluation, a second security review and a second contract for something they expect from you. Embedded AI also protects the renewal: it gives your existing buyer a reason to stay that a newcomer cannot copy quickly.

If the buyer is different, the answer can change. A capability used by your customer's customers, by a department that never logs into your product, or by a partner who wants to resell it, has its own sales conversation. That is the first real signal for a separate product.

One trap: the end user and the buyer are often different people. A feature that delights end users but is paid for by the administrator who buys your platform is still an embedded feature.

03Does the AI depend on your existing data and permissions?

This is the criterion that settles most decisions, and it usually points to embedded. Your mature product already holds years of business logic, integrations and permissions. Those are exactly the context and tools an AI agent needs to be useful, and they are what a new standalone product would have to rebuild or copy.

Ask three questions:

• Does the AI need records only your product holds, such as bookings, inventory, enrollments, patients or transactions?
• Does it need to respect your tenant boundaries and role-based permissions, so a user sees only what they can already see?
• Does it need to act through your existing workflows, such as creating a task, updating a record or sending a message your product already sends?

If the answer to any of them is yes, a separate product means building a second identity system, a second permission model and a sync job that copies sensitive data into a new place. Every copy is another item in your customers' security reviews. Built inside the product, the AI inherits the permissions, tenancy and audit trail you already maintain. The hard part is not the model. It is everything around the model, and an established product already has most of it.

04How would pricing and packaging differ?

Kyle Poyar's 2025 State of B2B Monetization survey of more than 240 software and AI companies found that 53% include AI capabilities in their core software offering. In the same survey, 16% sell AI largely as a standalone product or add-on. The same survey found hybrid pricing, a subscription combined with usage, rising from 27% to 41% of respondents in a year. Respondents named internal costs and margins as the most important factor when pricing AI.

That points to four packaging options for an embedded capability:

• Included in every plan, when the AI protects renewals for a workflow every customer runs.
• A higher tier, when it is valuable to some customers and cheap to serve.
• An add-on or usage credits, when cost scales with use. Poyar notes monday.com includes 500 AI credits per month across all paid plans.
• Outcome pricing, when the AI completes a unit of work you can count.

A separate product makes sense when the right price metric cannot sit inside your core contracts. Intercom charges per successful autonomous resolution, and Zendesk counts an automated resolution only when a request is resolved without escalation to a human agent and passes a check by a large language model. Poyar's survey also shows how hard outcome pricing is: only 5% of respondents used it as their primary model. He argues it needs consistency, attribution, measurability and predictability of outcomes before it works.

Whatever you choose, measure cost per successful task, not cost per call. That number decides whether a capability can be included or must be charged for.

05When does a separate or white label AI product make sense?

A separate product is the right call in a narrower set of cases than most roadmaps assume. We look for at least two of these:

• A different buyer with its own budget, who does not need your core product to get value.
• Data that travels: the AI runs on inputs the customer or partner brings, such as an inventory feed or a document set, through defined connectors.
• A partner channel: other software companies or resellers want to put it in front of their own customers under their own brand.
• A pricing model, such as per outcome or per partner, that would distort your core plans.
• A launch you want to test with buyers before you commit your core roadmap to it.

White label is a special case. The product ships under someone else's name, so it has to be configurable per partner (branding, tone, knowledge, data sources) and has to hand its results into each partner's own systems. That is more engineering than an embedded feature, not less.

A separate product also needs its own roadmap, support, security answers and sales motion. If the matrix does not justify that overhead, embed.

06Can we start embedded and spin out later?

Yes, and for most established vertical SaaS companies it is the lowest risk path. Embedding first proves the capability with buyers you already have. Spinning out later is cheap only if you design for it early. The sequence we recommend:

1. 01

   Ship one capability inside the product, behind a feature flag, for a small group of customers.

2. 02

   Measure usage, cost per successful task and whether it changes renewals or expansion.

3. 03

   Draw a boundary between the AI engine and your product code, and let the AI reach product data only through a defined set of tools and APIs, not through direct database access.

4. 04

   Make that engine tenant aware and configurable, with evaluations you can run per customer.

5. 05

   Spin it out only when a second buyer or a partner asks for it without your core product.

Step 3 is the one teams skip. If the capability calls your internal tables directly, spinning it out means rewriting it. If it already acts through a tool layer, a standalone or white label version swaps the tools behind the same engine.

If you embed it, price it from the start: how much production AI costs in SaaS.

07What we see in production

We have shipped all three paths: embedded, a separate product a software company runs for its dealers and a spin out from a working proof of concept.

A separate dealer product, when the inputs travel. A vertical software company serving dealerships had a problem its dealers felt directly: dealer websites offered only static forms and filters, while shoppers asked about towing, payments and follow ups. The company needed an assistant that talks like a salesperson, recommends real units from live inventory, qualifies the buyer and hands a complete lead to the dealer's CRM.

This passed the separate product test. Each dealer brings its own inventory and financing knowledge, and the software company runs the assistant on its dealers' websites. Our first flow let a general file-based agent read inventory files, and in the first sprint we replaced it with a dedicated inventory search fed by an hourly sync of each dealer's inventory. The result grounds buyer conversations in live inventory, dealership and financing knowledge, connected to lead capture, CRM and appointments.

An embedded assistant, when the value lives in the product's data. A property operations platform coordinates owners, managers and field staff around bookings, work windows, assignments, issues and supplies. Field staff often report by text and in different languages, and existing tools needed app installs and heavy onboarding.

Every useful answer depended on bookings and assignments the platform already owned, and the assistant already ran inside the live product, so we extended it there. We exposed its backend APIs as a tightly defined tool registry, so the model can act only through real endpoints. The result is an operations layer with role aware assistance, multilingual interaction, contractor outreach the owner approves and mobile task coordination, without a second permission model to keep in sync.

A spin out, when a proof needs its own buyers. A healthcare client had an AI patient intake we had designed with its founder, which worked in three practices but was built for one. The goal was a commercial product clinics could sign up for on their own, pay for, configure for their providers and run without seeing each other's data.

We kept the AI intake that worked and rebuilt the product around it. We chose a single database in one cloud for everything instead of syncing with the client's existing sign up system. We settled the roles and data structure first (super admin, clinic admin, provider, and no accounts for patients) before building any screen. The spin out work was tenancy, roles, onboarding and billing.

On a regulated investment platform, the same rule held: we added AI and automation through services around the existing core application and database, without replacing the regulated application.

Frequently asked questions