Is Package Software Dead?
<– DRAFT –>
Introduction
AI and in particular LLMs, are dramatically reducing costs throughout the software delivery lifecycle. How does that change the build versus buy decision making process? Building software is not just about engineering - there are also the added costs of operations, security and ongoing support. Package providers can also provide accountability when things go wrong.
So although software development costs are reducing, is that a compelling enough reason to throw out packages and adopt a custom build approach?
What is package software?
By package software, we mean off-the-shelf products deployed within an enterprise — whether that’s a traditional on-premise application or a SaaS platform. Think ERPs, CRMs, HR systems, procurement tools.
These systems are expensive and often inflexible but they take away a lot of the headaches and accountability. So the question of whether AI changes their value proposition is a legitimate one. But to answer it properly, you have to understand why enterprises adopted them in the first place.
Why Enterprises Buy Packages
Lack of engineering capability
Many enterprises simply don’t have the capability to design, build and operate software at scale. A small logistics company isn’t going to build a world-class engineering organisation overnight. Package software lets smaller organisations acquire capability without building it.
Core competency
If your business is centred around retail, banking or manufacturing, running a high-performing engineering organisation is a significant cultural and operational shift — not just a hiring exercise. Many enterprises have made a rational choice to stay focused on what they’re actually good at, and buy the rest.
No competitive advantage
If a capability doesn’t differentiate you from competitors, building it yourself is hard to justify. A finance department running a standard accounts payable process doesn’t need bespoke software — it needs reliable, auditable software that everyone already knows how to use.
Regulatory burden
In heavily regulated industries, compliance requirements can make custom development risky and time consuming. Package vendors carry certifications, compliance histories and legal accountability that custom systems can’t easily replicate.
Legacy integration complexity
Large enterprises often have IT estates that have grown organically over decades. Package software often provides mature integration capabilities — connectors, APIs, data standards — that plumb systems together, often orchestrating complex business processes that would be difficult to replicate from scratch. The value here isn’t just in the features, it’s in the accumulated integrations that abstract away the legacy complexities.
Scale and reliability
Package software is proven at scale. It’s often been hardened and proven across thousands of customers, stress-tested in ways no single enterprise could replicate. The vendor’s support model, SLAs and incident response are part of what you’re paying for.
Accountability
When something goes wrong with a package — a security breach, a compliance failure, a data loss incident — there’s a vendor in the room with you. They have contractual obligations, they carry liability insurance, and they have a reputation that depends on making it right. For a board or a regulator, that shared accountability matters. When you build your own system, you own every failure entirely — and in a world of increasing regulatory scrutiny, that’s a meaningful risk to absorb.
What Has AI Actually Changed?
AI has meaningfully reduced the cost of developing software - from writing User Stories, to development and testing. Tasks that once took weeks can now take days - and things will only get faster. But what about the other reasons described above - let’s assess these in turn.
Engineering capability
AI reduces the number of engineers needed to build a given piece of software. But it doesn’t remove the need for architecture, governance and operational ownership. Someone still has to make the right decisions, respond to incidents and take responsibility when things go wrong. The headcount required is lower — but the end to end responsibilities remain.
Core competency
The barrier to building software has lowered, but many of the barriers to operating as a software company remain the same. Culture, product thinking, talent retention, engineering leadership, governance, pace of change — all of these are approached differently in a software company and none of them are addressed by AI. For many enterprises who’ve already made the decision to go with packages, nothing has really changed.
No competitive advantage
This is where the economics are starting to shift most noticeably. AI reduces the cost of building bespoke software; the business case is narrowing for “build versus buy” decisions - especially if vendors keep their licensing costs high. Capabilities that were previously considered commodities are now more viable as custom builds.
Regulatory burden
AI changes very little here. Compliance, auditability and legal accountability still rest on institutional structures, certifications and documented processes. If anything, AI-generated code introduces new questions about provenance and liability that regulators are still working out.
Legacy complexity
Package software still has a significant advantage in complex legacy environments, though this is worth watching. Agentic AI — systems that can act across multiple tools and workflows — may begin to reduce the need for tightly integrated monolithic platforms by providing a more flexible orchestration layer. It’s early, but the direction is clear.
Scale and reliability
AI improves monitoring and automated recovery. But operational responsibility still sits with whoever built and deployed the system. A package vendor’s SLA is worth something precisely because there’s a contract behind it.
Accountability
AI changes nothing here. If anything, it makes it worse. AI-generated code introduces new questions about provenance, auditability and liability that are still being worked out legally and regulatorily. If your custom-built system fails and the code was written by an AI, the accountability still sits entirely with you — but now you also have to explain what the AI did and why. Package vendors, by contrast, carry that burden themselves.
The Cost of Getting Out
However, for many package-software adopters, there’s another reason the custom build route can’t be rushed into: the cost of transformation is still incredibly high.
Packages that have been in place for many years are extremely difficult and expensive to unpick. They’ve accumulated integrations, workarounds, customisations and institutional knowledge over decades. The data is messy, the processes have been shaped around the software rather than the other way around. Unpicking all of that requires strong leadership, genuine risk tolerance and protected budgets sustained over many years — the kind of commitment that’s hard to maintain through leadership changes, economic cycles and competing priorities.
AI doesn’t change this. It might reduce the cost of writing the replacement software, but the transformation effort — the process redesign, the data migration, the change management, the retraining — remains largely untouched. For most enterprises, that’s the dominant cost. The engineering is the easy part.
Conclusion
Smaller SaaS vendors competing primarily on functionality in areas without strong regulatory or complexity advantages will find it increasingly hard to justify their pricing. If a reasonably capable engineering team can build a functional equivalent in a fraction of the time it once took, the value proposition of a mid-market SaaS product becomes harder to defend.
Large enterprise platforms are more resilient. They’re embedded in complex environments, carry years of integrations and compliance history, and benefit from deep institutional trust. They’re not going away soon - but they should be paying attention.
So although the economics of software development are changing, package software still remains a solid choice for many - at least for now.