The killer AI app might only matter to you

The headlines keep looking for the killer AI app. By that, they mean something with a name, a launch, millions of users, and a business model that looks familiar. I think all those articles are making us miss a bigger change: AI is becoming a way to better use the software we already have and to create software that would never have made sense as a product. I believe these two ideas are fundamentally shaping this moment of AI, and, as a result, the enterprise software market.

On the first point, in his Dreamforce analysis, Ben Thompson described a profound shift in Salesforce's strategy. In 2024, Benioff's pitch was Agentforce: Salesforce's own agents doing the work. This year's keynote included a demo of a plugin that let people operate Salesforce from Claude and left you questioning why you would ever log in to your CRM again. For a company that built its business around being the place people went to manage customer relationships, that is a big concession. Thompson concludes his missive with as strong a review as you’ll read: “Interacting with software through ChatGPT or Claude is just flat out better than interacting with the software directly. It’s honestly hard to explain how much better it is if you haven’t experienced it, but it’s better enough that I felt compelled to write about Salesforce in a Daily Update!”

The bet is that Salesforce can remain valuable as the system of record even when you are inputting and reporting through other systems. Salesforce seems to believe the customer data, business logic, and permissions matter to keep you in the SFDC ecosystem.

That has implications well beyond CRM. Owning the record has always put software vendors in a strong position to sell the workflows around it. An agent that works across systems gives buyers more freedom to combine capabilities from different vendors and build the pieces specific to their business. The assumption that the vendor who owns the record also gets to own every workflow that touches it feels much more tenuous in a world where AI is the orchestrator.

We see this at Alephic: where we once had a CRM that managed contacts, opportunities, and other records, it is now replaced by Alephic Intelligence, which has all that information, plus pull requests, tickets, and just about everything else central to running the company. What makes the system particularly powerful is that while it has a UI, it’s secondary to its primary interface: Codex, Claude Code, and Slack. The system's data is a mix of records from other systems like HubSpot, Linear, and GitHub, which we enrich with AI. We serve all that data back out, in a shape that makes sense for our work, to whatever harness an employee prefers.

But beyond centralizing that data, the systems' power lies in the functionality we layer on just for us. We track every meeting and Slack message to spot escalations and commitments, tracking work in real time with permanent records. This has become an indispensable part of how we operate the company, but when we’re asked whether we would ever consider making it available to others, the answer is no. Alephic Intelligence was designed for us and only us. We believe it gives us a huge operational advantage.

Inside Alephic Intelligence: client cases organized by status, impact, urgency, and evidence. This is an interface to the database but the interaction with this data happens in your Codex, Claude Code, Slack, etc.

Put these together (replacing the CRM with AI and building software to solve narrow problems for single users or organizations), and the question for an enterprise buyer gets interesting. If AI can operate the software you already have, and help build the pieces you are missing, how much of your next workflow needs to arrive as another packaged application that someone has built for you and your competitors?

For years, buying enterprise software meant buying somebody else's idea of how work should happen.

You bought the data model, the screens, the sequence of steps, the reports, and a collection of features designed to serve enough customers to support a software business. Your team then learned the product and worked out where its process fit. Where it didn't fit, you configured, customized, customer success’d, or spent millions with a systems integrator to force it down everyone’s throats.

That bargain often made sense. Building and maintaining software was expensive. Sharing that cost with thousands of other companies was useful.

The compromise was all the work that happened between the products. Someone copied information from one system to another. Someone knew which document was current. Someone reconciled two reports before the meeting. Someone remembered that this customer, market, or campaign followed a different approval process.

A lot of that work was too specific to become a feature on a vendor's roadmap. It was also too small to justify its own software project. So people did it themselves, every week.

AI changes the economics of that gap, and I see two big themes emerging that will cascade across how we all work.

1. AI is the UI

AI is becoming an interface across existing systems. Instead of learning where every field and button lives, you can describe what you want to accomplish. With the right access and tools, the AI can retrieve information and carry out steps across applications. A CRM can remain the database of record even when you interact with it through an agent elsewhere.

That doesn't mean every screen disappears. A spreadsheet, a map, or a timeline can still be the best way to understand something. But the user shouldn't have to navigate five products simply because the information happens to live in five places.

Another example of AI as an interface: a sample meeting-prep request with the Customer Work skill selected. For the user, they don’t have to interact with any of this, they simply talk with AI and work with the data wherever they are

2. AI builds software for you, by you

AI can help create software for the parts of the workflow those systems don't handle. A small application can encode your team's rules, connect the relevant sources, and produce exactly the view or action you need.

These are separate capabilities, and together they widen the choices available to a buyer.

Consider a team preparing a campaign for launch. The brief lives in a document. The budget is in a spreadsheet. Approved assets are in a library. Feedback is scattered across messages. The launch date is in a project management tool.

Someone has to pull it all together and answer a simple question: are we ready?

A tool built for that team could check the current brief against the available assets, flag missing approvals, show unresolved feedback, and prepare a launch review. It could use the systems the team already relies on. It could follow the team's actual approval rules. People would still make the decisions that require judgment.

There may be no VC market for that exact application. Another company might organize the work differently. That has little bearing on whether it is useful to this team.

This is where the search for the killer app can mislead us. We are used to recognizing valuable software by how many people buy the same thing. Custom software can create value precisely because it understands the details that make one workflow different.

Those details already exist inside a company: its briefs, decisions, exceptions, approval rules, and the experience of the people doing the work. Making them usable is a substantial part of the job. Now, generating the code to make this happen is a tiny fraction of the cost.

Someone still has to own the software, test whether it works, manage access, and maintain it when the underlying systems change. A cheap prototype is not the same as a dependable workflow. Buying a proven product will remain the right choice for plenty of problems. Sometimes configuring what you already own will be enough.

But the choice deserves to be reopened more often.

For buyers, this opens up a more precise decision. Which system should hold the trusted record? Which capabilities can we use from it? Which parts of the workflow should we build ourselves? A CRM can remain essential without being the place where your team needs to arduously hunt and peck through their workday, all backed by a staff of 15 Salesforce admins to make it work.

Keep the shared systems that earn their place. Build around them where your workflow is specific. Judge the result by whether it reliably removes work, improves a decision, or helps someone finish a task.

Before buying another application, pick a process your team repeats every week. Look at the copying, checking, translating, and chasing required to get it done. Ask which parts could be handled by software built around that process.

The answer might be a small tool used by six people. It might never need a product name, a sales team, or a place in an app store.

It just needs to work for you.