For builders and investors of AI app companies, there are two frequently posed and equally defeating questions that the industry cannot seem to shake: Won’t the model providers build this? And, is this a ChatGPT wrapper?
Two and a half years into founders building on LLMs, an obvious third question has emerged: Who cares?
To be fair, the answer right now is everyone. The argument on whether to build or invest at the AI app layer has been hotly debated. Countless blog posts have been written on the rise and predicted success of vertical AI (including from us). Still, OpenAI’s recent ChatGPT Agent release is the latest example of a model provider’s new feature sparking a flurry of panic and swinging sentiment the other way. If OpenAI can do it, doesn’t that make any derivative software a commodity?
While Silicon Valley is busy coining every release from model providers as a “startup killer,” we seem to be forgetting one fundamental truth that’s been proven over and over again: great technology does not on its own produce great products.
It is so easy to build software right now that people seem to be forgetting what the software is actually for. The act of writing code used to force engineers to think about implementation at every step. Now, as a growing percentage of code is AI generated, roughly-written natural language prompts often outsource core product decisions to an LLM. That’s a lot of agency to hand over to an agent.
Much of today’s AI tooling is designed around what a model can do. Software that truly resonates, on the other hand, starts from a different premise, the one that is tried-and-true and has built many greats before: “What is the user trying to do?” The difference is small, but critical, and it’s where great applied AI products are starting to shine.
There will be companies from the AI boom that succeed based on doing something truly technically innovative, and just as many, if not more, that will succeed by becoming a beloved product. And just like in previous eras, that could very well require embracing the “commodity” label.
The case for commoditization
Over the past year, nearly every function of products built on LLMs has been accused of heading toward the commodity bucket, and it’s not just at the app layer. GPU Clouds, podcast generation, legal evidence synthesis, medical note transcription… you get the point. The implication is clear: if the core functionality can be replicated by a general-purpose model, the product must be undifferentiated and fragile.
However, commodity does not have to be a bad word. Oftentimes, building around a commodity means that you’re building something important where the use case is obvious and the customer pull is strong. Your job is now to build and sell the living hell out of it.
Salesforce didn’t win because CRM was novel. It won by shifting delivery to the cloud and out-executing legacy players like Oracle and Siebel. Zoom, too, was not the first video conferencing tool. But it outpaced incumbents like Skype and Google Hangouts by focusing relentlessly on low latency, clean UX, and frictionless onboarding. Both were built in “commoditized” categories but resulted in enduring companies. In fact, most great software was (and, I would argue, still is!).
There are endless examples of notable companies that could have once been written off as commodities, simply because the core technology they are built on existed in the market prior to their founding.
Product excellence as a differentiator
The truth is, functionality alone did not hurdle these companies towards success. Product is what turns technical commodities into systems that people trust, adopt, and return to.
Great product builders excel at identifying what a user is struggling to describe, or, even better, anticipate it, and then shape software that reflects those latent workflows. This is not trivial work. It requires understanding how flow manifests in the context of software. There is a mapping of intention to interaction that is scarcely instantiated into data a model could consume. This takes taste, time, and actual proximity to a problem.
That kind of understanding doesn’t come from better prompts, context, or model routing.
As the cost of software development decreases, it has become viable to build focused products in places where purpose-built software simply didn’t exist before. The tools are finally here to make great, domain-specific software possible at scale. These products excel not only due to AI functionality, but because they deeply understand a user’s workflow. For example, recording and summarizing audio is a bread-and-butter LLM capability. Applying it to the medical field, Freed is creating templates that support the differences in what specialty doctors need, building the tool around the workflow instead of making the workflow accommodate the tool.
Products can also win when they create exceptional user experience. These are products that are not only functional but are deeply attuned to the people who use them. That process requires an unusual degree of care. It truly is what distinguishes the merely functional from the beloved. Granola, for example, has garnered a cult following after making a core product decision to not have a clunky assistant “join” Zoom meetings. With LLMs accelerating foundational engineering work via automation of documentation creation, code generation, migrations, etc., teams should finally have time to polish their products. User delight, the OKR that no one can measure so no one can chase, might finally regain a spot at the table.
We’re already seeing magical product experiences pay dividends for those who invest the time to build them.
So, no, your AI app doesn’t need to be defensible because of your use of AI. If you don’t have a technical moat, that’s fine. Let the commodities be commodities. The greats will be determined by the same principles that have always defined great product: usability, empathy, iteration, and taste. Some of those will have a great technical moat, but many will not! And the need for product, not just commodity tools, is far from going away.
As AI becomes embedded across the software development process, the temptation will be to ship faster, automate more, and let the model define the product. However, in a world of commodities, good product feels just as good as product has always felt. So yes – maybe you’re building a GPT wrapper. But if it’s intensely sticky and indispensable to your user… who cares?
If you’ve used a great product recently or are building something magical, I’d love to hear about it and try it out myself. Drop me a note at sabina@scalevp.com.
