A video that was too large to email made me rethink how we buy enterprise software.
I had recorded high-quality footage and needed to reduce the file size. Previously, that would have meant searching for a compression tool, comparing options, checking limitations, learning an interface, and experimenting with settings.
All to complete a task that had nothing to do with my actual work.
Instead, I asked ChatGPT:
“Decrease this video file, keep the format, and make it fit within X MB so I can share it easily.”
In my setup, it identified a way to accomplish the task using software already available on my machine. I did not need to begin by finding another product or learning a specialist workflow.
What stayed with me was not the video compression. It was this:
The capability was already there. The missing piece was an accessible way to use it.
That is a small personal example, not proof that an enterprise application can be retired. But it raises a substantial business question:
How many software purchases and renewals would look different if we reassessed what our existing technology can now deliver?
We have seen this pattern before
Think about how we find someone’s contact information.
An address book or Rolodex helped us maintain the people and businesses we already knew. Printed directories extended that search beyond our personal networks. These tools did not simply vanish when digital alternatives arrived; Cooper Hewitt, Smithsonian Design Museum, for example, documents the Rolodex’s continued use alongside its electronic successors. [1]
Web search and smartphones changed the experience again. Contact information, search, maps, and communication could sit together rather than require separate tools. Apple’s original 2007 iPhone announcement explicitly brought contacts, calling, internet search, and maps into one device. [2]
The need to find and contact someone survived. The way we accessed that capability changed.
I see a related shift emerging with AI.
A search engine could help me find video-processing software or a tutorial. I would still need to interpret the instructions and complete the work. An appropriately configured AI system can combine a request with relevant information, select tools, and work through a sequence of actions. The surrounding software—often called the harness—connects the model to those tools and manages execution. Its configuration and permissions determine what is actually possible. [3]
Action itself is not new. Conventional software and automation have provided it for decades. What interests me is the possibility of connecting an ordinary-language request to a much broader range of capabilities without making the user learn every underlying product.
I think of this as capability compression: reducing the interfaces, specialist knowledge, and handoffs between an intention and a usable outcome.
The work still exists. Some of the complexity surrounding it may no longer be necessary.
Useful software may no longer justify a separate licence
Software portfolio management already has established practices for reclaiming inactive licences, downgrading unnecessary tiers, and consolidating overlapping applications. The FinOps Foundation includes these activities in its guidance for managing software-as-a-service spending. [4]
AI adds another question:
Even when employees actively use an application, is it still the best-supported and most economical way to achieve the required outcome?
An application could have excellent adoption and still deserve reassessment.
Perhaps employees use it to complete three routine tasks. Historically, its interface made those tasks accessible. If an approved environment can now deliver them reliably, the original reason for issuing everyone a licence may have weakened—even while specialist users still need the product.
There are already concrete examples of capabilities being repackaged. In January 2025, Google announced that generative AI features would be incorporated into Workspace Business and Enterprise plans without requiring separate AI add-ons. That change also involved pricing adjustments: inclusion did not mean the underlying platform became free. [5]
For procurement, the implication is straightforward: a capability previously evaluated as a separate purchase may now belong in the baseline assessment of an existing platform.
That does not automatically make the standalone alternative redundant. It means the comparison should be reopened.
We should renew a product because its current value justifies its current cost—not because the original purchasing decision was reasonable.
Where I would look first
I would start with the characteristics of the work, rather than declare entire industries or software categories obsolete.
The strongest initial candidates, in my view, are repeatable digital tasks with clear acceptance criteria, accessible data, manageable consequences if something goes wrong, and limited integration requirements.
That points towards several areas worth testing.
Professional services and corporate support. Proposal preparation, document formatting, internal research, meeting summaries, file conversion, and routine presentation preparation are sensible starting points. The review should distinguish occasional users who need a few outcomes from specialists who need the depth of a professional application.
Retail, marketing, and commercial operations. I would examine product-content preparation, campaign adaptations, customer-feedback summaries, account research, and routine sales reporting. The objective would be to identify whether existing approved tools can replace a narrow subscription, remove an add-on, or reduce repetitive processing—not assume that generated content can bypass brand or quality review.
Financial services, insurance, healthcare, and other sensitive environments. I would begin around the administrative work: document preparation, correspondence drafting, knowledge retrieval, intake support, and assembling information for human review. That is a different proposition from replacing authoritative records or delegating consequential decisions.
Technology, manufacturing, and logistics organisations. The first review need not target the most technically complex systems. Internal support, documentation, report preparation, supplier-information processing, and routine file or data transformations may offer more practical entry points.
Across these sectors, I would examine the handoffs, not just individual features.
Consider a customer interview that becomes a transcript, then a spreadsheet of themes, then a presentation, then a set of product tasks. The business outcome is not “use four applications.” It is “turn customer evidence into an informed product decision.”
A capability review should test the entire journey. Making one step faster has limited value if the result still waits in a queue, needs extensive correction, or cannot be used by the next team.
The commercial answer may be partial substitution: keep specialist licences, reduce occasional-user seats, remove a module, or avoid a proposed purchase. Full replacement should be one possible outcome, not the target imposed on every review.
The evidence supports investigation—not a universal savings percentage
There is credible evidence that AI can improve particular workflows.
A study published in The Quarterly Journal of Economics in 2025 examined 5,172 customer-support agents at one business-software company. Access to an AI assistant increased issues resolved per hour by 15% on average, with substantial differences between workers. Less experienced workers generally benefited more. That is evidence of productivity improvement in a specific setting—not evidence that every support platform can be replaced, or that its licence costs will fall by 15%. [6]
There are also reported procurement-displacement examples. In June 2025, Bloomberg reported that Klarna’s chief executive said the company had saved around $2 million after ending its Salesforce relationship in favour of internally developed, AI-enabled data tools. That is an executive-reported saving; the report does not establish a complete comparison of implementation, maintenance, and operating costs. Nor is developing an internal technology stack equivalent to simply using an existing chatbot subscription. [7]
These examples matter, but for different reasons.
One demonstrates a measured improvement in work output. The other reports a change in software spending. Neither should become a percentage copied into an unrelated company’s business case.
Evidence should help us choose what to test. Our own operating results and contracts must establish what we can save.
Give Finance a business case it can verify
For CTOs and CIOs, this creates an opportunity to explain AI investment through more than adoption statistics or estimated hours saved.
The financial conversation should separate four outcomes.
Realised cost reduction occurs when an existing expense actually decreases: a contract ends, fewer licences are renewed, or a paid module is removed.
Cost avoidance occurs when a credible planned purchase is no longer necessary. It should be tied to an identifiable requirement or budget, not an imaginary product the organisation might someday have bought.
Capacity released means people can complete the work with less effort. That becomes a cash benefit only when it changes spending; otherwise, its value should be demonstrated through additional output, reduced backlogs, or other useful redeployment.
Service or revenue improvement belongs in the case too, but needs its own evidence. Faster quotation preparation, for example, is not automatically higher revenue. The organisation should measure whether turnaround, conversion, or customer experience actually changes.
Keeping those categories separate makes the argument stronger.
A renewal example
Consider a hypothetical organisation spending CAD 120,000 annually on a group of specialised tools, after ordinary unused-seat cleanup has already been completed.
A validated review determines that specialist licences costing CAD 36,000 should remain. Moving the other workflows into the existing AI environment would add CAD 24,000 in annual AI capacity and usage, plus CAD 12,000 in annual support and operating costs.
Recurring spending within that comparison falls from CAD 120,000 to CAD 72,000: a CAD 48,000 annual reduction.
With CAD 18,000 in one-time validation, transition, training, and exit costs, the net benefit over the first twelve months would be CAD 30,000, assuming the change takes effect at the start of that period.
These are illustrative assumptions, not an industry benchmark. But they expose the decision to useful scrutiny.
If additional AI costs doubled to CAD 48,000, the recurring benefit would fall to CAD 24,000. If the contract could not be reduced until the following year, the timing of the benefit would change.
No speculative conversion of employee minutes into salary savings is needed to make the original example work.
Existing capacity is not free capacity
There are also two different cost perspectives to preserve.
For an individual renewal, assess the incremental cost of moving that workflow.
For the overall AI programme, assess the fully loaded cost of the shared platform, including subscriptions, infrastructure, administration, governance, and support.
Charging the entire platform independently to every use case would distort the comparison. Ignoring its cost across the whole portfolio would distort it in the opposite direction.
My preferred operating measure would be:
Cost per accepted outcome: total workflow cost divided by the number of results that meet the business requirement.
That total should include failed attempts, human review, retries, exceptions, and fallback processing. A cheap first attempt is not necessarily a cheap completed task.
Put the review before the vendor shortlist
This is where the idea becomes an operating discipline rather than an interesting observation.
I would add an Existing Capability Review to material procurement requests and renewals, with a level of effort proportionate to the spend and risk.
First, describe the requirement without naming a product. “We need employees to prepare shareable videos within an approved file-size limit” is a business need. “We need a video-compression subscription” already assumes the answer.
Next, map the available capabilities. Include approved AI environments, existing applications, native utilities, automation services, and integrations. Pay particular attention to tooling adopted during the previous two years, but verify what is actually licensed, enabled, accessible, and supported.
Then test representative work against explicit acceptance criteria. A successful demonstration is not enough. Include difficult cases, corrections, peak demand, and the fallback when the normal path fails.
Finally, choose among reuse, configure, integrate, buy, or build—and record the commercial consequence. Retaining the incumbent is a valid result when its value is demonstrated.
This changes several responsibilities.
Product and business teams define the outcome. Architecture identifies what can deliver it. Procurement and vendor management connect the decision to contract options. Finance validates the baseline and benefits. Security, Legal, and data owners assess acceptable access and use. Service management ensures that the replacement has an owner and a support path.
A shared capability catalogue would help connect these functions. It should describe what employees can accomplish, not merely list the applications the company owns.
The timing matters. Renewal notice periods, automatic renewals, minimum commitments, and restrictions on reducing licence quantities can determine whether a technically sound alternative produces a financial benefit. Start the assessment before the relevant contractual deadline—not merely before the subscription expires. [4]
Do not confuse a new interface with a replacement
One commercial trap deserves explicit attention: putting an AI agent in front of licensed software does not necessarily eliminate the underlying licence requirement.
Microsoft’s online-services terms, for example, state that automation or other methods that reduce direct or indirect access do not reduce the number of licences required under its multiplexing provisions. The applicable agreement still needs to be assessed. [8]
The distinction is important:
Using an incumbent differently is not the same as replacing its capability.
Nor should an organisation cancel a supported product and discover that its replacement consists of undocumented prompts maintained by one enthusiastic employee.
I would expect a production replacement to have clear ownership, access controls, acceptance tests, monitoring, escalation, and a fallback. Trustworthiness needs to be assessed through design, deployment, use, and evaluation—the lifecycle perspective reflected in NIST’s AI Risk Management Framework and its generative AI profile. [9]
The implementation should also be no more complicated than necessary. Anthropic’s engineering guidance explicitly recommends starting with the simplest viable solution and adding agentic complexity only where it improves the outcome. [3]
In the video example, AI could help identify or configure an appropriate process, while conventional software handles repeat execution.
That still represents useful AI-enabled value. There is no requirement to make every subsequent operation a fresh reasoning exercise.
The same caution applies to products whose value extends well beyond their interface. Before considering replacement, ask what would have to be rebuilt: authoritative records, specialist functionality, permissions, transaction processing, auditability, reliability, or contractual support.
Reproducing one visible feature is not reproducing the product.
Eventually, the same question reaches physical assets
I expect this way of thinking to become relevant to hardware procurement as well, although the threshold for proof is much higher.
A fleet operator could evaluate vehicles, automation, maintenance, and human supervision together against cost per safely completed delivery, rather than treating the vehicle purchase and its operating model as unrelated decisions.
A warehouse could ask whether compatible robotic equipment can perform an additional task through improved software and controls before another specialised machine is purchased.
These are extensions of the framework, not assumptions that existing hardware can acquire arbitrary new abilities.
Driver assistance, for example, must not be treated as driverless operation. NHTSA distinguishes Level 2 assistance, where the driver remains responsible, from higher levels of automation with different responsibilities and operating limits. [10]
For physical systems, the assessment would need to include safety, operating conditions, supervision, insurance, maintenance, downtime, and applicable requirements.
The principle remains the same: evaluate the capability and the complete cost of the outcome, not just the object being purchased.
What are we actually renewing?
The video did not make me a professional editor. It made learning a specialist workflow unnecessary for that particular task.
That is the distinction I want leadership teams to explore at enterprise scale.
At Castle, this connects directly to how I think about technology leadership: understanding what the business needs, what it already has, and where another investment genuinely adds value.
AI should not receive credit merely because more people are using it. Part of its business case should come from demonstrating which expenses it removes, which purchases it avoids, and which capabilities it makes more useful—without quietly transferring the cost into maintenance, risk, or rework.
The next opportunity may not require another AI initiative. It may require a better conversation between architecture, procurement, and Finance about the renewals already on the calendar.
When your next renewal arrives, who is responsible for checking whether the capability still needs to be bought separately?
References
- Cooper Hewitt, Smithsonian Design Museum. Angela Hall. “The Power of the Rolodex.” April 15, 2014.
- Apple Newsroom. “Apple Reinvents the Phone with iPhone.” January 9, 2007.
- Anthropic. “Building effective agents.” December 19, 2024.
- FinOps Foundation. “FinOps for SaaS.” Living framework guidance; accessed September 16, 2026.
- Google Workspace Blog. Jerry Dischler. “Google Workspace enables the future of AI-powered work for every business.” January 15, 2025; updated April 28, 2025.
- The Quarterly Journal of Economics. Erik Brynjolfsson, Danielle Li, and Lindsey Raymond. “Generative AI at Work.” Volume 140, Issue 2, May 2025, pp. 889–942; published online February 4, 2025. Author-institution summary.
- Bloomberg, via Bloomberg Law. Aisha S Gani. “Klarna Saved $2 Million After Cutting Ties With Salesforce.” June 4, 2025. Reports an executive statement, not an independently audited total-cost comparison. Full article may require a subscription.
- Microsoft. “Product Terms — For all Online Services: Multiplexing.” MOSA agreement view; accessed September 16, 2026. The applicable agreement and product-specific terms must be assessed.
- National Institute of Standards and Technology (NIST). “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.” NIST AI 600-1, July 26, 2024.
- National Highway Traffic Safety Administration (NHTSA). “Automated Vehicle Safety.” Accessed September 16, 2026.