The Generational Shift in Software: What AI Unlocked, and What It Means for Buyers

#In brief

For thirty years, the cost of building and changing software determined how software was sold. Vendors built one product for many companies, priced the work of making it fit as a separate consulting engagement, and charged for every person who used it. After go-live, any modification required a change order, which was costly and took months. Organizations with the largest budgets could afford to keep a system aligned to their business. Everyone else conformed to the software and absorbed the difference in workarounds.

Those conditions no longer hold, and what has replaced them is a genuinely different generation of software. The change runs across four layers at once, which is what makes it generational rather than incremental.

What software can do has changed. Systems can now weigh competing considerations against a stated policy, summarize a long and contradictory case file into a decision-ready brief, draft a response tailored to the situation in front of them, decide within stated limits, execute a transaction, and hand a case to a person with full context when it reaches the edge of its authority. This was not available in the previous generation at any budget.

How software gets built has changed. The foundation that used to be the expensive, proprietary part, meaning the data layer, orchestration, storage, and integration plumbing, has become commodity. What replaced it as the difficult part is governing systems that act rather than record. And the layer that makes a system match a particular business is now generated against that business's actual process, rather than configured within the shapes a vendor anticipated.

How it gets delivered has changed. Analysis, scheduling, specification, testing, and documentation all became faster at the same time, and a small team now carries what used to require several times the headcount.

And improvement no longer stops at go-live. Changes that took months and cost a great deal now take days and arrive properly tested. I have taken to calling the resulting loop continuous fit: the system is used, using it reveals what is possible, the client decides what matters, the change is built and tested, and the cycle turns again with better input than it had the first time.

Any one of those alone would be a useful improvement. Together they compound, because inexpensive change is only valuable if delivery can keep pace with it, and fast delivery is only responsible if the foundation underneath already carries governance, audit, and control.

For a customer, this means software shaped around how the business actually works rather than the business reshaping itself around the software. It means everyone who needs access can have it, because charging for each person has stopped making sense. It means a system that keeps improving, where each round of improvement teaches the organization something about its own operation and produces better ideas for the next round. And it costs materially less than what many organizations pay today for software that does not fit them.

This paper describes what changed at each of those four layers, how the delivery cycle works in practice, including the staging, testing, hardening, and governance that make it responsible to run at that speed, and what I would suggest to a leadership team planning a replacement, an upgrade, or a new purchase this year.

#The cycle everyone recognizes

Consider what it took, until recently, to change something in a business system after it went live.

An operations manager identifies a problem. The approval routing does not match how the business actually escalates, and the workaround costs the team several hours a week. The request goes to IT, where it joins a queue. Eventually someone agrees it is worth pursuing, and the vendor or the systems integrator is asked what it would take. They propose a scoping engagement, because they cannot quote the change without first analyzing it, and the scoping engagement itself is billable. Weeks later a specification arrives with a price, and a change order follows: a formal amendment to the contract, priced, signed, and scheduled. Any modification, any new feature, any adjustment to a report or a workflow travels this same route, because everything outside the original statement of work is by definition out of scope. The price requires an approval the operations manager cannot give, so it goes to a steering committee, which meets monthly. If it survives that, the work is scheduled against the vendor's availability, developed, handed back for user acceptance testing, and released in the next quarterly window. Elapsed time from problem to production, in a well-run organization, is somewhere between four and nine months. The cost is enough that nobody submits the request casually.

Most organizations run that cycle twice and then stop running it. The economics teach the lesson quickly: the second or third time someone proposes a change, a manager weighs the request and the wait against telling the team to keep doing it manually, and manual usually wins. The system stops moving while the business keeps moving, and the gap is absorbed by staff, by spreadsheets, and eventually by a role created specifically to bridge two systems that will not speak to each other.

This pattern is older than most of the software running on it. SAP established it with R/2 in the 1980s and R/3 in 1992, where the license was substantial and the implementation was a multi-year program with a systems integrator attached. Siebel and PeopleSoft carried the same structure through the 1990s, and anyone who lived through a Siebel implementation remembers what customization cost and how long it took. The move to cloud in the following decade changed where the software ran and how it was billed, but it left the underlying commercial logic largely intact. Configuration was still an engagement, users were still the unit of pricing, and material changes still arrived through a change order.

Every part of this followed from the cost of producing and changing software. Because building was expensive, a vendor built one product and sold it to as many companies as possible. Because making that product match a particular business was also expensive, that work was priced separately, delivered as a project, and concluded on a go-live date, after which the system stopped moving. You paid for the software, then paid again for every person who used it, and again for every change. For thirty years that was a rational response to real costs.

#Why the old model is under real pressure

What I have described is not a bad experience with one vendor or one implementation. It is the structure of the industry, and this year the capital markets repriced it.

Application software stocks fell roughly 30 to 55 percent in the opening weeks of 2026, against a 24 percent decline for the software index as a whole. In February, Jefferies reset its coverage of the sector on an explicit assessment of AI disruption risk, downgrading Workday, DocuSign, Monday.com and Freshworks. Several analysts argued at the time that the selloff had overshot, and they may be right about the prices. There was much less disagreement about what was being repriced. It was not software. It was the per-seat license, and specifically the assumption underneath it that the number of people with access approximates the amount of work the software performs.

It was not software. It was the per-seat license, and specifically the assumption underneath it that the number of people with access approximates the amount of work the software performs.

That assumption held for a long time and it is now coming apart, which is a structural change rather than a sentiment cycle. A buyer does not need a view on any particular vendor's prospects to draw the relevant conclusion, which is that a commercial model under this much pressure is not a safe thing to commit to for five years.

#The first layer: what software can now do

Start with capability, because it is the part that is genuinely new rather than merely cheaper.

The useful examples are not the ones a rule could have handled. Pulling a date or an invoice number off a form was solved a long time ago, and a system that does only that is the previous generation with better tooling. What is new is judgment applied where no branch of an if statement fits.

A system can now weigh a request against a policy that was written in prose, decide which of several considerations should govern when they point in different directions, and explain which parts of the policy it relied on. It can read a complaint and judge its tone and severity, distinguishing a customer who is inconvenienced from one who is about to leave, which is a distinction no keyword list has ever drawn well. It can take a case file assembled from a dozen sources over two years and produce a brief that a decision-maker can act on, which is a genuinely generative act rather than a retrieval. It can draft correspondence that fits this situation and this counterparty rather than filling a template. It can reconcile records across sources that disagree and, more usefully, articulate why they disagree. Around all of that it can make a determination within limits you set, execute the resulting transaction in your systems, and hand the case to a person with the full context of what it did and why when the request goes beyond what it is permitted to decide.

None of that was purchasable in the previous generation at any budget. A bank with unlimited capital in 2015 could not buy a system that weighed a hardship request against its own policy and wrote a defensible recommendation. What it could buy was a system that recorded a person doing that work, which is a different thing entirely. The previous generation of enterprise software was, at its core, a very good system of record. What is available now performs work rather than documenting it.

The previous generation of enterprise software was, at its core, a very good system of record. What is available now performs work rather than documenting it.

This matters for the buying decision because it changes what the wish list can contain. The honest list of what would make your operation genuinely good has always included items that were not about software at all, because the work required judgment applied to messy inputs. A meaningful portion of those items now has an answer.

Which is also the reason a requirements document written from vendor demonstrations understates what you can obtain. It was assembled from what you have watched software do, and software has recently started doing a different category of thing.

#The second layer: how a system gets built

The promise of a foundation plus configuration is not new, and the surface description of what we do sounds similar enough to it that the distinction is worth drawing carefully.

Lotus Notes and Domino made this argument in the 1990s and made it well. Build your applications on our foundation, shape them to your business, and you will not start from nothing each time. Oracle Forms offered a version of the same bargain, and every generation since has offered its own. These were real advances, and they worked within a specific limit. You configured inside the vendor's object model, their workflow engine, their form builder, their data structures. Tailoring meant working within the shapes their designers had anticipated, and when a business needed something they had not anticipated, you were into custom development against their interfaces, carrying whatever upgrade risk that created, or you were waiting for a roadmap item. The platform defined the space of possible systems and your business found a place inside it. Anyone who maintained a substantial Notes estate remembers both halves of that: how much you could build, and how completely stranded you were once you needed something the model did not contemplate. That pattern did not end with Notes. It is the design of every configurable enterprise platform sold since, and the wall arrives at a different point for each company depending on how conventional its operation is.

Three things changed, and the third matters most.

The foundation stopped being where the value sits. The data layer, orchestration, storage, integration plumbing, and conventional application logging were what platform vendors charged a premium for, and having built inside them you could not leave, which was the point of the arrangement. Those components are now infrastructure. The precedent is what AWS did to compute: racking servers went from a capital requirement that favored large companies to something rented by the hour, and the interesting work moved up the stack. Worth noting that the last round of commoditization stopped short of the buyer. Infrastructure became cheap, the application layer above it did not, and the savings were largely retained by vendors. What is different now is that the commoditization has reached the application layer itself, which is the layer a buyer actually pays for.

What is different now is that the commoditization has reached the application layer itself, which is the layer a buyer actually pays for.

What replaced the foundation as the difficult part is governing systems that act. When software recorded what people did, knowing who changed which record and when was sufficient, and that has been a solved problem for twenty years. When a system makes determinations and executes transactions on an organization's behalf, the questions change: what was it permitted to do, what did it actually do, was the output correct, can you stop it, and can you produce evidence that holds up when a regulator, a customer, or a court asks. That discipline did not exist as an established practice three years ago. It is where our own work is concentrated, and it is the subject of a later section.

What replaced the foundation as the difficult part is governing systems that act.

The third change, and this is the unlock at this layer, is that the part which makes a system fit a particular business is now generated against that business's real process rather than configured within someone else's structure. There is no object model to talk yourself into. When the process changes, that layer is rewritten rather than worked around. On our current engagements roughly half the required capability is already present as foundation, and the fitted layer, which brings the system to parity with whatever it is replacing and adds the items that were on the client's wish list and on no vendor's roadmap, has taken two to three days to reach a working state.

The remainder comes from the people who use it, and that portion does not close. Once a team is working in a system every day, they see things nobody could have written into a requirements document, and those observations keep arriving for as long as they keep using it.

There is a further consequence that is easy to miss. When tailoring is inexpensive, access stops being something you ration. Software priced per person means a twenty-person department gets twelve licenses and someone maintains a spreadsheet for the other eight. That rationing has always carried a real cost in duplicated work and lost visibility, and it has never appeared as a line item in any budget.

The practical consequence of the first two layers together is that the document most organizations have never written, the honest list of what would make the operation genuinely good, stops being a fantasy and becomes a queue. I would encourage any leadership team to write that list before their next software decision, without regard to what is currently for sale, because it is now a more useful input than a requirements matrix.

#The third layer: what happened to delivery

The change in delivery is less discussed than the change in coding, and for a buyer it matters more, because it is what determines the price.

Writing software has become faster and, with disciplined review and test coverage, more reliable than it was. What is equally consequential and rarely mentioned is that every other function involved in delivering a system improved at the same time. Requirements analysis, project scheduling, risk registers, test planning and execution, visual specifications and interface design, documentation, and client reporting have all become faster and more accurate together.

In our own delivery organization, the project manager produces schedule updates, risk management, and planning in a fraction of the time it previously took, more accurately, with clearer client communication than we have run before, and performs business analysis alongside it. Our analysts write, ship, and test code. The boundaries between roles have thinned considerably, and a small team now carries work that would previously have required several times the headcount. Having delivered enterprise systems through traditional means, my considered assessment is that the same scope, delivered this way, is achieved at a fraction of the cost and the time.

The same shift is visible at the top of the market, where Accenture has been explicit about separating revenue growth from headcount, and HFS Research's tracking across more than 25 major providers shows revenue and margin per employee rising while headcount stays broadly flat. Most organizations will never engage Accenture, which is exactly why the change matters to them. Work that used to sit below every credible provider's cost floor can now be delivered at a workable margin.

#The fourth layer: continuous fit

The fourth change has the most consequence for how software should be bought, and it inverts the order enterprise software has used for decades.

A requirements document is assembled from what a buyer has watched vendors do. It encodes the capability of the previous generation and then scores vendors on how closely they match it. Every subsequent decision narrows the outcome, and all of the narrowing happens before anyone has seen anything actually run. Nobody can specify a capability they have not seen working, which means that writing the specification first quietly sets a ceiling on the result.

Nobody can specify a capability they have not seen working, which means that writing the specification first quietly sets a ceiling on the result.

What we run instead is a loop rather than a project. I have taken to calling it continuous fit, which is less a methodology than a name for what actually happens once the cost of a change falls far enough. Use it. See what is possible. Decide what matters. Build it. Use it again.

• Use it

• See what is possible

• Decide what matters

• Build it

• Use it again

It begins with the wish list rather than the requirements list, and puts a working system in front of the client's team as early as possible. They use it in their actual work, not in a demonstration and not against a test script. Using it surfaces things nobody could have written down in advance, and the feedback at that stage is granular in a way that no analysis phase produces, because it comes from operating the thing rather than imagining it. Their leadership collects those ideas, triages them, and sets priority. We build them in, and they use the result, at which point they see capability they had not previously known to ask for, and the next round of ideas follows from that.

The principle underneath it is that capability you can see generates requirements you could not have written. Value compounds through use rather than through planning, which is why the loop produces better input each time it turns, and why a fixed backlog worked through to completion is the wrong mental model for this.

The principle underneath it is that capability you can see generates requirements you could not have written.

Two conditions make it work, and without either one it is something else.

The buyer owns the queue. The client's leadership decides what gets built and in what order, and the cadence belongs to them rather than to us. In practice it slows over time, for a reason worth understanding: they become better at triage. Early on everything appears urgent because everything is newly possible, and a few cycles in their leadership is making sharper decisions about what actually matters. A vendor whose commercial model requires the cadence to stay high is optimizing for something other than the client's outcome.

The gates do not move. The cycle turns in under a week, and it turns through the same discipline that responsible delivery has always required. Work is built, promoted to a staging environment, and tested there against realistic data rather than against a developer's assumptions. Regression testing runs across the existing system, not only the new work. Security and performance hardening happen before promotion, not after an incident. The client conducts acceptance testing on a pre-production environment that mirrors production, and nothing reaches production without passing that gate. What has changed is not the discipline. It is that generating the code, writing and running the test coverage, producing the documentation, and preparing the release used to consume most of the elapsed time in that sequence, and now they do not. The testing is more thorough than we used to be able to afford, because the cost of writing and running it fell alongside everything else.

We run one-week sprints because two weeks has become too long, and a single week now carries considerably more than a month of work did under the previous arrangement. Two cycles is typically enough to reach production. From there the buyer's central task shifts from writing requirements to triaging their own ideas, which is a considerably better use of an executive team's judgment.

I did not set out to design any of this. We arrived at it because the old sequence stopped making sense once a change took days instead of months, and having run it on several engagements now I am reasonably confident it is the right shape rather than a local habit. Whether it holds up under other people's conditions is a fair question, and I would be interested in the answer.

#Why this is safe to run at speed

Speed of this kind is only responsible when the control layer is genuinely present, and I want to be direct about that, because it is where most of the risk in this model sits. My colleague Roshnee Sharma has argued that speed and safety are not a trade-off, and has made the longer version of the case in GeekWire in Why Moving Fast with AI Shouldn't Mean Sacrificing Safety. I agree with the argument, and what follows is what it requires in practice.

When a system acts on an organization's behalf, that organization carries the consequences. Four things are required: control over what the system may do, visibility into what it actually does, the ability to stop it, and proof of what happened. The last matters most. When an auditor, a regulator, a customer, or a court asks why the system did something, the organization has to be able to answer, and the answer has to hold up under examination.

This requires access to the layer where control actually lives, which a closed platform does not provide, and it requires expertise in the discipline itself. Deploying AI is now the straightforward part. Governing it is the work. On our platform, deployment, governance, observability, evaluation, and audit are one system rather than separate products, so that every determination is recorded to an exportable audit trail, escalation to a person is conditioned on measured confidence rather than on a fixed rule, and generated output can be reviewed, corrected, or suppressed by an administrator on the client's side.

Deploying AI is now the straightforward part. Governing it is the work.

Without that layer, a fast cycle produces liability rather than advantage. Retool's 2026 survey of 817 builders found that 60 percent had created software outside any formal oversight in the prior year, which is the predictable consequence of inexpensive production without governance. Software that is cheap to produce is not free to own, and someone has to maintain it, secure it, and answer for it when it fails.

#What you pay for

The clearest measure of a generational change is usually what a customer is asked to pay for, and this is where the two models diverge most sharply.

The previous generation sold access. A license fee, plus a charge for every person who touched the system, billed whether or not the software performed any work in a given month, with each configuration change scoped and billed separately as a services engagement.

We charge for work performed rather than for access. The platform license is free, user access is unlimited with no per-seat charge, and maintenance and support are included. Ordinary administration, review, configuration, and reporting are not billed. The consequence, and the reason this matters more than any particular rate, is that cost stops scaling with two things at once: with how much a customer tailors the system, and with how many people use it. Those were the two mechanisms that made tailored software unaffordable, and removing both is what makes continuous fit economically rational for the client rather than only for the vendor.

If you would like to see what that pricing logic produces rather than take my description of it, Autessa E-Signature is free, with unlimited users and unlimited envelopes. It is a component of the platform rather than a separate product, which is precisely why it can be given away, and it is the same system we execute our own agreements through.

#Planning a replacement, an upgrade, or a new purchase

For an organization approaching a software decision this year, I would suggest the following, and I recognize that some of it runs against how procurement is conventionally organized.

Begin with the wish list rather than the requirements matrix. Ask what would make the operation genuinely good if nothing were for sale, and treat that document as the primary input. It is now a more accurate description of what you can obtain than a requirements list assembled from vendor demonstrations.

Ask to see one item from that list running against your own data, on your own metrics, before money changes hands. This is the practical form of the shift, and it is the single most useful thing a buyer can insist on. We propose engagements this way as a matter of course: discovery, a measured proof of value on the client's actual data, and the formal test campaign are provided at no cost, with delivery proceeding through acceptance-gated milestones and no advance payment. A vendor confident in what they have built should be willing to demonstrate it before invoicing for it.

Expect your requirements to change, and plan for it rather than resisting it. Once a leadership team sees what is possible, its list changes, and that revision is the return on the exercise rather than a failure of planning. A vendor who treats new ideas as scope creep is describing what the next three years will be like.

Then settle four questions, and treat contract term as the last item rather than the first. What is the cycle time, and what does a change cost inside it, not the first configuration during implementation, which is priced into the deal and invariably looks reasonable, but the eleventh one in month twenty-two when your process has moved and the implementation team is on another account. Who decides what gets built, because if the answer is the vendor or a product roadmap committee you will never meet, the cycle belongs to them rather than to you. What exactly are you being charged for, whether that is people, documents, records, transactions, or results, and what does that unit have to do with the value you receive. And what leaves with you, meaning your data, in open formats, whenever you ask rather than only at termination.

On term length, I would be cautious rather than categorical. A long term is not inherently a problem, and it often buys a better price. The risk is committing for five years to the previous generation's architecture and commercial model while the shift is still in progress, which is a different thing from a long relationship with a supplier whose model has already moved.

#What this looks like in practice

The engagement referenced throughout involves an organization replacing an off-the-shelf product that had stopped matching how they work. Roughly half the required capability was already present on the platform. The tailored layer, bringing the system to parity with what they were replacing and adding items from their own wish list, took two to three days to reach a working state.

We then put it in front of their team on a staging environment, where they used it, tested it, and trained on it, and the feedback that came back was detailed in a way that no requirements process would have produced: specific flows, specific nuances, specific exceptions. We built those in. They used the improved system, saw capability they had not previously known to ask for, and produced a further set of ideas. Their leadership triages and prioritizes; we build, promote to staging, run regression and security testing, harden, and put it through client acceptance on pre-production before anything is deployed. Two cycles brought it to production, and it has continued at a cadence they set.

Their assessment, which I report as theirs rather than as a claim of my own, is that this has been the best software purchase and implementation experience they have had, and that it has cost considerably less than they expected. The part I find most significant is not the speed. It is that their leadership now spends its time deciding what their systems should do next, rather than negotiating with a vendor about whether a change is in scope.

It is that their leadership now spends its time deciding what their systems should do next, rather than negotiating with a vendor about whether a change is in scope.

#The honest limits

Three qualifications, offered directly rather than buried.

Speed to a working system is not the same as speed to production. Days to a system comparable to an off-the-shelf product is an accurate claim. Days to a hardened, integrated, governed production deployment is not, which is why the engagement above required two cycles to reach production rather than two days. Staging, regression testing, security and performance hardening, and client acceptance on pre-production are not steps this model removes. They are the steps that determine whether any of the rest of it is trustworthy.

Production cost is not ownership cost. Something built quickly still has to be maintained, secured, and answered for. This model works because the platform underneath carries governance, audit, and control as standard, and it would not be responsible without that.

Not everything should be built. We use Mailchimp for email marketing and third-party tools for analytics, because both are inexpensive, mature, and unrelated to how we compete. The rule we apply is to build what is core to the business and what shapes how we work, and to buy what is commodity. Having the capability to build makes that judgment more consequential rather than less, and an organization that builds reflexively will end up with the shadow IT problem rather than the advantage.

#What this opens up

I have spent most of my career on the delivery side of enterprise software, and the part of this I did not expect is how much better the work has become for the people doing it.

A project manager who spent most of a week maintaining a schedule and a risk register now produces both in a fraction of the time, more accurately, and spends the recovered hours on business analysis and on the client relationship. An analyst who used to hand a specification to a developer and wait now builds and tests the thing directly. A consultant who could only ever afford to serve large accounts can now do serious work for organizations that were previously below the economic threshold. These are not efficiency gains in the usual sense. They are people doing more of the work they are actually good at and less of the work that existed because the tools were slow.

The customer receives the benefit of all of it at once: software shaped to how the business actually works, everyone who needs it able to use it, improvements arriving in days and properly tested, and a total cost that is materially lower than the previous generation could offer. The organization gets better at its own operation as it goes, because each round of improvement shows the team something they could not have known to ask for at the start.

The constraint on what your systems can be is no longer your budget, your vendor's roadmap, or your IT department's capacity. It is the quality of your own ideas about how the business should run, and how well you prioritize them. That is a far better problem to have, and it is available now.