Building an ISV App in the Age of AI (Part 1)

This is the first part of a two part series looking at how to survive and thrive as an ISV in the AI era. I am using Salesforce as my example because it is the platform I know best after 12 years....

The ISV game has always been a strange mix of opportunity and dependency.
You get the reach of a massive platform, the credibility that comes from being in the ecosystem, and a ready made way to sell to customers who already trust that platform. But you also live in someone else’s house. You can decorate your own room, but the plumbing, the wiring, the neighborhood rules, those are not yours to change.

And right now, the landlord is renovating.

This is the first part of a two part series looking at how to survive and thrive as an ISV in the AI era. I am using Salesforce as my example because it is the platform I know best after 12 years of working closely with it and its partner ecosystem. But what I will share here applies just as well to Microsoft, HubSpot, AWS, Oracle, or any other platform.

I like the platform and I have seen firsthand how much value it brings to ISVs. What I am doing here is taking an honest look at the reality of building an AI first ISV product in this kind of environment. And I believe the same shortcomings and challenges apply across platforms.

In this first part we will talk about the model, the structural constraints, the architectural decisions, and the technical realities. In the second part we will go deeper into the product management side, from market analysis to execution and go to market, and the mindset it takes to succeed.

The ISV Model and Why Platforms Need Them

An Independent Software Vendor, or ISV, is a company that builds products on top of another platform. Think Microsoft, AWS, HubSpot, Oracle, or Salesforce.

ISVs are the specialists. They go deep where the platform can only go broad. When I ran Partner Relationship Management at Salesforce, our scope was huge. We covered partner recruitment, onboarding, training, certifications, co-selling, co-marketing, analytics, pretty everything Salesforce core had to offer. We could not possibly build every specialist feature ourselves. That is where ISVs came in.

We partnered with loyalty management vendors like Fielo, learning management systems like Appinium, and CPQ vendors before we acquired SteelBrick. They did not just bolt something onto Salesforce. They filled real gaps. In return, we gave them credibility, visibility, and a spot in deals where their feature was the missing puzzle piece.

The Salesforce AppExchange is the main street for this relationship. If you are not there, you are invisible to most Salesforce buyers. But here is the catch. Your product lives by the platform’s rules. It runs on their APIs. It fits inside their pricing and packaging structure. If you need a usage based billing model, something AI makes more relevant than ever, you cannot do it today. It is seats or nothing.

Salesforce Constraints and Realities

Salesforce is a great platform, but it is also a very opinionated one. If you are an ISV, that matters. You are not building in a vacuum. You are building inside a structured environment that shapes what you can do, how you can do it, and even how you get paid.

First, your entire product relationship with Salesforce runs through the APIs. That is your oxygen supply. You breathe it in every time you read or write data. But like oxygen, it is regulated. API limits dictate how much you can do, and certain features are off limits unless Salesforce decides to expose them. And even when the APIs are available, you have another layer to navigate: cloud and sub cloud dependencies.

A CPQ app assumes the customer actually has Sales Cloud and the CPQ add-on. A customer service assistant assumes they have Service Cloud and access to Cases. The licenses your users hold determine which objects and data models you can work with, and therefore what your app can actually do. That is a hard limitation unless you fully custom build your own model (custom objects).

Then there is the money side. The Salesforce ISV program only supports one core monetization model, seat-based pricing. That works for traditional workflow software. For AI it is a square peg in a round hole. AI usage varies wildly by customer and by workload. Some customers might hammer your app ten times more than others, but you cannot meter and bill for that. There is no native consumption based billing for ISVs today.

And remember, you are a guest in Salesforce’s house. They can decide tomorrow to build their own version of your killer feature. I have seen it happen. When Salesforce launched Loyalty Management, my partner Fielo went from must have to competing with Salesforce on every deal overnight. Even though their solution was proven, superior, and a fraction of the price, they struggled to win against Salesforce and their army of AEs.

Finally, the ISV partnership economics matter. Yes, being on the AppExchange gives you credibility. Yes, certification matters. But Salesforce takes a meaningful revenue share, and in SMB or mid market deals, that can hurt. And while you will get a Partner Account Manager assigned, they are often juggling a huge roster of partners. Unless you are in a hot category or driving significant deal flow, you will mostly get the standard playbook.

Salesforce, like other big players, gives you reach and trust, but it also boxes you into its architecture, pricing model, licensing realities, and competitive priorities. In the AI era, those constraints matter even more.

Ease of Deployment, Setup and Control

One of the biggest strategic questions for an AI driven ISV right now is, how tightly should you couple yourself to Salesforce.

The default ISV instinct is to go all native. You package everything into a tidy AppExchange listing, make it look and feel like Salesforce, and let customers install it with a few clicks. It is neat, familiar, and plays by the Salesforce way.

But in the AI era, that may not be the smartest choice.

When you build fully native, you inherit every platform constraint. Your UI must follow Lightning rules. Your admin setup must fit Salesforce configuration patterns. Your release cycle syncs with theirs. And if you want to make a major change, you are back in the packaging, security review, and upgrade management loop.

With AI, speed and flexibility matter more than ever. Models are evolving fast. Features you thought you had months to plan may be needed next week. The last thing you want is to be stuck waiting for a release cycle while competitors ship updates monthly.

This is why some ISVs are using to a looser model. Keep the Salesforce integration, but run the core app outside of it. Think of a single page web app hosted where you choose, with SSO (Single-Sign-On) for Salesforce users. Pull in Salesforce data through APIs. Push insights back into Salesforce where they are useful. You still integrate, but you own the product experience, the UI, and the release cadence.

The beauty of this approach is that you are not painting yourself into a Salesforce only corner. If you want to support HubSpot, Microsoft, or Zoho in the future, you can. If Salesforce changes in ways that do not work for you, you can adjust without starting over.

You lose a little of the instant install magic, but you gain speed, control, and the freedom to grow beyond one platform.

AI Disruption: The Rules Just Changed

AI has not just nudged the ISV world forward. It has turned the table over and scattered the pieces.

A couple of years ago, you could build a solid Salesforce app, plant your flag in a niche, and improve it steadily. If you solved a real problem and stayed close to the platform, you were in a relatively safe spot. Not anymore.

Customer expectations have shifted. Tools like ChatGPT, Claude, and Google Gemini have trained everyone to expect software that thinks with them. If your app is not proactive, contextual, and somewhere “intelligent”, it feels dated. A nice dashboard will not impress anyone anymore.

Here is the challenge. Salesforce’s AI features are built for Salesforce products first. Agentforce, Copilot, embedded assistants, these are aimed at customers, not ISVs. Yes, you can extend them. But building a deep, AI native product on Salesforce today means living with evolving APIs, shifting capabilities, and an unstable foundation for long term bets.

And if you think you have found a perfect AI opportunity in Sales Cloud, Service Cloud, or Marketing Cloud, be careful. That white space may exist only because Salesforce has not yet gotten to it. If they decide to prioritize it, they will move fast and own it. You might have a year or two of head start. Then you are competing with the platform itself.

On top of that, AI itself is volatile. Building agents inside Salesforce comes with constraints you would not have on a platform like AWS Bedrock, where you can plug in any LLM or service you want. On Salesforce, your choices are narrower and tied to what the platform supports. That will improve over time, but it is still far from being a fully open and composable AI platform (same applies to many platforms).

So yes, you can build an AI first ISV on Salesforce today. But you will do it in a fast shifting market, with pricing that may not fit your usage model, and with a platform that can be both your biggest ally and your toughest competitor.

The Data Layer: What Powers Your AI

There’s one thing we haven’t talked about yet, and it might be the most important if you’re building anything with AI: Data.

Every AI-powered product, whether it's a chatbot, a smart assistant, or a predictive engine, needs data. And as an ISV, you have two options.

The first is clean and simple. You build a product with its own custom data model, and your customers generate data by using the app. That data stays inside your system, and you train your AI on it. This kind of self-contained loop is the easiest to control. You know the structure, the volume, and the context of the data. You’re not relying on anyone else to make it available or understandable. The integration with Salesforce or any other platform becomes a UI or workflow connection, not a dependency on data access.

But the second path is more complicated. That’s when your app needs to use data that already exists in Salesforce. Maybe you want to build an AI assistant for customer service. Maybe you want to analyze historical sales activity. Maybe you want to auto-suggest field inputs based on past cases. Whatever the use case, now your app needs access to customer data that lives outside of you.

One option is to fetch the data directly. Read the records, build your own layer for analyzing them, and generate insights or automation based on that. Many AI chatbots do this today. I recently installed one on Shopify for The French Cookie Guys, and it automatically scanned all my product listings, metadata fields, and even the site content to create a smart FAQ. It consumed and structured the data as a foundation for a better AI interaction layer. That’s a good example of making your own data layer, even if you didn’t own the original data source.

But let’s say you want to an agent on AgentForce. Now it gets tricky.

Salesforce agents are designed to run on top of the Data Cloud (or at least that’s what is being promoted, there’s little documentation about it). If your customer doesn’t have Data Cloud, you’re stuck. Even if they do, the specific data you need may not be available there. And even if it is, it may not be in the right format, or have the granularity and quality your app requires. You’re suddenly depending on your customers to provision, structure, and sync data in a specific way before your app can be useful. That’s not a great onboarding experience.

Did I mention security? Do you need granular access to data? My advice is to read the Data Cloud security documentation and see if it fits your needs.

This is why your data strategy matters. What data do you need? Where will it come from? How will you keep it current? And how do you ensure your app continues to deliver value as data evolves?

It’s not just a technical detail. It’s a core part of your product design.

Conclusion

What we have done here is take a look at the ISV landscape in the AI era. We have covered the model, the realities of working on a leading platform like Salesforce, the architecture trade offs, and the technical and competitive risks. This is the context you need before making product decisions.

In Part 2, we will shift into the product management perspective. We will talk about how to analyze your market, how to design for impact, how to build in a way that protects your flexibility, and how to go to market in a crowded ecosystem. We will also talk about the common mistakes to avoid and the mindset you need to lead with confidence.