For the longest time, companies have been trapped by enterprise software vendors.

First by shrink-wrapped software packages.

Then by SaaS offerings.

Both situations led to what one even in a SaaS world can call shelfware – although these days the shelf is a virtual one instead of a physical one. Buyers still get enticed to purchase more capabilities than they need, which leads to them paying more than necessary while often using software packages that offer overlapping capabilities.

One of the promises that SaaS started with, was to end this. Sadly, it looks like this promise was not kept. And this is no wonder; after all vendors want to be sticky. And they need to have increasing revenues. This means that they need to offer an ever-increasing number of capabilities, aka features, to warrant their pricing and eventually regular price increases. Combined with the frequently used strategy of offering related capabilities, i.e., seats for an adjacent software that is not yet needed by a customer, this led to two things: bloat and shelfware. Both go at the expense of the enterprise buyer.

Since the dawn of packaged software, the argument to buy, i.e., to voluntarily step into this trap, is the same: Buying is cheaper than building.

Which probably was correct. Buying from a specialist was the logical choice. Engineering talent was, and still is, scarce. Building software includes a lengthy process of requirements engineering, years of development and ultimately never-ending maintenance.

Just that most of this is true for most implementations of purchased enterprise software, too.

And the buying process is arguably broken. Need identification is often done without the right stakeholders, the software selection becomes a procurement-heavy process that is more based on checking boxes than in fulfilling user needs and the implementation turns out to be a death march. Who has not read – or at least heard of – the statistics that show implementation failure rates of more than 60 percent?

But then, who got ever fired for buying IBM, or Salesforce or SAP, for that matter. Or Oracle? Take your pick.

The result?

As a consequence, we see processes that are not improved or that not necessarily differentiate the company, as they are either implemented to follow the “same ole” or along “best practices”, which often translates to “average”, i.e., mediocrity. Users are forced to adapt to the tool, and not the other way round. Their pain is not solved. This, combined with shelfware, contributed to low adoption and shadow IT which ultimately harms all efforts of a digital transformation.

And it is costly.

Entry low-code, no-code and GenAI

Low- and no-code environments are basically there since, well … forever. At least as measured in Internet time. I had my first experiences with one back in 1995 (yeah, I am that old).

Depending on who got its fingers on these environments, results have been good or not so. Anyone remember the infamous Lotus Notes app graveyards? It needs guardrails.

However!

The combination of low-code, no-code and generative AI has the potential to reduce the marginal cost of software development to almost zero. Instead of engaging into a multi person year software implementation project, it is now theoretically possible to “vibe-code” a bespoke application in a short time and at low cost. The scarcity of IT personnel is mitigated, and the procurement process is no hurdle anymore.

At least theoretically. Again, it needs guardrails and the right tools for the right people.

Still, and this is important, it is now possible to create what one could call a throwaway MVP, or a working prototype, that covers a requirement’s happy path at almost zero cost. To be clear, this is a capability that we didn’t or only barely have with all the traditional low-code and no-code environments. And this is a big deal.

With this prototype it is possible to quickly identify whether a real problem is solved or at least mitigated; and this before big money is spent for the customizing and deployment of a new SaaS solution. This flips the procurement process to something for which one could use the term prompt-to-product.

A new paradigm?

As said, the traditional software procurement lifecycle: requirements identification → software selection → implementation is flawed. It relies on abstract and static written requirements. Text is ambiguous whereas software is explicit. The gap between a fuzzy, written requirement (e.g., "The system must support flexible workflows") that we see all too often and the delivered reality is where millions of dollars in enterprise value can get tanked.

With the help of Generative AI, it is possible to establish a methodology that moves the build phase to the very beginning. It serves not as the delivery mechanism, but as an agile discovery tool in a three phased process.

Phase 1: Dynamic Discovery

Instead of collecting stakeholder needs in a static document, this process begins with live prototyping. Business stakeholders work with an AI engineer or directly with an LLM-enabled no-code environment to describe their problem in natural language, rapidly developing a working prototype that supports the happy path to the desired outcome. This is agile development on steroids. The prototype does not need to be secure or scalable; it only needs to fulfill the job and be interactive. As a result, it becomes very clear what the users actually want. Plus, some implicit requirements get surfaced early in the process instead of after the purchasing decision and project budget assignment.

Questions like “Does the user actually want a dashboard, or just a daily email summary?” or “Does the data structure actually fit the way the team works?”, and more, are answered before they require costly change requests.

Phase 2: Stress Test

After the prototype solves the business users’ pains, IT leadership is in a better position to decide whether to buy, build, or opt for composing a low-code solution. Based on the assumption that the existing software packages do not cover the requirements, this decision can be taken by answering three main questions based on the generated code.

• Does this tool need to read/write to business-critical system like the ERP, or does it live in isolation?
• Does the logic involve high-liability calculations (tax, payroll, health data)?
• Is the logic static, or will it require constant updates based on external factors (e.g., changing shipping tariffs)?

Phase 3: Strategic Fork

Based on the answers, the organization moves down one of three paths. Crucially, the outcome of phase 1 is valuable on all three paths.

Build

If the prototype is self-contained, low-liability, and specific to the company’s internal operations, the decision is to build.

The prototype code gets refined to cater for edge scenarios and for compliance and security, if the development environment of the prototype didn’t already take care of these. After that, it can get deployed.

Because the cost of generation stays at near zero, the resulting software is disposable. If the process changes over time, the application is not patched but simply discarded and regenerated.

As a result, the company has a solution with perfect process fit, low implementation cost and zero licensing fees.

Buy

If the prototype reveals that the requirements are more complex than anticipated, for example, if there are more regulations to consider, the decision is to buy. In contrast to the traditional process, this is now an informed decision.

The organization stops building but uses the functional prototype as a key part of the RFP that demonstrates the desired process. The conversation shifts from "Can you meet our requirements?" to "Here is exactly how our process works; demonstrate that your software can replicate this specific behavior."

The result is risk mitigation for both the company and the winning vendor. The prototype proves that building potentially creates unmanageable technical debt. It also prevents buying vaporware by forcing vendors to prove capability against a live model. For the vendors, it takes away considerable uncertainty in assessing the project size.

Compose

If the prototype requires the flexibility of custom logic but the governance of a standard platform (Microsoft, SAP, Oracle, Zoho, Salesforce, etc.), the decision is to compose it using a low-code environment.

The AI-generated logic gets transferred to an existing low-code/no-code platform. This platform handles identity management, UI standardization, and hosting, while the generated code still handles the unique business rules.

This enables speed of deployment with the safety net of IT governance.

What does this mean?

Executives should flip the purchasing process using three key actions.

• Provide an infrastructure that allows for rapid, AI-supported prototyping, aka vibe-code environments. Ideally, this environment already embraces security and compliance rules.
• Train users, business analysts or IT personnel to use this environment to bridge the gap between business and AI.
• Instead of asking for written requirements only, make it the creation of prototypes in this environment that serve as core elements of the demand mandatory.

This flipped process opens the build vs. buy question to no longer being binary. It creates a build-to-define process that ensures that the decision of how to deliver required functionality in a better informed, de-risked way that has a higher chance for success at lower cost. It isn't killing SaaS but stopping to buy hope. Low-code/no-code in combination with GenAI can help to know more exactly what gets delivered, regardless of whether you build or buy.

My past two column articles on CustomerThink dealt with how to determine the return of agentic investments and whether agentic AI delivers at all.

The question of ability to deliver is particularly interesting for me, as I am researching measurable results other than cost savings in contained business areas for some months now, and regularly find a very strong focus on customer service and marketing, with customer service functions being best able to report measurable results. This is evidenced by the number of success stories I find, supported by the publication of a recent TEI of Zendesk customer service study. 

However, most of this is anecdotal evidence, or vendor sponsored/commissioned. And which vendor likes to speak about failures? Similar for buyers who understandably do not like to be in the spotlight with investments that turned out to be less than successful. There hasn’t been too much in depth research on whether generative and/or agentic AI deliver to promise or not. 

Luckily, there has been at least some research evaluating the capabilities of LLM based AI agents in business environments published this year. CRMArena-Pro by Salesforce Research naturally has a focus on CRM tasks across B2B and B2C scenarios. The authors identified nineteen tasks commonly executed in CRM systems and categorize these tasks in the four business skill categories database querying and numerical computation, information retrieval and reasoning, workflow execution, and policy compliance and includes a confidentiality awareness evaluation. TheAgentCompany on one hand covers a wider area along the business value chain but on the other hand has a narrower focus on software engineering companies. One other main difference between these two studies is that TheAgentCompany has a focus on more complex tasks that require multiple steps for their execution.

Both studies find that LLM-based agents deliver in simpler contexts while they are still failing in more complex ones.

Not that this comes as a surprise.

While this consistent result gives an indication on what scenarios to avoid, there is little help in what actually to do – besides of starting with simple scenarios and to focus on workflows. 

This is where a recent study from the MIT NANDA project gives additional insight. The study, titled “The GenAI Divide – State of AI in Business 2025” starts off with a quite unsettling finding: Only five percent of organizations are extracting value from their integrated AI pilots. The rest – a staggering 95% - doesn’t receive any measurable P&L impact. 

Why? 

According to the study, the problem is the missing ability of integrated systems to retain feedback, adapt to context, or improve over time.

That’s a big ouch, given that enterprises often invest multi-million dollar budgets into these initiatives.

This is also in stark contrast to what emerged as shadow AI. About 90% of all employees are using privately purchased licenses for ChatGPT, Perplexity, Claude, or other tools

Figure 1: The steep drop from pilots to production for task-specific GenAI tools; source The GenAI Divide

And they are happy with how these consumer-grade tools help them in their work environment. So, apparently, employees are convinced that genAI tools can and do help them in their work environments.

So, the important thing is not to cry out failure but to identify what businesses and vendors can do to make investments into generative and agentic AI a success. The GenAI Divide – State of AI in Business 2025 gives plenty of insight for both. 

So, let’s have a look under the hood of this report

What can buyer executives do?

First things first, buy, don’t make. This doubles your chance for success.

• Look at the right problem and use the right KPIs. A lot of budget, around 50% of it, is sunk in sales and marketing. While this seems sexy and results can be showed off with easy to gather (and misattribute) KPIs, the real gains seem to lie in back office automation. To mitigate the still existing weaknesses in the automation of complex, start simple. But think big. This is corrobated by the findings of both earlier studies, TheAgentCompany and CRMArena-Pro.
• Look at the right partners. Do not only rely on artificial benchmarks but on business outcomes. The world of AI is different from traditional SaaS. AI is service as a software, so consider your vendors outsourcing partners instead of software partners. Have them prove that their AI tools can be configured to your needs – and hold them accountable.
• Usability and flexibility are key. One of the core reasons for the success of tools like ChatGPT, Perplexity, Claude or Gemini is the simple user interface plus their ability to be guided through the problem-solving process in conversations. These conversations resemble iterations and are regularly the way humans work. Technologies like RAG and RAC help, but still need improvement. Again, start with the simpler problems and go from there.
• Trust your people. Your employees do know what they need. This is abundantly clear through their use of privately sourced AI tools. Do not centralize AI initiatives but have them driven where they matter while providing a meaningful yet robust set of guidelines.

Plus, here’s a bonus tip: All the above is particularly important for enterprises. As opposed to SMBs, enterprises tend to be more vulnerable to internal politics. For the sake of sustaining success, this should be avoided.

What should vendors do?

Vendors should have a close understanding about what their clients are – and have a hard look at what they actually need and want. GenAI and agentic AI are the shiny new tools, still, they need to solve actual business problems. This means that it is important to not build generic tools but solutions that are capable of embedding themselves into business workflows, improve them. This requires a strong focus. Grow from there. If the big, established vendors don’t do that – there is a startup that is capable of disrupting them and eating their lunch. Start with solutions to problems that are not business critical, and extend from there.

One of the major complaints that users have about the tools at hand is that they do not learn and are too rigid. So, genAI tools need to incorporate learning mechanisms that help them to learn via supervised, or unsupervised, means. They also need to provide a context window that is big enough for the complexity of business challenges that are addressed. Lastly, even if a process looks the same, it often isn’t. As a consequence, build in a deep ability for configuration, maybe even customization.

A bonus tip for startups. Many a buyer does not even consider you. They don’t know you, they don’t trust you. Heck, they don’t even know whether you’ll be around tomorrow. So, your best bet to get into larger accounts is by partnering up with vendors or consultants that your buyers know and trust.

Vendor or buyer. Do you need some help? Give me a call. I am there.

It is not that uncommon that a software company creates new software based upon customer requirements. Actually, this is the way things should be done; not exclusively, but to quite an extent.

Now, there are few software vendors who are truly independent. Most vendors are, and need to be, part of one or more other vendor ecosystems. This is simply a matter of scale, as there are only a few vendors who have the size and market power that are necessary to surround themselves with a good number of customers, ISVs, system integrators and other partners. And the number of these ecosystems is rather shrinking than growing. 

What this means is not that these few companies can implement and deliver what they want, but that the other ones need to carefully check two things.

First, which ecosystem(s) to belong to, be it one or more than one. And as the CEO of 3CLogic, Denis Seynhaeve in a recent CRMKonvo said: It is important to choose wisely, which ecosystem to commit to.

One of the fundamental consequences of this decision is the degree of dependency on other vendors that the smaller vendor has. This degree naturally decreases with the number of ecosystems it participates in, although they can never be truly independent - which is also not wanted when playing the ecosystem game. Conversely, participating in more than one ecosystem increases options and the potential reach.

On the other hand, there are some other factors that come into play. The software architecture and the software itself will become more complicated when different vendors’ systems shall get augmented. Deep knowledge in different technologies is required, if deep integrations are necessary. As a consequence of all that, the implementation and maintenance become more expensive. This has an adverse impact on pricing.

Different vendors at the core of an ecosystem prioritize the functionalities they deliver differently. This means a vendor that engages into enhancing core solutions cannot necessarily guarantee an equivalence of functionality across platforms, unless extending it outside the platform and integrating via APIs. While this is a viable option, it increases the complexity of the system architecture at the customer.

This is precisely where the wise choice that Denis spoke of comes into picture.

The choice is about which ecosystem or ecosystems to join.

And there is definitely a value in focusing on one ecosystem. One of these values is time to value for customers.

Let me provide you with an example of a company I regularly interact with at this point. The company is called Fastcall and builds CTI solutions that extend Salesforce. Fastcall is a so-called ISV (independent software vendor) and has fully committed to the Salesforce stack. Being a Salesforce-only provider, the company is by definition dependent on Salesforce but tied its success to the success of the Salesforce platform. Its management pays particular attention to Salesforce’s new feature releases. Those that show promise to add value to their customers then may be adopted in their solution. This can be started as early as the new feature is in a Salesforce beta program.

For Fastcall, this has several advantages. These range from being able to work within the Salesforce stack to being able to quickly leverage new features that are offered by Salesforce and to turn them into more value for mutual customers. One of these features being the Einstein Conversation Insights, which got released at the end of March 2021.

Einstein Conversation Insights is a framework that can be used to analyze call recordings to find predefined keywords and to obtain some metrics. One of the important aspects of this framework is that it is agnostic to the source of the call recordings. This means that it can be easily used by partners like Fastcall by simply uploading a call recording and getting results in return.

Well, this somewhat simplifies things.

Still, looking at the example of Einstein Conversation Insights, Fastcall was able to build, QA and deliver an integration with this new Salesforce functionality in less than a month. Fastcall recordings are made available to Einstein Conversation Insights in real time, which in turn delivers useful insights into the recorded conversation.

The message here is that partners who focus on one particular ecosystem, in this example Salesforce, can react with tremendous speed to offer more value to their customers. Especially, if these partners are smaller, they can, and usually do, prioritize their developments closer to the needs of their customers, which are often smaller in nature, too.

Earlier, we spoke of wise choices. What could be wiser than aligning product development to the needs of one’s customers?