Blog

The "AI Feature Value" conjecture for B2B SaaS

October 13, 2025 | ai |

An AI feature or an Agentic AI workflow only creates value within a product based on two properties: Data Locality and Data Assembly.

That is, there are tons of valuable uses for LLMs, but the continued growth and improvement of open-weight models and self-hosting means that most AI features will be runnable locally or within private networks in the future.

Thus, for a product to charge money for an AI feature specifically, the product must possess a rich and unique data locality, and/or the AI feature must comprise a rich and unique data assembly.

Data Locality

If the product contains a unique set of (customer) data, then there is value in using an LLM to interact with that data.

This is analogous to paying a premium for a bottle of water at the airport or the stadium. The provider has created a valuable environment that the customer can't (or doesn't want to) create and maintain on their own, and the customer pays for additional enhancements to their experience there.

In this sense, the richness of the environment already existed before the AI feature was added. The AI feature is simply another way to monetize the asset.

Data Assembly

If the AI feature takes data sources and transforms or distills them in a non-trivial way and combines them with external sources or knowledge and manipulates the result in an iterative or compounding way, then the result has value and, by extension, so does the data construction, or assembly. The key to such an AI feature is that it decomposes the problem in some arbitrary domain into fundamental patterns and relationships of information, which is the language learned and spoken by LLMs.

Effectively, an AI feature getting paid for data assembly has found a unique or novel translation of a problem into its “information relationship” primitives.

Of course it can't be faked. Manipulating data through a sequence or graph of 100 different prompts has complexity but not necessarily value. The entire workflow must be coherent, novel (or at least unknown) and align to the fundamental patterns of the domain.

Analogously, a client brings all of the facts (theoretically 😄 ) to their attorney who organizes the data into a coherent argument. The lawyer gets paid to take raw data and translate it and decompose it into logical units that align with the universal truths of the domain.

Examples

Snowflake is an example of a product that charges, literally, for the value of data locality. They could add an AI Chatbot feature that has a minimal prompt “wrapper” and it would still create value for their customers. Customers use Snowflake specifically to bring all of their data together; they don't want to pay the network bandwidth and latency cost to extract their data just to use their own LLM.

GitHub is an interesting case. On the one hand, they have your source code—a really valuable data set. On the other hand, every developer on the team has that same data set locally. So, it's not uniquely residing in GitHub. If GitHub rolled out an AI Chatbot to “talk with your code”, it would create minimal value for developers since they can bring their own LLM directly into their IDE and talk with the codebase locally. However, you could imagine non-developers (PM, Support, and others), who don't have the source code locally, would find value in being able to understand and learn the system by using an LLM to intelligently interact with the source code.

From a different angle, GitHub's Copilot Code Review agent gets paid for its data assembly; it creates value by intelligently decomposing and structuring the task of code review.

Similarly, Devin is an example of AI that has value due to data assembly. They've hit on a secret sauce (for now) for how to decompose the task of implementing features in a codebase. The customer has all of the data (source code, tickets, docs, etc.) already themselves, but they can't (or don't want to) figure out how to organize the data and decompose it into foundational units of information that the LLM can understand and manipulate.

Of course, the risk to making money on Data Assembly is that the world might eventually figure out the decomposition and then everyone can replicate it locally for use with their own LLMs. This suggests that the most defensible problems to attack with LLMs are the most complex ones.

What's an example of an AI feature that doesn't create value? The quintessential example of an AI Feature that lacks locality and assembly is the AI chatbot enabling interaction with application account data, which is already visible in the UI. Many SaaS platforms were quick to release an AI chatbot in the early days of LLMs so they could say their product was AI-enabled or AI-powered. In CRUD-based SaaS applications, the data itself is generally not rich enough to create value simply by making it interactive, or chattable. And on the assembly side, the AI chatbot has basically no workflow or structure, aside from basic steering or guards. Most organizations today realize that their AI features need to do more than simply make things chattable.

As a good rule of thumb, if the product doesn't possess a rich and unique (customer) data set, then the team must put in the work to build a valuable Data Assembly approach in order to create value with an AI feature.

Summary

The best way to judge an AI feature or workflow is to ask: What is the customer paying for? It must be either:

  • The rich data environment that will be exposed to the LLM (good!), or
  • The proprietary data preparation and assembly performed before presenting it to the LLM (great!).
If it's both, then that's the golden egg-laying goose (🤑). If it's neither, then it's back to the drawing board (😔).