Software inventory is cheap. Organizational context is not.

The app is no longer the hard part.

That sentence sounds more dramatic than it should. For a lot of business software, it is already true.

I do not mean “software is easy” in the lazy conference-panel sense. I mean something narrower and more dangerous for the current software market: the cost of producing a working application is collapsing faster than the cost of understanding the organization that application is supposed to serve.

The screen is getting cheap. The context is not.

TL;DR

• AI makes more software economically disposable. A CRUD app, admin dashboard, workflow tool, customer portal, or internal reporting surface is increasingly closer to inventory than a durable asset.
• That does not mean SaaS disappears. It means the old amortization logic weakens where customers can generate or commission their own version quickly.
• The durable value is shifting above and around the app: distribution, trust, governance, domain expertise, customer relationships, permissions, history, and operational continuity.
• Just-in-time software makes organizational context more valuable, not less. If apps can be spun up, replaced, or rewritten quickly, something stable has to remember what the organization knows and what it decided.
• My position: generated software commoditizes the surface. Governed organizational context becomes the asset.

Software As Inventory

Sidu Ponnappa’s essay There Is No Product is the sharpest version of the software-as-inventory argument I have seen.

The basic idea is simple. Traditional software companies treated code as an asset because the code was expensive and risky to produce. You invested millions into building a product, then amortized that investment across customers through subscription revenue. The product was valuable because reproducing it was hard.

If reproducing it stops being hard, the economic story changes.

That is not a philosophical point. It is a pricing point.

If a company can build the same internal tool in a weekend, or pay a small services team to build and maintain a customer-specific version for less than the annual SaaS bill, the vendor has a problem. The vendor is no longer selling access to scarcity. It is selling access to something the buyer can manufacture.

This is why the usual “is SaaS dead?” debate feels too shallow. SaaS is a delivery and commercial model. Hosted software sold by subscription is not going away. Nobody is nostalgic for installing enterprise software from a box.

The sharper question is whether the software itself is still hard enough to deserve asset economics.

For some categories, yes. Compilers, serious infrastructure, deep simulation, regulated engines, real-time trading systems, complex tax logic, products built on proprietary data, and anything requiring years of accumulated domain judgment are not weekend projects. The code is not the moat by itself, but the understanding encoded inside the system still matters.

For a lot of the business software market, though, the moat was not as deep as vendors wanted to believe. It was mostly the customer’s fear that building software would be painful, expensive, slow, and impossible to maintain.

AI is attacking that fear first.

”SaaS Is Dead” Is The Wrong Frame

The punchy take is that SaaS dies. I think that is too clean.

SaaS will get squeezed unevenly. Developer tooling gets squeezed first because developers have agency, taste, and the ability to replace their own tools. Akash Bajwa’s write-up from an Anthropic roundtable, The Future Of Software Engineering, makes this pattern explicit: teams are already replacing incident tools, auth layers, project tracking surfaces, and small internal utilities, while business-facing systems remain stickier.

That stickiness matters.

The CRM is not just a table of accounts. It is the place the sales team trusts, the place the CRO reports from, the place RevOps has permission rules, the place account notes accumulate, the place renewals trigger, the place the board number comes from. Most CRMs are ugly. Many are hated. They survive because replacing the app is not the same as replacing the operational role it plays.

Same with HR systems. The performance review module might be bad, but it carries the comp cycle, the permission model, the calibration history, the audit trail, the angry conversations about who can see what, and the legal risk if the wrong person sees the wrong thing.

Same with finance workflows. The approval screen is the easy part. The hard part is knowing which exceptions are allowed, which vendor names are aliases, which budget owner is on leave, which controller will reject a category, and which process exists only because of an incident three years ago.

Apps are visible. Organizations are messy.

That mess is where the value moves.

What Is Not Cheap

AI makes it cheaper to generate a lot of software. It does not make the following cheap.

Distribution. Getting software in front of the right buyer is still hard. Trusting a vendor enough to run payroll, renewals, compliance, or customer support through it is even harder. The average company does not want 400 random internal apps nobody owns. It wants fewer problems.

Trust. Security reviews, vendor risk, uptime history, support quality, procurement relationships, and reputation do not get generated overnight. A passable app can appear in a weekend. A trusted operational system cannot.

Permissions. Access control is where toy software meets the organization. Who can see compensation? Who can approve a refund? Who can export customer data? Who can override policy? Who can impersonate a user? These rules are political, legal, and operational. The UI is the least interesting part.

Workflow reality. The process written in Notion is rarely the process people follow. Real workflows have side doors, escalations, exceptions, stale fields, informal approvals, Slack pings, and “ask Maria because she knows the old system.” AI can help uncover this, but it cannot invent the truth from nothing.

Domain context. Pharma documentation, logistics planning, insurance claims, B2B renewals, clinical translation, industrial QA, and enterprise procurement all have language that looks obvious only after you have lived with it. Generic software can mimic the shape. It cannot automatically know which detail matters.

History. Why was this rule created? Which customer promise forced this exception? Which integration broke last quarter? Which metric did leadership stop trusting? Organizational memory is a graveyard of expensive lessons. Most companies barely preserve it for humans, let alone agents.

Compliance and auditability. A generated workflow might work. That is not the same as being explainable, controllable, reviewable, and defensible. Regulated organizations need to know who changed what, why, under which authority, with which evidence.

Continuity. The software can change every week. The business cannot forget every week. Customers still need support. Employees still need consistent processes. Finance still needs a close. The board still wants one number.

This is the part I think many AI software takes miss. They are obsessed with the replaceability of apps and underweight the continuity burden that appears when apps become replaceable.

Cheap Apps Increase The Need For Durable Context

Andrew Montalenti calls the new pattern Just-In-Time-Software: software generated when needed, by agents, often as part of a broader knowledge-work task. His broader point is that programmers are seeing the future of knowledge-work automation first. We are the weird early adopters because code is verifiable enough for the models to act.

I buy that.

But just-in-time software has a shadow requirement: just-in-time software needs not-just-in-time context.

If every team can spin up a custom app, who knows which app is authoritative? If an agent generates a new support dashboard for a customer escalation, where does it learn the account history? If RevOps replaces a renewal workflow, how does the next workflow inherit the exception logic from the old one? If the HR team generates a new calibration tool, who guarantees it respects the permission decisions from the last cycle?

The app can be temporary. The context cannot be.

This is the architectural shift I care about. The durable layer moves from “the application” to “the governed work graph around the application.” The app becomes a view, a tool, a temporary surface over a more persistent system of facts, decisions, permissions, relationships, and commitments.

That sounds abstract until you look at a real organization.

A customer record is not just fields. It is the deal history, the contract, the last support incident, the expansion conversation, the security questionnaire, the champion who left, the implementation promise someone made on a call, and the internal debate over whether this account is strategic or just loud.

A project is not just tasks. It is the decisions, blocked dependencies, rejected approaches, ownership changes, deadlines, political constraints, and “we already tried that in March” context.

A compliance workflow is not just steps. It is evidence, sign-off, policy, audit trail, version history, exception handling, and the ability to explain the decision later to someone who was not in the room.

Generated software can make a nice surface for all of this. It cannot be the only place this lives.

The Complement Moves

There is a useful analogy in infrastructure. Almog Gavra’s broken economics of databases argues that value capture in databases is distorted by complements: cloud providers own much of the infrastructure needed to commercialize the database, while database vendors fight commoditization through differentiation, managed operations, and sometimes complexity.

The same broad pattern applies here. When the core artifact becomes easier to reproduce, value moves to the complements.

For business software, the complements are not only compute and hosting. They are go-to-market, trust, integration depth, proprietary data, operational know-how, workflow ownership, compliance posture, and customer intimacy.

This is why “we can generate the app” is not the same as “we can replace the business.”

A vendor with weak software but deep distribution can survive longer than a better tool nobody trusts. A vertical SaaS company with mediocre screens but ten years of regulatory edge can survive longer than a generated clone. A services company that understands the messy customer process may capture more value than a horizontal app that has cleaner UI but no operational memory.

The market will punish software that was only software.

It will reward systems that know the work.

The Real Product Is Knowing What Should Happen

The most valuable question in an organization is not “can we build an app for this?”

Increasingly, yes, you can.

The valuable question is “what should happen?”

Should this lead route to enterprise sales or self-serve? Should this document be translated by AI, reviewed by a pharmacist, or rejected because the source is stale? Should this vendor payment be approved, escalated, or blocked? Should this customer get a refund, a roadmap commitment, or a hard no? Should this agent be allowed to take the action or only draft it?

Those questions depend on context.

They depend on who the customer is. What was promised. Which rules apply. Who has authority. Which exceptions are acceptable. Which past decision should not be reopened. Which policy is real and which one is a document nobody follows.

That is why I do not think the end state is everyone drowning in bespoke micro-apps. That is chaos with better code generation.

The end state that makes sense is more like this: durable organizational context underneath, generated or replaceable software surfaces above, governance wrapped around both.

The software gets more fluid. The context gets more important.

Why I Am Building Around Memory

I am biased here, because this is one of the reasons I started building 3ngram.

Not because I think “memory” is a cute feature. I think memory is becoming infrastructure. More specifically, shared work state is becoming infrastructure.

Every AI tool I used had the same failure mode. It could produce impressive work in a session, then forget the decision that made the work coherent. Switch tools, start a new chat, move from writing to coding, hand off from one agent to another, and the organization leaks through the gaps.

That is annoying for an individual. It is fatal for teams.

If agents are going to create, modify, inspect, and operate software across an organization, they need access to more than documents. They need the current state of the work: decisions, commitments, blockers, ownership, history, permissions, and the reasons behind rules.

The user feels this as shared context. The deeper strategic layer is a governed work graph.

That is not the only way to build it. But some version of it has to exist if applications become more disposable. Otherwise every generated app becomes another place for context to fragment.

The Takeaway

The mistake is to think AI makes software worthless.

It does not.

It makes some software less scarce. That is different, and more interesting.

When the cost of generating an app falls, the market asks a harder question: what else do you have? Do you have distribution? Trust? Domain expertise? Data? Governance? Workflow ownership? Continuity? Do you know the customer’s work better than a generated clone can? Do you know what should happen inside the messy organization after the button is clicked?

If the answer is no, you are probably holding inventory and calling it a product.

If the answer is yes, the app may become cheaper and your position may still get stronger.

Generated software commoditizes the surface. Governed organizational context becomes more valuable.

That is the shift.