Inside Software 06.14.26: If Everyone Has the Same AI, What Makes You Different?

Jun 15, 2026

Every other week we’ll provide updates on the latest value levers and trends operators are asking us about in Technology and Software. If there are things you want to hear more about - shoot us a note.

Pre-emptive apologies. This one is a bit longer; my colleague Dave Mortlock in our Media Practice and I needed to make sure we hammered the right points!

At Microsoft’s recent CEO Summit, Satya Nadella used a phrase that should be stuck in every software CEO’s head: every company needs its own “hill-climbing machine.”

His point, translated out of keynote-speak, is pretty simple. Everyone is going to have access to great foundation models. Everyone is going to have copilots, agents, chat interfaces, tool use, memory, orchestration, and increasingly good AI infrastructure. So the question is not, “Do we have AI?” Congratulations, yes, you and everyone else.

The better question is: what do we know, measure, and improve that others do not?

That is where this gets uncomfortable for software companies. Because the same AI that helps you build internal tools faster also helps your customers build internal tools faster. The same AI that lets your team create a contract review agent, a customer support triage bot, or an FP&A variance explainer also lets your customers ask a very dangerous question:

“Why are we paying for this if we can build an 80% version ourselves?”

That question is going to show up more often. Not everywhere. Not for every category. Not for every buyer. But often enough that software CEOs should be paying attention.

To be clear, building 80% versions of internal apps can be useful. We are seeing clients do it. They are automating workflows, reducing manual work, replacing clunky point solutions, and cutting spend in places where the software was never that differentiated to begin with. Fantastic. Nobody is crying for the expense report tool that required three approvals and a blood oath.

But here is the trap: if your AI strategy is mostly “we can build cheaper versions of other people’s software,” you should assume your customers are thinking the same thing about you.

So the CEO question is not just: how do we use AI to reduce cost?

It is: how do we use AI to make our product harder to replace?

The three layers of AI advantage

A simple way to think about this is to separate the stack into three layers.

Layer 1 is the model. Hugely important. Also increasingly available to everyone.

Layer 2 is the vendor harness. This is the interface and tooling wrapped around the model: chat, memory, search, tool use, code execution, planning, integrations, and agent orchestration. Also important. Also rented.

Layer 3 is where things get interesting. This is the company-specific layer: the context you bring, the workflows you understand, the decisions you optimize, the data exhaust you capture, the evals you build, and the feedback loops you run.

That is the hill-climbing machine.

A company’s AI moat is not “we use the best model.” That is like saying your 1999 internet strategy was “we use browsers.” Great. Bold.

The moat is the system that gets better every time customers use it, experts correct it, and the product learns what “good” looks like in your category.

The 80% app trap

We are seeing two AI agendas emerge in client conversations.

The first is the “build a bunch of apps” agenda. This is the team that says, “We can build our own internal version of vendor X.” Sometimes they are right. Internal tools that were expensive, underused, generic, or lightly integrated are now vulnerable. AI lowers the cost of building good-enough workflow software.

That can be a great productivity move. It can also become a giant distraction.

Because building internal 80% apps is not the same as building a proprietary moat. It is often just cost takeout. Useful, yes. Strategic, maybe. Differentiated, usually not.

The second agenda is harder and more valuable: using AI to make the core offering more distinctive, more outcome-driven, and harder for customers to replicate.

That is where software leaders need to spend more of their oxygen.

If you are a vertical software company, the goal is not to add a chatbot to the product and call it a day. Everyone is doing that. The goal is to encode what makes your category hard: the exception logic, the regulatory nuance, the customer benchmarks, the workflow history, the expert judgment, the outcomes data, and the evals that define superior performance.

If you are a horizontal workflow platform, the goal is not to summarize tickets, draft emails, or generate dashboards. Again, everyone is doing that. The goal is to know which ticket actually matters, which escalation will churn a customer, which forecast variance is signal versus noise, which approval can be skipped safely, and which workflow pattern produces better outcomes.

That is much harder to copy.

What actually makes software proprietary?

The word “proprietary” gets thrown around a lot. Usually right before someone shows a feature that will be in every competitor’s product by next quarter.

So let’s be more precise.

Your AI moat is probably not the prompt. It is probably not the wrapper. It is probably not the fact that your product now has a sparkle icon next to the search bar.

The proprietary layer is usually some combination of:

This is the important shift. In the last software era, the moat was often workflow depth, integrations, switching cost, data, and distribution. Those still matter. But AI changes the shape of the moat.

The new question is: can the product learn faster than the customer can rebuild?

If the answer is yes, you have something. If the answer is no, you may have a very nice UI sitting on top of a workflow your customer is already trying to automate around.

Example: field service software

Take field service management. A customer might use a vendor to schedule technicians, manage work orders, optimize routes, track parts, and communicate with customers.

Now imagine the buyer’s internal team builds an AI agent that reads service requests, checks technician availability, pulls route data, drafts customer updates, and summarizes work orders. Is it perfect? No. Is it suddenly good enough for some workflows? Maybe.

If the vendor’s value is mostly forms, scheduling screens, and basic automation, that is not a great place to be.

The durable moat is deeper. The best field service product should know what a good dispatch decision looks like across thousands of jobs. It should learn which technician is most likely to solve a specific issue on the first visit. It should understand parts availability, warranty exposure, customer priority, SLA risk, travel time, regional constraints, and historical resolution patterns. It should have evals for first-time fix rate, margin per job, technician utilization, customer satisfaction, and avoidable truck rolls.

That is not just an app. That is an operating brain for the workflow.

Could a customer build an 80% version of the screens? Sure.

Could they replicate the outcome intelligence, benchmarks, feedback loops, and decision quality? Much harder.

That is the difference.

The durability lens

This is where software CEOs need to get more disciplined. Not every AI investment has the same shelf life.

The most common mistake is overinvesting in the bottom row because it creates visible progress. Prompt libraries, clever wrappers, orchestration hacks, demo-ready agents. Very satisfying. Very perishable.

The more valuable work is messier. It requires product, engineering, customer success, data science, legal, and domain experts to agree on what “good” means. It requires instrumentation. It requires capturing overrides. It requires deciding which workflows deserve proprietary investment and which should be handled by the platform.

Harder? Yes.

More durable? Also yes.

The meeting you should have next week

The practical move is not to launch another generic AI roadmap review. You probably already have one. It has 14 workstreams, a capability heatmap, and at least one slide with “agentic” in 28-point font.

Instead, run the meeting around one question:

If a customer tried to build an 80% version of our product, where would they fail?

Then push the team through the uncomfortable follow-ups:

Which parts of our product are now easier to replicate because of AI?
Which workflows do we understand better than our customers or competitors?
What evals define “good” in our category?
Where do we capture expert judgment and customer corrections?
What product data gets more valuable with every customer interaction?
Which AI features are durable, and which are just wrappers around today’s model gaps?
Are we using AI to reduce cost, or to deepen differentiation?
If a customer’s CIO asked, “Can we build this ourselves?”, what would make the answer no?

That last one is the strategy.

The actual takeaway

AI is going to make a lot of software easier to build. That is exciting if you are trying to automate internal work. It is less exciting if your product is the thing someone else is trying to automate around.

The answer is not to panic. It is also not to sprinkle AI features everywhere and hope the market confuses activity with strategy.

The answer is to get very clear on what makes your product truly distinctive.

The foundation model is powerful, but everyone can access it. The vendor harness is useful, but rented. The durable moat is the company-specific system around it: evals, context, workflow intelligence, customer data loops, expert feedback, and governance.

That is the hill-climbing machine. That is what improves. That is what compounds. That is what makes the product harder to replace.

If everyone has the same AI, the winner is not the company with the most AI features.

It is the company whose product learns the fastest about the work that matters most.

Wants to read more? Check-out our most popular recent posts

Note: The opinions expressed in this article are my own and do not represent the views or specific practices of Bain & Company. The information provided is believed to be from reliable sources, but no liability is accepted for any inaccuracies.

Inside Software

Discussion about this post

Ready for more?