What do I need to understand about the future of enterprise software in 60 seconds?
TL → DR
Enterprise software has historically been designed around the complexity of large organizations and sold downward. AI changes that because the cost of creating company-specific software, workflows, intelligence, and interfaces is falling dramatically.
That does not mean small companies are ahead in AI adoption. They aren’t. The opportunity is that an established SMB can combine assets a startup does not have—customers, reputation, industry knowledge, distribution, operating experience—with more freedom to redesign than a large enterprise has.
The winning architecture is unlikely to be “build everything yourself.” It is more likely to be buy the durable core, own the differentiated logic, and build a governed layer of data, context, intelligence, and workflows around the way your company actually operates.
That creates a second possibility: some of tomorrow’s enterprise software companies may begin as operating companies that build software for themselves first.
Introduction
I have spent the last 20 years of my career learning how to operate companies as efficiently as possible.
That has meant leading an unusually large number of projects focused on:
Migrating companies to new enterprise software
Implementing and integrating those systems
Optimizing existing enterprise applications
Building the databases, data warehouses, and now data lakes required to support them
Creating the data infrastructure that allows operators to run critical workflows, analyze performance, and understand what is actually happening inside their businesses
Along the way, I have developed deep experience with ERP systems, CRMs, inventory management platforms, financial management software, and the analytics layers that sit above them.
The last 24 months have fundamentally changed how I think about this entire category of work.
Large language models, combined with code-generation tools such as Claude Code, Codex, and Cursor, have dramatically expanded what companies can build for themselves. Custom enterprise applications, and, perhaps more importantly, highly specific modules that extend or replace pieces of larger enterprise systems—can now be built faster, more affordably, and with far greater precision than was previously practical.
That changes what operators should expect from their software.
Companies no longer need to accept quite as many compromises between what their business actually requires and what an off-the-shelf enterprise platform allows them to do. The potential for customization is increasing, while the cost and difficulty of building it are falling.
The same transformation is happening underneath the applications themselves.
Large language models can now assist with preparing, cleaning, structuring, and transforming enterprise data. Modern database platforms such as Supabase have made sophisticated data infrastructure significantly more accessible. Data warehouses and data lakes can be built and managed in ways that would have required substantially more time, expertise, and capital only a few years ago.
Together, these changes are creating a new set of possibilities for how companies architect their systems, manage their data, automate their workflows, and build the software they depend on every day.
This article is written for operators, founders, and CEOs who should be thinking more ambitiously about those possibilities.
My goal is to help you understand what is changing, what is now realistically achievable, and what these shifts could mean for the accuracy of your systems, the quality of your data, the competitiveness of your company, and ultimately its profitability.
The expectations we place on enterprise software should be changing. So should the way we build it and make the associated purchasing decisions.
This article is the beginning of a much larger body of work I plan to write on the subject. If you are an operator, founder, or CEO wrestling with these questions inside your own company, I hope it helps, and if there is a specific problem you would like me to explore, please message me.
Why was enterprise software built around companies much larger than yours?
For most of the last 30 years, enterprise software moved in one direction…
Large organizations needed systems capable of handling enormous complexity. ERP, CRM, finance, inventory, HR, procurement, and analytics platforms were built around those requirements and gradually packaged into products for smaller companies. Panorama Consulting’s 2026 ERP research still segments the market into revenue tiers, from companies under $10 million to those above $750 million.
The smaller company ends up adapting itself to software designed for somebody else.
A 75-person manufacturer, distributor, healthcare business, or professional-services company does not necessarily need a smaller version of a system built for a multinational corporation. It needs an operating system shaped around the way its own company creates value.
A16z’s research on next-generation ERP makes a similar argument from the software-founder side: platform shifts create opportunities to rethink ERP around specific verticals, company sizes, and transition points rather than recreating the same monolithic architecture.
AI makes that alternative increasingly possible.
Operating Stories: The $20 Billion Swing - How Uber turned losses into a cash machine.
AI Was Supposed to Kill Consulting. Instead It Has Started a Golden Age.
The Quiet Builders Are Coming. Great Companies Will Build Around Them.
What happens when an established SMB gets a second startup phase?
An NBER analysis built from Census Bureau microdata finds AI usage increases substantially with company size, particularly in information, professional services, and finance. Even more interesting, however, is how shallow adoption still is: among firms already using AI, 57% use it in three or fewer business functions.
Most companies have adopted AI.
Very few have rearchitected themselves around it.
That creates the opportunity.
A 20-year-old, $30 million business ordinarily never gets to become a startup again. It already has customers, employees, suppliers, habits, systems, processes, and an established economic model.
AI offers a rare second startup phase.
The business gets to keep the valuable things it spent years building (customers, reputation, industry expertise, distribution, relationships, institutional knowledge) while reconsidering how work gets done.
Research from Harvard Business School provides an early picture of what the destination may look like. In “AI-Native Firms,” Hyunjin Kim and Rembrand Koning find that AI-native startups are roughly 25% smaller than comparable non-AI startups. They tend to be flatter, with fewer managers and entry-level roles, and much of the difference comes from embedding AI into the product itself rather than merely helping employees complete existing work faster.
That does not mean an established SMB should cut 25% of its workforce. Rather, we should place our emphasis and attention on the truth that we are beginning to see: companies designed around AI look structurally different from companies that merely use AI.
The opportunity for the established SMB is to determine how much of that architecture it can adopt without harming its current assets, thereby placing it in a more competitive position.
Why hasn’t AI created the giant productivity gains everyone expected yet?
Because installing a new technology and redesigning a company around that technology are not the same thing.
Erik Brynjolfsson, Daniel Rock, and Chad Syverson describe this phenomenon in their research on the Productivity J-Curve. General-purpose technologies often produce disappointing measured productivity at first because businesses still need to build the processes, knowledge, systems, training, and organizational structures required to exploit them.
Electricity offers the classic analogy.
Factories did not fully realize the benefits of electric motors by placing them where steam-powered machinery had previously stood. The breakthrough came when factories redesigned the floor around what distributed electric power made possible.
We are largely still putting AI where the steam engine used to be. We add Copilot. We summarize meetings. We automate an email. We generate a proposal.
Useful. But the much larger question is:
If this technology had existed when we founded the company, would we have designed the company this way at all?
What should become the durable layer when the software interface becomes in question?
Traditional enterprise software organizes work around modules, menus, forms, fields, and reports.
AI increasingly allows the employee to begin with intent.
Instead of navigating Inventory → Reports → Stock Status → Export → Excel, the employee asks:
“Which products are likely to stock out in the next 60 days, what revenue is at risk, and which purchase orders should we accelerate?”
The application determines what analysis, data, visualization, workflow, or action is required. But that future only works if the system understands what the company means.
What counts as revenue?
Which inventory is actually available to promise?
When does a prospect become a customer?
Which discount requires approval?
Who can see which information?
Research on real enterprise querying makes this limitation very clear. The EntSQL benchmark finds that the overwhelming majority of enterprise questions require domain knowledge beyond what is present in the question or the raw database schema.
That is why I no longer think the database alone is the critical asset. The more valuable layer is a governed model of the company: clean data plus canonical definitions, permissions, relationships, business rules, exceptions, and institutional knowledge, all of which can be housed in common databases, regardless of their data type or current location. Thank God for data lakes and Apache Spark.
a16z describes this as a context layer that gives agents the business meaning they cannot recover from raw tables alone. In a related piece on “headless” software, the firm argues that AI may weaken interface-driven stickiness while leaving operational logic and context extremely valuable.
The interface becomes more disposable.
The company’s understanding of itself becomes more valuable.
Where should the new line between building software and buying software sit?
This is where the “everyone will build their own ERP” argument goes too far.
Aaron Levie at Box has articulated the strongest objection. In Foundation Capital’s discussion with Levie, he argues that companies buy software not simply because software is difficult to write, but because it is difficult to maintain, secure, permission, support, and operate over time.
He is right. AI has not made software ownership free. It has changed the minimum economically rational scope of software ownership.
Morgan Stanley Investment Management’s 2026 analysis of the software market reaches a similar conclusion. AI-driven insourcing is much more credible for lightweight workflows and thin application layers than for complex, regulated systems of record.
The practical strategy is therefore not build versus buy.
It is: Where should the line move?
Curative provides a useful real-world example. The healthcare company built an internal CRM in roughly two months and canceled a $600,000 annual Salesforce contract, while subsequently acknowledging that maintenance was difficult and AI infrastructure costs were growing rapidly, as described in this reporting on its internal software strategy.
A company may continue buying its general ledger, payroll system, banking infrastructure, and commodity communications tools while building the quoting logic, customer intelligence, inventory allocator, contracting workflow, or decision engine that actually makes the business different.
Buy the durable core. Build the differentiated edge.
This model is the one I currently see most in practice and implement across my own consulting engagements. It's important to add, however, that the capacity to build from a durable core to a differentiated edge would not have been possible 12 or 18 months ago (I’m thinking CRM and inventory management systems). Anthropic's release of Fable 5 was a major step forward on this front and it is my expectation, that 12 months from now or sooner, we will be talking about building more robust custom applications, and having them replace enterprise software line items that currently feel untouchable. CRM and ERP being prime candidates
When does an operating company become a software company?
This may be the most interesting consequence of all.
Operating companies have something most software startups spend years trying to acquire: a real environment in which to discover what the software should do.
They already have customers, workflows, transactions, exceptions, domain experts, feedback loops, and definitions of success.
Travis Kalanick’s Otter is a useful example. The platform grew out of the restaurant technology built around CloudKitchens’ operating needs before becoming a standalone software business. Business Insider reported that Otter had reached roughly 100,000 paying restaurants and was approaching $70 million in annual revenue.
The cycle is worth paying attention to:
Operate → build → prove → productize → sell.
Sequoia reaches a related conclusion in “Services: The New Software,” arguing that AI businesses increasingly have an opportunity to sell the work itself rather than merely sell a tool that helps somebody else perform the work.
Enterprise software is moving from helping people perform work toward increasingly completing the work itself. Sequoia describes this transition as the movement from copilots toward autopilots, and argues that the larger opportunity may ultimately sit in selling outcomes rather than tools.
That means the software created inside an SMB does not necessarily remain internal.
A distributor builds a superior quoting architecture for itself. A healthcare company builds a better contracting workflow. A manufacturer builds an inventory decision engine.
If those systems create real operating advantage, the company may eventually realize it has also created a product. Some of the next important enterprise-software companies may begin inside businesses that never intended to become software companies.
What should you build if you are selling enterprise software into this market?
Do not begin by asking what feature Salesforce, SAP, NetSuite, or Workday is missing. Instead, ask: What work should no longer require someone to manually operate software?
The market is already moving in this direction. Menlo Ventures found that startups captured 63% of the AI application layer in 2025, up from 36% the year before.
Bessemer describes the architectural transition as a move from systems of record toward systems of action, while its work on AI monetization argues that software economics are shifting away from simply licensing access and increasingly toward usage and outcomes, as outlined in its AI Pricing and Monetization Playbook.
The opportunity for enterprise-software founders is therefore not simply to make existing SaaS prettier with an AI assistant.
Design for the growth-oriented, legacy-light company willing to rethink the workflow.
Expose data and actions so agents can operate the software as easily as humans.
Make permissions, context, definitions, auditability, and learning part of the product.
And sell the shortest path from trusted information to completed work.
For decades, enterprise software has asked smaller companies to adapt to software designed elsewhere. AI allows us to reverse the relationship.
The SMB is interesting because it may now be able to combine the accumulated advantages of an incumbent with some of the architectural freedom of a startup.
That makes it one of the most interesting laboratories we have for discovering what the next generation of enterprise software will be.
- j -
Questions For Executives
Is this primarily an AI adoption project or a company redesign project?
If the objective is simply to give employees access to better tools, buy the tools. If the goal is to change the company's economics, capabilities, or operating model, the work needs to go much deeper into workflows, data, roles, and decision-making.
Should we build our own CRM, ERP, or other core system?
Usually not in its entirety. The more useful question is which parts of the operating stack encode proprietary judgment or create competitive advantage and which parts are standardized infrastructure that another company can maintain more effectively.
What data do we need for agents to operate the business reliably?
Clean records are only the beginning. Companies need common definitions, authoritative sources, permissions, entity relationships, business rules, exception handling, and a way to capture institutional knowledge.
Will AI automatically make a smaller company more productive?
No. Research on firm-level AI adoption still shows limited realized productivity effects, and the broader history of general-purpose technologies suggests that significant gains require complementary organizational redesign.
Does this mean SaaS is going away?
No. It means the surface area over which companies rationally build their own software may expand, while the strongest software vendors increasingly compete on context, proprietary data, workflow knowledge, reliability, governance, and outcomes rather than screens and seats alone.
Why might SMBs be particularly important to this transition?
Not because they currently lead AI deployment. The most ambitious SMBs may simply occupy an unusual position: they have enough operational complexity and accumulated assets to produce meaningful lessons, while often having fewer legacy systems, organizational layers, and entrenched workflows preventing them from changing.
John Brewton documents the history and future of operating companies at Operating by John Brewton. He is a graduate of Harvard University and began his career as a PhD student in economics at the University of Chicago. After selling his family’s B2B industrial distribution company in 2021, he has been helping business owners, founders, and investors optimize their operations ever since. He is the founder of 6A East Partners, a research and advisory firm asking the question: What is the future of companies
Research
Enterprise Software and ERP Design
Panorama Consulting — 2026 ERP Report
Market segmentation, ERP buyer characteristics, implementation patterns, and historical enterprise-software structure.
Read the report
Andreessen Horowitz — The Opportunity for Next-Gen ERPs
Research on AI-native ERP challengers, company-size and vertical wedges, and the opportunity created by platform transitions.
Read the research
AI Adoption and the Second Startup Phase
Harvard Business School — AI-Native Firms, Hyunjin Kim and Rembrand Koning
Research on organizational structure, headcount, valuation, and product design at AI-native startups.
Read the HBS working paper
NBER — The Microstructure of AI Diffusion
Census-based analysis of AI adoption by firm size, function, and worker task.
Read the paper
NBER — Firm Data on AI
International executive survey examining current and expected employment and productivity effects from AI.
Read the paper
NBER — The Productivity J-Curve
Brynjolfsson, Rock, and Syverson on why general-purpose technologies require complementary intangible investment and organizational redesign before productivity gains appear.
Read the paper
Data, Context, and AI-Native Software Architecture
Andreessen Horowitz — Your Data Agents Need Context
Framework for canonical entities, business definitions, identity resolution, governance, and institutional knowledge surrounding enterprise data.
Read the article
Andreessen Horowitz — Is Software Losing Its Head?
Analysis of headless software, agent-driven interfaces, and why operational logic and context remain defensible.
Read the article
EntSQL — Enterprise Text-to-SQL Benchmark
Technical research showing the importance of enterprise-specific contextual and domain knowledge when querying business data.
Read the paper
dbt Labs — Semantic Layer vs. Text-to-SQL
Supporting benchmark research on the accuracy improvements created by curated semantic layers.
Read the benchmark
Build Versus Buy
Morgan Stanley Investment Management — AI-Related Sell-Off in Software
Institutional analysis distinguishing software categories vulnerable to internal AI-driven development from durable, regulated systems of record.
Read the report
Foundation Capital — The Case for Context Graphs with Aaron Levie
Levie’s argument about maintenance, support, governance, context, and the enduring economics of buying enterprise software.
Read the discussion
Curative — Internal CRM and SaaS Replacement Case
Reporting on Curative’s internal CRM, Salesforce cancellation, AI infrastructure spending, and maintenance experience.
Read the reporting
From Internal Operations to Software Products
Business Insider — Otter and CloudKitchens
Reporting on the restaurant-software platform’s development, customer scale, and evolution from operating infrastructure into a standalone product.
Read the reporting
Otter — Restaurant Operating Platform
Current product architecture and positioning around restaurant operations.
Visit Otter
Sequoia Capital — Services: The New Software
Julien Bek’s thesis on AI companies selling completed work and outcomes rather than simply providing tools.
Read the thesis
Building and Selling AI-Native Enterprise Software
Menlo Ventures — 2025 State of Generative AI in the Enterprise
Research on startup market share, enterprise AI application spending, and bottom-up distribution.
Read the report
Bessemer Venture Partners — Roadmap: AI Systems of Action
Research on AI-driven systems of action, integration economics, and disruption of traditional systems of record.
Read the research
Bessemer Venture Partners — The AI Pricing and Monetization Playbook
Research on consumption, outcome-based pricing, and the changing economic model for AI-native software.
Read the playbook
The idea of an established SMB getting a second startup phase is especially compelling. AI isn’t just changing the tools companies use. It’s creating an opportunity to rethink how the business itself operates
I feel everything will be backend. Own the backend, clean and understand your data. Make it accessible through different endpoints. I kind of feel software as such will become invisible.