In Defense of App Sprawl
Why AI changes the build-versus-buy equation for technology executives
📌 THE POINT IS: AI is lowering the cost of creating highly specialized software. That changes the traditional tradeoff between standardized vendor platforms and expensive custom development.
Technology leaders should standardize commodity capabilities while retaining ownership of workflows that create competitive advantage.
The answer is not unmanaged app sprawl. It’s hyper-customization built on governed data, enterprise controls, automatic cataloging, and application lifecycle management.
For most of my career, “app sprawl” has been something technology leaders were supposed to eliminate.
Too many tools meant duplicated costs, fragmented data, inconsistent controls, and security exposure. The responsible strategy was consolidation and standardization.
That strategy made sense when software was expensive to build, difficult to maintain, and slow to change.
But what if the economics of software creation are changing faster than our operating assumptions?
New world economics
I have been thinking about this while building my own software through AI-assisted development, or vibe coding. While using the workflow I created for cataloging items, I kept noticing small improvements I wanted: a contextual field, a faster flag, a different view of related records, or a shortcut for a repeated action.
These were not roadmap items. They were micro-features.
Traditionally, most would be too small to justify a development cycle. I would have absorbed the friction through extra clicks, a spreadsheet, a sticky note or a mental workaround.
Instead, I could add a feature while the idea was fresh, test it locally, and move it into production in a tight loop.
The software began to mold itself around how I worked, rather than requiring me to mold my work around the software.
That experience has made me reconsider whether all app sprawl is inherently bad.
When small problems become worth solving
When software is expensive, only large problems deserve software. When software becomes cheaper and faster to create, small frictions become addressable.
Ethan Mollick described a related shift in “Claude Dispatch and the Power of Interfaces”. He suggests that the future may not be “one interface to rule them all,” but AI generating the right interface for a particular moment, including “a custom app to solve a problem.”
That is the promise of hyper-customization
Enterprise applications are designed for averaged workflows. A vendor cannot design every screen around one employee, one team’s exceptions, or one company’s operating process.
Generalized software creates scale, but it also creates quiet mismatches:
The workflow almost fits.
The data model captures most of what matters.
The exception lives in email, a spreadsheet, or someone’s memory.
AI-assisted software can begin to occupy that gap.
Are we standardizing our secret sauce?
At the Gartner Research Board Cycle 2 2026 meeting in Chicago, my takeaway from the discussions was that this question is larger than personal productivity.
Large enterprises frequently implement vendor applications for entire processes or deploy multi-module ERP platforms such as SAP. These provide mature controls, reliable transactions, regulatory support, integrated data, and an upgrade path.
But these decisions often carry an assumption that receives too little scrutiny:
The business process should conform to the software.
That may be reasonable for commodity capabilities. Few companies differentiate themselves through the mechanics of maintaining a general ledger or administering standard benefits. Standardization there can reduce cost and risk.
The calculation changes when the process is part of the company’s advantage
How a company prices, fulfills, underwrites, merchandises, manages risk, or serves customers may be part of its secret sauce. Forcing those capabilities into a vendor’s generalized model can produce consistency while removing some of what makes the company distinctive.
Historically, executives accepted that tradeoff because:
Custom software was too expensive.
Customization made upgrades painful.
The vendor was presumed to have encoded an optimized process.
Those constraints were real. They should not become permanent beliefs after the economics change.
Buy the commodity. Build the advantage.
AI-assisted development does not mean replacing an ERP with thousands of casually generated applications. That would exchange rigidity for chaos.
The useful question is:
Where should the boundary between packaged and custom software now sit?
My working principle is:
Buy the commodity. Build the advantage. Connect both through governed data and explicit contracts.
Core platforms can continue to manage durable records, commodity transactions, and enterprise controls. A governed data platform can preserve shared definitions, history, quality, and access policies.
Around those foundations, specialized applications can express how the company wants to operate. Some will extend vendor platforms; others may replace modules where customization produces enough value.
New but not necessarily novel
This is not entirely outside the vendor playbook. SAP’s clean-core guidance recommends standardizing the core while prioritizing extensions for business-differentiating processes. Gartner’s work on postmodern ERP and composable enterprise architecture similarly challenges the idea that every capability must live inside one monolithic suite.
Mollick provides an early signal about the changing cost curve. In “Management as AI Superpower”, he describes executive MBA students, most without coding backgrounds, creating working prototypes in four days.
A prototype is not a production system; security, resilience, integration, and regulatory requirements remain. But the cost of building, testing, discarding, and revising software is falling.
That changes which problems are economical to solve.
The governed hyper-customization stack
The architecture I am imagining has three layers:
Stable enterprise core: ERP, CRM, systems of record, commodity transactions, identity, and financial or regulatory controls.
Data and control plane: Governed data products, APIs, security policies, observability, lineage, audit logs, and application lifecycle management.
Adaptive application layer: Personalized interfaces, workflow tools, specialized business modules, and AI agents operating within defined permissions.
The adaptive layer can change quickly because the foundations beneath it remain stable.
The small app becomes the interface, not the prison for the data. If an application is retired, its durable data remains available to whatever replaces it.
The harness matters more than the app count
This is not a defense of unmanaged shadow IT. The relevant measure is no longer simply how many applications exist. Leaders should ask whether every application:
Has a named owner and business purpose.
Inherits enterprise identity and permissions.
Uses approved data connections.
Passes security and deployment checks.
Produces logs and usage information.
Has traceable versions and a rollback path.
Can be retired without losing important data.
Mollick makes a similar point in “Claude Code and What Comes Next”. He highlights what AI coding agents can accomplish “with the right harness,” while warning that they can delete files, run unintended code, or expose sensitive information.
The capability and the control problem arrive together
Every employee-built application should therefore be cataloged automatically. The catalog should capture its owner, purpose, users, data sources, permissions, versions, security status, and last-used date. Microsoft’s Power Platform governance model already points in this direction through centralized inventory, usage monitoring, and administrative controls.
Applications should also have an ending. An automated process can flag inactive tools, notify owners, preserve durable data, and recommend archival or retirement.
App sprawl becomes dangerous when software has no lifecycle.
What technology executives can do today
This does not require an immediate ERP replacement. It requires a controlled way to learn.
Choose one differentiated workflow. Find a process where your company’s way of working matters and current software creates obvious friction.
Map the hidden workaround layer. Document the spreadsheets, emails, duplicate entry, manual reconciliations, and knowledge carried in employees’ heads.
Run a governed experiment. Give a small team an approved AI-assisted development environment with enterprise identity, governed data, source control, testing, and logging.
Measure operating value. Track cycle time, manual steps, decision quality, errors, adoption, and iteration speed rather than lines of code or applications created.
Catalog from the beginning. Capture the owner, purpose, users, data, permissions, versions, and last-used date during deployment.
Define retirement before launch. Decide when the application will be reviewed, where its data will remain, and how it can be shut down safely.
Update the build-versus-buy framework. Ask: Is this capability a commodity we should standardize, or an advantage we should own?
A different kind of sprawl
Some app sprawl is still waste, duplicated effort, security risk, or poor technology leadership.
But some may be creativity made operational.
It may represent employees solving problems while they still understand them, companies learning faster than major platforms can adapt, and distinctive capabilities scaling beyond software designed for the average customer.
The future of enterprise software may not be one perfect platform used the same way by everyone: it may be a governed ecosystem of stable core systems, shared data products, and many adaptive tools close to the work. Those tools can be created quickly, observed centrally, connected securely, and retired when their usefulness ends.
That is not the app sprawl we were warned about.
That is hyper-customization with a control plane.
Subscribe to dAItaPoints for practical operating memos on AI-ready data, agentic AI, governance, and the leadership work behind production AI.