BLOG
Applications as a Dying Category
The word “application” carries baggage. When enterprise buyers hear it, they think: pre-packaged logic. Fixed workflows. Or they think: customization hell. Three-year implementation cycles. Consulting costs that equal or exceed the license.
Both sides of that baggage come from the same underlying problem. For decades, enterprise software forced a choice: change the software to fit your organization, or change your organization to fit the software. Pick one. You couldn’t have both without paying a price most organizations didn’t fully understand until they were deep into year two of a deployment.
Enterprise software moved through three distinct eras, each solving the previous generation’s problem while creating a new one. Mainframe applications had everything in one place but were monolithic and inflexible—you got what you paid for and it was fixed. Best-of-breed specialization delivered functional power but fragmented the application landscape. Integration became the new bottleneck. Then customizable software arrived, promising that organizations could finally shape the tools to match how they actually operated.
And they could. At a cost most didn’t fully understand until they were deep into year two of a three-year implementation.
Customization meant consulting spend that equaled or exceeded the license cost. It meant requirements that were outdated before go-live. It meant teams so exhausted by the deployment that the first user login felt less like a milestone and more like the moment they could finally stop holding their breath. I’ve watched organizations pour eighteen months of effort into getting a system to do exactly what they needed—only to discover that by the time it launched, the market had moved and half those requirements no longer mattered.
What’s more, the upgrade question never disappeared. Customize too far outside the vendor’s standard implementation and every version update becomes a renegotiation with your own technical debt. Organizations had to choose: stay on the supported version and protect the custom work, or upgrade and risk losing years of investment.
The pattern was always the same. The burden of coordination transferred from one place to another—paper to pixels, system to system—but it never left. It always landed on people.
Every Feature Is a Prompt Away
Here’s what changed: CIOs will not make platform decisions based on feature lists going forward.
When every feature is a prompt away, the old application-buying criteria—feature matrices, implementation timelines, vendor lock-in risk—stop mattering in the same way. The question enterprise buyers have always asked—does this platform conform to how my organization operates, or does my organization have to conform to it—finally has a different answer.
Not because the software industry suddenly decided to be more accommodating. Because the underlying technology shifted.
Vibe coding—where you describe what you want and AI generates it—is real. It works. And it’s compelling to watch. But here’s what most demonstrations leave out: the code that gets generated is hanging in the internet. It has no knowledge of your systems. It doesn’t understand your data sources, your access rights, your API contracts, or your organizational policies. When that code tries to execute inside your actual environment, it either fails at the system boundary or you grant it elevated permissions that create a security exposure you’ll discover later.
The difference between AI that can generate code and AI that can execute work across your enterprise comes down to context. Does the AI know which systems you’re running? Does it understand your org structure and who has access to what? Can it identify the data sources it needs and connect to them within your existing security model? When a workflow spans multiple systems, does the AI understand the interfaces between them?
That context—system interfaces, access rights, data sources, organizational policies—is what a platform provides. Without it, you’re generating code that solves a problem in isolation. With it, you’re generating execution that fits into the way your organization actually operates.
This is why the organizations upgrading their ERP environments right now are locking themselves into an architecture that will look fundamentally different in two years. Not because the vendors won’t deliver on their roadmaps—they will. But because the nature of what an “application” is has shifted beneath those roadmaps. Applications assumed that business logic lived inside the software and that the organization’s job was to configure around it. What’s emerging is execution infrastructure where the organization’s logic defines how the system behaves, not the other way around.
Value Packs Are Accelerators, Not Applications
In this context, NEWWORK’s value packs aren’t applications in the traditional sense. They’re accelerators. They deliver 90% of standard workflows out of the box—hire-to-onboard, invoice processing, approval routing—without requiring you to implement a platform first. But the remaining 10%, the part that makes it fit your specific operations, happens within defined API guardrails.
That distinction matters. In traditional customizable software, you could build anything you wanted. And therein lay the problem: you could build things that would break on the next upgrade, create security exposures, or lock you into maintenance cycles that consumed more resources than the original implementation. The freedom to customize became the source of the technical debt.
NEWWORK’s AI generates customizations within a defined API contract layer. It can’t bypass or break an interface because it learns on the API as a contract. When you configure that remaining 10%, you’re working within boundaries the system enforces—not boundaries a project manager warns you about in a design review three months into the build.
The result is something the industry has been promising for years but hasn’t architecturally delivered: software that adapts to the organization. Your policies run in the system, not alongside it. Your org structure defines the access rights. Your exception handling routes to the people who understand the domain, not to IT as an undifferentiated technical problem.
AI in Applications vs. AI Across Applications
There’s another shift happening that makes the application category problem more urgent: every major enterprise system now has its own AI.
Your ERP vendor has AI. Your HR platform has AI. Your CRM has AI. Each one is getting better at what it does within its own boundary. And that specialization creates a new version of the old best-of-breed fragmentation problem.
Think of it this way: you’re building an engine. The transmission team is world-class. They build the best transmission ever made. The engine block team is equally world-class. They build the best engine block ever made. But when you try to bolt the transmission to the engine block, the holes don’t fit—because nobody established the interface before both teams started building.
Specialized AI per system is the same problem at enterprise scale. Each AI is excellent within its system boundary. The HR platform’s AI understands everything about HR workflows. The finance system’s AI understands everything about AP processing. But when a hire-to-onboard workflow needs to coordinate between HR, IT provisioning, payroll, and facilities—across four different systems with four different AIs—there’s no overarching intelligence that understands the complete context.
The coordination still lands on people.
What’s needed is not more specialized AI. What’s needed is an execution layer that orchestrates across those specialized systems—an AI that understands the whole enterprise, not just one vendor’s portion of it. That AI can work alongside the specialized intelligence in each application. It doesn’t replace it. But it provides the governed coordination that makes the whole thing run as one organization instead of a collection of smart but disconnected tools.
What Dies and What Replaces It
So what dies when applications become a dying category? The assumption that enterprise software deployment requires the organization to adapt its operations to match the vendor’s idea of best practice. The three-year implementation cycle where the requirements change faster than the build. The choice between speed and fit. The belief that CIOs choose platforms based on whether they can check every box in a feature matrix.
What replaces it is execution infrastructure. Governed AI that operates across the systems you already have, without replacing any of them. Value packs that get you to 90% immediately, with the remaining 10% configurable within guardrails that protect your upgrade path by design. A deployment model where each workflow is a discrete, self-contained value event—no dependency on what came before, no commitment to what comes after.
The burden of coordination, for the first time, moves from the person to the platform.
That’s not an application. That’s something else entirely. And the organizations that recognize the distinction now are the ones that won’t spend the next two years retrofitting governance into a foundation that wasn’t built for it.