Twenty Years of Software Licensing: What Actually Changed, and What Didn't

When we started, the technology landscape was unrecognisable. No smartphones. And what we now call cloud was called ASP — application service provider.

The problem we set out to solve was concrete and expensive. If you wanted to license your software back then, you bought servers. Lots of them. Every customer ran their own infrastructure, installed the software, and staffed a department to keep it alive.

To make that concrete: a typical 2005 deployment meant a customer's IT team racking physical servers, installing an operating system, patching it, then installing your software on top — and doing that again for every environment, development, staging, production, sometimes three or four times over per site. A licensing change meant someone reissuing a physical dongle, mailing a floppy disk or CD with an update, or editing a configuration file by hand, on-site, months after the change was actually decided. If a customer ran ten locations, you had ten points of failure and ten different people who could get the entitlement wrong. None of that was exotic technology. It was plumbing. But plumbing multiplied by every customer, every site, every version, is what made the whole model expensive to run and slow to change.

Our idea was to host that infrastructure centrally on behalf of customers — what we'd now call multi-tenant. The benefit was immediate: no servers, no maintenance, no dedicated staff, no per-installation licence fees for the supporting infrastructure. You signed up for something in the cloud and it was handled.

That sounds unremarkable in 2026. It was not unremarkable in 2005.

Alongside it, my co-founder did work that was genuinely early — the first thesis on software license management, and encryption far more robust than the norm at the time. We also invented processes that became two issued US software patents, which are difficult to obtain and which we still hold.

It's worth being specific about what those patents actually cover, because "we have patents" is a claim vendors throw around loosely. US 8,843,745 and US 9,467,427 cover methods for controlling and enforcing software licensing centrally, across a network, rather than trusting each individual installation to police its own rules. That distinction — enforcement that lives with the vendor, not with the copy of the software sitting on a customer's machine — is unremarkable now because it's how every SaaS product works by default. In 2005 it wasn't the default; it was the thing you had to invent, and then persuade a patent examiner it was genuinely novel rather than an obvious rearrangement of existing techniques. Most applications don't clear that bar. Ours did, twice, and the underlying principle hasn't needed revising since.

Three shifts stand out, and only three.

Software left the desktop. What we called enterprise software — the thing running on servers and desktops — is now predominantly a phone app, a tablet app, or something in a cloud environment. We adapted to cover all of it, but the underlying need never moved: whatever the deployment, someone has to know what each customer is entitled to.

Hardware became software-defined. This one I find the most interesting. Twenty years ago, a manufacturer wanting twenty variants of a product built twenty products.

"Today, you make one version of a piece of hardware and you use Nalpeiron to control the 20 different flavors of the same hardware."

Manufacturing streamlines dramatically. The differentiation moves into entitlements. That's a genuine business-model change, not a technical detail — and it arrived without much fanfare. We've gone deeper on what software-defined hardware monetization actually looks like in practice elsewhere; here I just want to note how quietly it happened.

Portfolios stopped being homogeneous. This is the change most vendors underestimate. Our customers rarely make one kind of thing. They make hardware and on-prem software and mobile apps and SaaS — often mid-transition, with legacy products still generating real revenue alongside new cloud ones.

That's why we built toward what we call one pane of glass: all of it on one platform. Not because unification is elegant, but because managing four licensing systems across four deployment models is how companies end up unable to change anything.

Now the constant.

In 2005, software companies hardcoded their licensing logic into their products. In 2026, software companies hardcode their monetization logic into their products. Same instinct, same consequence.

It's easy to see why it happens. Nobody sets out to build a monetization system. You're a startup, you need to charge for something, you write the smallest amount of code that works. Then you add a tier. Then a feature flag. Then an enterprise exception. Ten years later:

"It's like spaghetti basically. You've got 10 years worth of this stuff all wrapped up in your product."

Nobody decided this. It accumulated. And the cost stays invisible right up until the moment you need to move quickly — at which point it becomes the only thing that matters. We've written in more detail about how homegrown licensing systems get to this point — this piece isn't that post; I only want to note that I've watched it happen at close range for twenty years, and it never announces itself as a decision. It just accretes.

For most of the last twenty years, hardcoded monetization was a manageable liability. Pricing changed rarely. An annual repackaging exercise absorbed into the roadmap was survivable.

AI ended that.

"Only a few months ago, the whole world changed upside down and has become very consumption-driven because people buying AI want to do it by the query. They don't want to buy seats. They don't want to buy features."

Software vendors everywhere are now being asked by their customers for consumption pricing. Not eventually — now. And the request keeps changing, because the market is still working out what these products are worth.

That's what turned an old, tolerable liability into an acute one. The failure mode is no longer inefficiency; it's competitive:

"If your primary competitor changes their price and they package differently from one week to the next, you must respond immediately or you will be toast. That is the law."

I stand by the phrasing. In a market where buyers have ten alternatives, being three months behind on pricing is indistinguishable from being three months behind on product. For the more technical version of why this shift happened when it did, we've laid out the mechanics of usage-based billing's rise separately; the short version is that metering infrastructure finally got cheap and reliable enough for anyone to offer it, so buyers started expecting it everywhere.

The lesson of twenty years, compressed: monetization logic does not belong in product code.

We've written before about what that looks like architecturally — treating packaging and pricing as configuration, not code. This piece is the twenty-year path that led us to that principle, not a restatement of it. And it's a different question from whether you should build that separation yourself or buy it — that's a build-versus-buy decision; what I'm describing here is simply where the logic needs to live once you've made it, regardless of which way you go.

Engineering writes once to a platform. After that, the product team configures pricing, packaging and models directly.

"Instead of waiting 6 months for the engineering team to say 'sure, I figured out how to do consumption models' — we can do that in a weekend now."

There are two beneficiaries, and the second is usually overlooked.

The product team gets to run experiments — try a consumption tier, watch what happens, adjust. Pricing becomes iterative rather than a once-a-year commitment.

Engineering gets something arguably more valuable: the queue outside their door disappears. They stop being the bottleneck for every commercial decision and go back to building product. In my experience that constant interruption is one of the more corrosive things you can do to an engineering team — not because the work is hard, but because it's endless and it isn't theirs. If you want to see the shape of what teams configure once that separation exists, our documentation walks through the current pricing models for modern SaaS and AI.

We're now watching this pattern repeat with AI, which is why our position is deliberately narrow:

"Our policy on AI is to supercharge our customer, not replace our customer."

That policy shapes the product too, not just the sales team. When we built metering for AI-era consumption pricing, the goal was the same: give vendors the infrastructure to price AI the way their buyers now expect — by the query, by the token, by whatever unit makes sense — without asking them to replace judgment with automation everywhere else.

Applied to sales, that means using AI for the research, the data gathering, the scheduling — the work that consumes a rep's day without using their judgment. It does not mean replacing the rep. I'm a CEO; people sell to me constantly:

"When it comes down to having a negotiation, I want a human."

I'm content for AI to book the meeting, prepare the brief, surface the data. When I'm deciding where to spend money, I want to talk to a person who can answer an unexpected question.

There's a cautionary precedent here. We once automated customer phone support enthusiastically, and produced a decade of experiences nobody enjoyed. It was cheaper, and it was worse. The lesson wasn't that automation is bad — it's that automating the relationship rather than the drudgery destroys value while appearing to save money.

Two things, from twenty years of watching this.

Assume your business model will change more often than you expect. Whatever you build in year one, you'll want to change in year two and rethink in year three. Build for that, or you'll spend year five untangling spaghetti while a competitor reprices in a weekend.

Separate what you sell from how you charge for it. The product is your differentiation. The mechanics of entitlement, metering and packaging are infrastructure. Treating infrastructure as differentiation is how good engineering teams end up maintaining billing logic instead of building products.

Deployment models changed. Devices changed. Buying behaviour changed. The instinct to hardcode monetization never did — and that instinct now costs more than it ever has. If you're looking at your own product right now and recognising the spaghetti, that's usually the moment worth talking to someone about it — we're glad to compare notes.