Author: Alex Carry

Commercial clarity is not a communication skill. It is a thinking skill that shows up in communication. The developer who can explain what software does for the person who needs it done — in the specific language of the problem that person lives with every day, not the technical language of the solution being constructed — demonstrates that they have thought about the customer’s situation from the customer’s position rather than from the engineer’s. That discipline is rarer than it sounds, because most technical communication is optimised for peer recognition: it tells other engineers what the code does and why the architecture is elegant. Peer recognition is a legitimate goal for academic and collaborative technical work. It is the wrong goal for commercial work, because the person who renews the contract is not evaluating elegance. Friction is the compounding mechanism through which misaligned product communication produces churn that registers as competitive loss — an attrition pattern that often traces not to product quality but to the gap between what the product does and what the customer understands it to do in their specific context. The commercial developer closes that gap through precision of description, not enthusiasm of pitch. The pitch follows from the precision. The precision is the work, and the work is what makes the difference between a developer who ships and a developer who sells.

 

TL;DR

The durable moat for developers and product managers is no longer pure technical output. It is customer proximity, commercial literacy, and the ability to translate work into outcomes the business and the user can both feel. Technical brilliance still matters, but brilliance from a distance is becoming less valuable because AI raises the output ceiling while shrinking the market’s tolerance for passengers. The builder who stays close to users, hunts friction, and understands value creation is becoming more defensible than the builder who hides behind systems, process, or elegant abstractions.

---

The new builder is uncomfortable by default because truth lives closer to the customer than to the roadmap.

 

The point is not to abandon craft. It is to reconnect craft to terrain, users, and consequences.

 

Disclosure: This page is editorial analysis built from the Reddit/developer cluster source material and supported by widely cited operator frameworks around customer obsession, founder-led learning, and product feedback loops. Sources appear near the end.

 

The market used to fund a certain kind of technical insulation.

A developer could live inside code. A product manager could live inside tickets and planning ceremonies. As long as the broader machine kept growing, that distance from the user was survivable. But the old arrangement is weakening. AI makes output cheaper, teams are leaner, and the tolerance for work that cannot explain its commercial value is shrinking. That is why the real career moat is moving.

This is the practical extension of the broader Reddit/developer thesis. The question is no longer whether you can ship. The question is whether what you ship changes the right thing for the right user in a way that holds up commercially.

 

Proximity Beats Brilliance

Technical brilliance is seductive because it is visible. It offers status, narrative, and a clean internal identity. But brilliance without customer proximity often turns into a beautifully sharpened spear thrown blindfolded into the forest.

The market does not reward elegance in the abstract. It rewards tools that solve problems for real people. That is why distance is denial. Teams that rely on abstractions alone start treating the customer like a dashboard category instead of a living source of truth. Once that happens, technical confidence can become a shield against learning rather than an aid to it.

The builder who stays close to users sees weak signals earlier. They notice where friction is building, where usage is narrowing, and where the product is drifting from the job the customer is actually trying to get done. That makes them more commercially valuable even if someone else writes cleaner code.

 

What Amazon Got Right

Amazon’s Working Backwards process remains one of the cleanest cultural antidotes to product delusion because it forces the team to explain value before building anything complicated.

Starting with a press release and FAQ is not ceremony for its own sake. It is an anti-bloat device. It forces the builder to answer the dangerous question early: who benefits, how, and why should they care? If the team cannot explain the customer outcome in plain language, it probably does not understand the product well enough to build it confidently.

That is why Working Backwards matters here. It drags technical ambition through commercial reality before engineering effort becomes sunk cost.

 

Founder-Led Sales Was Never About Hustle

Paul Graham’s “Do Things That Don’t Scale” is often reduced to founder hustle mythology. That misses the deeper point. Early customer work is not merely labor. It is an information system.

Manual onboarding, direct demos, churn follow-ups, support replies, odd pricing experiments, and raw conversations all produce the kind of information that dashboards often miss. They break product delusion early. They force the team to confront where value is real, where friction lives, and where assumptions are weak.

This is why founder-led sales and direct user contact still matter so much in young companies. Not because the founder should remain a permanent bottleneck, but because distance too early is one of the fastest ways to build the wrong thing with total confidence.

 

Friction Hunting Is Commercial Work

A lot of builders still treat friction as a UX issue. It is broader than that. Friction is commercial leakage.

Tiny points of confusion, delay, doubt, or interruption do not always generate loud complaints. Often they generate silent churn. The user gets slower, less engaged, less trusting, or quietly more willing to try an alternative. That is why friction hunting matters so much. The builder who studies session behavior, reads support pain, interviews users, and traces weak spots through the journey is not doing “soft” work. They are defending retention and revenue.

This is also where the commercial developer differs most from the insulated builder. They do not assume the product is self-evidently good. They look for the tax it is silently imposing.

 

What The Commercial Developer Actually Does

• Starts with the customer problem: not with the feature inventory.
• Stays close to users: support, demos, feedback loops, and churn follow-ups are normal work.
• Explains value plainly: if the outcome cannot be articulated, the work is not ready.
• Hunts friction relentlessly: because silent drag often matters more than loud bugs.
• Bridges technical and commercial reality: product, user, pricing, and retention live in the same frame.

That is not a personality type. It is an operating model.

 

Sources

• Paul Graham, Do Things That Don’t Scale
• Amazon leadership principles and customer obsession context
• FullStory on user friction
• Contentsquare on friction and drop-offs

The Product-Discipline Read On Why Commercial Developers Are Rare

Every product organisation I have worked with has a small number of engineers who, in addition to writing the code, understand the customer well enough to make the dozens of small product decisions a day that no one else is positioned to make. These are the commercial developers the article describes. The product-discipline question worth asking is not whether they are valuable — they obviously are — but why so few of them exist, and what the organisations that produce more of them are doing differently from the organisations that produce almost none.

Most organisations actively select against the commercial-developer profile without realising they are doing it. The hiring process screens for technical depth and treats customer literacy as a soft skill that will develop on the job. It does not develop on the job, because the job is structured around tickets that arrive pre-decided, sprints that close on time-based cadence rather than outcome-based milestones, and a product-management layer whose existence implies that the engineers are not supposed to be making product decisions in the first place. Each of these structural choices is individually defensible. Combined, they produce an engineering function that has been organised, intentionally or not, to keep customer proximity out of the daily work.

The organisations that produce commercial developers do something different. They hire for both — technical depth and a demonstrated curiosity about the customer’s actual problem. They put engineers in front of customers regularly, not as a one-off but as a structural part of the role. They organise around outcomes that require the engineer to make product calls, and they hold the engineer accountable for those calls in a way that builds the commercial muscle over time. The product manager becomes a partner in the decision-making, not a buffer between the engineer and the customer. None of these moves are expensive. All of them require a leadership team that has decided customer literacy is part of the engineering job, not a separate function that engineering hands off to.

The competitive implication is that commercial-developer density predicts product-iteration quality more reliably than headcount does. A team of fifteen engineers with three commercial developers will out-ship a team of forty engineers with none. The forty-engineer team will burn cycles on the wrong features, build them to a higher quality bar than the customer needed, and miss the dimensions of the problem that the commercial developers on a smaller team would have surfaced in week one. The conventional metrics — story points, velocity, sprint completion — do not capture this. They measure the speed of the wrong work, not the rightness of the work being shipped.

The intervention worth running, for any product leader who recognises themselves in this description, is to do an inventory of which engineers on the team are operating as commercial developers — making product calls in their daily work, talking to customers directly, willing to push back on the product manager when the customer signal contradicts the spec. Then ask what the organisation is doing to develop more of them, what it is doing to retain the ones it has, and what structural defaults are getting in the way of both. The answers are usually uncomfortable. They are also the highest-leverage product-organisation work available to most companies, and the work that compounds across years rather than producing a one-time bump.

The commercial developer is not a new role to invent. It is a posture to develop in the engineers you already have, by changing the conditions under which they work. The companies that figure this out earlier in the AI era will pull ahead of the ones that try to compensate for missing customer literacy with more headcount and better PRDs. Better PRDs help. They do not substitute for the engineer who already knows what the customer was trying to do before they read the PRD, because they spent Tuesday morning watching three of them try to do it.

There is also a hiring observation hidden inside this that most engineering leaders dislike but should sit with. The interview process at most companies is designed to filter for technical depth and treats customer literacy as something that will either show up later or is somebody else’s responsibility. The process therefore systematically hires for half of the commercial-developer profile and is then surprised when the other half does not materialise inside the role. The fix in the hiring loop is straightforward and is rarely taken: add a stage that puts the candidate in a customer-shaped problem and watches how they reason about it. Not a coding problem with customer flavour. An actual customer problem, with ambiguity and trade-offs and the kind of judgment calls that the role will actually require. Candidates who do this well are not always the strongest technical interviewers, and the hiring committee has to decide whether the role wants both signals or only the one the existing process is built to measure.

The companies that do this best end up with engineering teams that look, on the org chart, like every other engineering team, and behave, in practice, like a different category of organisation entirely. The product cycle is faster. The wrong work gets caught earlier. The product manager’s job becomes more strategic because the engineers are absorbing more of the tactical product judgment. The economic value of this configuration is not captured by any of the conventional engineering-productivity metrics. It is captured by the customer outcomes, which compound, and by the talent retention, which compounds with them. The commercial developer is the multiplier the AI era is going to reward, because the parts of the job that AI is best at are the parts that the conventional engineer was already best at, and the parts that AI is worst at — judgment under customer-shaped ambiguity — are exactly the parts the commercial developer brings to the table that AI cannot replicate. The product leader who builds for this configuration earlier wins the talent race that nobody has formally announced yet.

 

The Disruption Read: Why Incumbent Engineering Cultures Cannot Simply Decide To Be Commercial

There is a paradox worth sitting with. Most engineering organisations already know that customer proximity produces better software; they will say so in every all-hands. Yet the same organisations keep promoting the engineers who are furthest from the customer and best at the abstractions that peers admire. This is not hypocrisy so much as incentive structure, and it behaves the way disruption theory predicts.

The conventional engineer was optimised for a job the organisation could measure: throughput, system elegance, delivery against a specification someone else wrote. That job was real and valuable, which is exactly why the promotion ladder, the interview loop, and the performance review were built around it. The difficulty is that the measured job is the one AI is closing in on fastest. The pressure now bearing down on the conventional developer role is not a temporary market condition; it is the market re-pricing the precise skills the incumbent culture was built to reward.

An incumbent culture cannot respond by fiat, any more than a disk-drive maker could simply decide to serve the low end of its market. The metrics, the hiring committee, and the reward system all point the other way, and each was rational when it was designed. The commercial developer emerges not where a company declares customer proximity a value, but where it rebuilds the measurement system so that customer-shaped judgment is the thing that earns a promotion. Everything upstream of that is theatre.

 

TL;DR

AI does not need to “kill SaaS” to make SaaS pricing much harder to defend. The relevant shift is simpler: the cost of useful capability keeps falling, while many software vendors still price as if building, switching, and replacing narrow workflows remain prohibitively expensive. That mismatch is why more customers are questioning subscriptions, rebuilding internal tools, and treating software less like leverage and more like rent. Durable premiums still exist, but they now need to be earned through trust, workflow depth, compliance, and risk reduction rather than by wrapping increasingly cheap capability in a monthly invoice.

---

Why falling AI capability costs are forcing a harder conversation about what software is really worth.

 

The important shift is not magic automation. It is that internal alternatives keep becoming more plausible.

 

Disclosure: This page is editorial analysis of AI pricing, software economics, and customer build-versus-buy behavior. Sources appear near the end.

 

The most unhelpful way to discuss AI and SaaS is to ask whether AI will “replace” software companies. That framing is theatrical, and it usually distracts from the real economic change already underway.

The useful question is narrower. What happens when the underlying cost of useful capability falls much faster than the pricing assumptions built into mature SaaS products? That is the real pressure point. Not every customer will build internally. Not every SaaS category will compress equally. But the baseline has changed: more teams now know that narrow internal alternatives are possible, and more CFOs know enough to ask what exactly they are paying for.

This is the core of the AI-deflation versus SaaS-inflation problem. The models, tools, and components that make many tasks possible are cheaper and more accessible than they were even a year ago. Yet plenty of software still prices as if scarcity remains intact. That is why the question underlying our broader developer-culture analysis keeps recurring in boardrooms and churn events: is this software still leverage, or has it quietly become rent?

 

The Cost Floor Is Moving

You do not need perfect price tables for every model to see the direction of travel. The important reality is that useful intelligence for text-heavy, classification-heavy, and workflow-heavy tasks is now cheap enough to reset expectations. Official pricing pages from OpenAI, Google, and Anthropic all point in the same direction: mainstream AI capability is no longer exotic enough to justify old software premiums on its own.

That matters because many software products, especially narrower workflow products, were quietly protected by the old economics of building. A customer paid the subscription not only because the product was better, but because the alternatives felt expensive, slow, and politically difficult. AI has weakened that protection. Internal developers can work faster. Prototype loops are cheaper. Narrow automations that once required a serious engineering commitment now look achievable enough to enter the conversation.

Inference from the sources: the precise model leaderboard will keep changing, but the strategic point is stable. Capability is being deflated faster than many software pricing systems are being rethought.

 

Why This Hurts SaaS Pricing Before It Kills SaaS

A common mistake is to assume the whole category needs to collapse for the economics to matter. It does not. SaaS pricing gets harder the moment customers believe a narrower internal alternative might be “good enough.” That is enough to change procurement behavior, renewal conversations, and willingness to accept bundling, seat expansion, or contract rigidity.

The customer does not need to believe their internal build will beat the SaaS product. They only need to believe that ownership, control, and cost now compare more favorably than they used to. That is why ugly internal tools can defeat more polished products. The contest is rarely “best software in the abstract.” It is more often “good-enough ownership plus control” versus “better product plus recurring rent.”

This is also why the pressure is uneven. Categories that still provide strong trust, compliance, workflow integration, reliability, or auditability can defend premiums much more easily. Categories that mostly package capability without deep workflow dependency look far more exposed. The line between the two is what many vendors still do not want to examine honestly.

 

Software Rent Versus Software Leverage

The most useful distinction in this whole debate is not “AI” versus “human” or “SaaS” versus “in-house.” It is rent versus leverage.

Customers keep paying when software feels like leverage. It reduces complexity they do not want to own. It lowers operating risk. It saves meaningful time. It supports revenue. It embeds itself into a workflow deeply enough that the customer would be irrational to remove it casually.

They begin to resist when the product no longer feels asymmetrically useful. The software may still work. It may still be better than the internal replacement. But once the delta narrows and the recurring bill remains high, the emotional framing shifts. The buyer starts asking the wrong question for the vendor: why are we still renting this?

That is why feature bloat is so dangerous in this environment. Weak vendors often respond to pressure by adding more things. But more things do not necessarily create more leverage. Sometimes they only create more complexity around a value proposition that is already weakening.

 

What Durable Premiums Still Look Like

SaaS can still charge premium prices. But it needs a better reason than “we wrapped AI around a workflow and called it smarter.”

• Trust and compliance: regulated buyers will still pay for auditable systems.
• Deep workflow integration: products that sit inside real operational muscle are harder to replace.
• Reliability at scale: many internal alternatives still fail once stakes rise.
• Risk reduction: software that prevents expensive mistakes can defend rent more cleanly.
• Network or ecosystem effects: some products become more valuable because the market already coordinates around them.

Those are durable reasons. Mere access to generic capability is becoming less durable by the quarter.

 

The Hidden Strategic Shift

The deeper shift is psychological. AI is training customers to ask harder pricing questions. Why this seat count? Why this premium tier? Why this contract length? Why this workflow wrapper costs more than the underlying intelligence layer now appears to justify? Even if the customer still buys, the tone of the relationship changes.

That is why this issue now appears across categories that initially seem unrelated. It helps explain our Microsoft squeeze thesis. It helps explain why a seemingly simple churn anecdote became so revealing in the Reddit churn story. And it helps explain why more teams are starting to look at internal alternatives with less embarrassment and more curiosity.

 

Conclusion

AI deflation versus SaaS inflation is not a slogan about extinction. It is a pricing reality check. The cost floor beneath many useful capabilities is falling quickly, while too many software products still behave as if that floor never moved.

The companies that survive this best will not be the ones with the loudest AI branding. They will be the ones that can clearly prove why their rent still buys leverage the customer cannot cheaply recreate. Everyone else should expect more churn conversations to start sounding like procurement discipline rather than technological rebellion.

 

Sources

• OpenAI API pricing
• Gemini Developer API pricing
• Anthropic pricing
• Ahrefs research on AI content cost compression

The Civilisational Pattern Underneath The AI-Versus-SaaS Pricing Story

Step back far enough from the AI deflation and SaaS inflation conversation and a much older pattern becomes visible. Every technology that compresses the cost of producing a previously-scarce good eventually re-prices the entire industry built on the prior scarcity, and the re-pricing happens in a sequence that has repeated itself across multiple centuries. The printing press did this to scribes. The steam engine did this to canal builders. Electricity did this to gas-lighting engineers. The pattern has a recognisable shape, and the AI-versus-SaaS pricing tension fits inside it more cleanly than the current commentary tends to acknowledge.

The shape, in compressed form, runs like this. A new technology lowers the marginal cost of the output by an order of magnitude. The incumbents whose business depends on the prior cost structure attempt to maintain pricing through bundling, through switching costs, through narrative claims about quality differentiation. The customers initially accept the pricing because the alternatives are unfamiliar and the switching cost is real. Then a generation of new entrants emerges whose entire business is built on the new cost structure, and the incumbents discover that their pricing power was load-bearing in ways their org charts did not understand. The bundles fail. The switching costs erode. The narrative claims about quality differentiation become marketing copy that no longer sells. The re-pricing arrives, sometimes slowly across a decade, sometimes catastrophically across a quarter, and the industry’s shape afterward bears only a partial resemblance to its shape before.

What is unusual about the AI-versus-SaaS case is the speed at which the cost compression has happened. The order-of-magnitude drop that took electricity perhaps fifteen years to deliver to industrial customers has happened in AI in something closer to three. The customers have therefore had less time to develop alternative purchase patterns, and the incumbents have had less time to absorb the implications. Both sides are still operating on mental models that are roughly one cycle behind the technology’s actual cost curve. The current pricing tension is the visible surface of that mental-model lag, and the resolution will happen when one side updates faster than the other and the pricing power follows.

The historical analogue worth holding most closely is the period in the late 19th century when the cost of producing books collapsed by a factor of fifty in roughly two decades. The publishers who survived were not the ones who maintained the old per-book pricing through bundling or quality claims. They were the ones who recognised that the underlying business had stopped being about producing scarce books and had started being about curating attention in a flood of newly-cheap books. The transition cost most of the established names their position. The transition created the conditions for new categories of business — periodicals, syndicated columns, mass-market publishing — that simply had not existed in the prior cost regime.

The same kind of category re-creation is the substantive bet on the AI-pricing question. The SaaS incumbents who survive will not be the ones who held the line on bundle pricing. They will be the ones who recognised that the underlying business was changing shape and re-positioned around something AI does not compress. The AI-native entrants who win will not be the ones who undercut SaaS on per-seat pricing alone. They will be the ones who built something whose value was never about per-seat in the first place. Both transitions will look like the current pricing tension is the story right up until the moment they reveal that the pricing tension was a symptom of a category re-creation that the daily news cycle was too zoomed-in to see.

The civilisational frame does not predict who wins. It predicts that the question of who wins will be settled by something other than the pricing arithmetic that currently dominates the conversation. Anyone allocating capital, building product, or evaluating competitive position in the SaaS-AI market would do well to ask the larger question: which of the seven powers of strategic position is becoming load-bearing in the post-compression environment, and which of the incumbents is positioned to inherit it. The answer to that question, when it arrives, will be the answer to the pricing question as well.

Why the Disruption Timeline Is Compressed This Cycle

The disruption pattern in the AI-SaaS transition follows a logic Christensen identified in hardware markets that later applied to software: the incumbent’s cost structure prevents them from competing at the low end until the low end has consumed enough market share to threaten the core. What makes the current cycle unusual is speed. Historical software disruption cycles played out over five to eight years, giving incumbents runway to reposition. The current compression of AI capability costs is happening at a pace that does not allow that runway. The gap between what enterprise SaaS charges and what AI-native alternatives can deliver is narrowing faster than incumbents can restructure their delivery costs, which means the window for preemptive repositioning is shorter than the organisational change timelines most large SaaS companies operate on. The companies that survive this transition are not the ones with the best existing products — they are the ones that can reduce their cost of delivery faster than their margin compresses. That is a fundamentally different organisational challenge than what most enterprise software companies were designed for, and it explains why the disruption this cycle is likely to be broader and faster than the incumbents’ board presentations currently model.

The Brand Value Question: Which SaaS Companies Survive the Deflationary Moment

Scott Galloway’s consistent framework for evaluating which companies survive category disruption begins with the brand question: does this company have brand value that exists independent of its product’s functional advantages? Brand value — the premium a customer pays above a functionally equivalent alternative, and the forgiveness a brand receives when it fails temporarily — is the asset that survives category compression. The AI deflation in software productivity tools is compressing the functional advantage of every SaaS product that does a task that an AI model can now do more cheaply. The brand question is which of those products have accumulated enough brand equity to price above the AI-enabled floor, and which have been selling functional utility at software margins without building the brand that would justify those margins when the functional utility becomes a commodity.

Galloway’s T-algorithm — his framework for identifying the characteristics of enduring consumer technology companies — identifies scale as the first requirement. The SaaS businesses most vulnerable to AI deflation are the mid-market tools that achieved product-market fit in a world where the cost of automating their core task was high enough to justify human-operated software. These tools have substantial revenue but not the scale economies that would allow them to lower prices fast enough to compete with AI-enabled alternatives. The tools that are defensible in the deflationary moment are the ones at scale — where the switching cost of leaving is high enough that price compression in the generic market doesn’t immediately translate to customer loss.

The SaaS inflation dimension is the counterintuitive element: the same period that is producing AI deflation in commodity software tasks is producing SaaS inflation in the enterprise workflow platforms that are successfully bundling AI capability into existing product surfaces. Microsoft’s 3.3% Copilot penetration at $30 per seat is a case where the inflation story (AI bundled into M365 at a premium) has not yet been validated by the behavioral adoption data that would justify the premium. The price went up; the value-to-price ratio went down for users who are not regularly using the AI features; and the retention risk is exactly what Galloway predicts when brands charge a premium above demonstrated value — customers tolerate it until a credible alternative appears, and then the tolerance collapses faster than the brand built it.

The infrastructure layer sits outside the deflation-inflation dynamic because it is not software — it is physical capital with long lead times, regulated supply chains, and engineering knowledge that cannot be open-sourced. Galloway’s brand question for the infrastructure layer is different: it is not “do you have brand equity that survives commoditisation?” but “do you have the process knowledge and customer relationships that make you the default supplier when demand growth exceeds the ability to evaluate alternatives?” The answer for Vertiv, Eaton, and Schneider is yes — their installed base in existing data centers and their engineering relationships with hyperscaler customers are exactly the kind of switching-cost moat that the deflation-inflation dynamic does not erode.

Galloway’s final observation about brand in the deflationary moment is the one that most technology companies resist: the brand that survives is the one that was built on behalf of the customer, not on behalf of the company’s margin structure. Developer platform brand built through genuine investment in developer capability — free tools, community infrastructure, education — survives the deflationary moment because it has created loyalty that is not purely price-correlated. Developer platform brand built through distribution leverage — making the tool the default because switching is costly — is vulnerable to the deflationary moment because loyalty built on switching costs does not survive a deflationary event that lowers the switching cost. Chinese open-source AI’s deflation effect on Western AI software is precisely this: it is lowering the cost of switching from Western AI platforms to models that are functionally competitive, and the Western platforms whose brand is built on distribution leverage rather than customer investment are the most exposed.

 

The 7 Powers Read: Deflation Is a Test of Which Power You Actually Hold

The deflation-versus-inflation framing describes the pressure well, but it does not tell a specific company whether it survives. For that, the sharper question is diagnostic: when the cost floor of building software collapses, which durable power is doing the work of keeping your price where it is? Most SaaS businesses, answering honestly, discover they were never relying on a power at all. They were relying on the absence of a cheaper alternative, which is not the same thing.

Run the diagnosis against the seven. Scale economies protect the infrastructure layer, which is why the compute and data-centre businesses sit outside this dynamic. Switching costs protect the incumbents whose software is wired into a customer’s workflows, data, and compliance posture, expensive to rip out regardless of what a cheaper tool can now do. Counter-positioning protects the newcomer whose entire cost structure assumes the deflation the incumbent cannot match without cannibalising its own revenue. Brand and network effects protect a narrower set of companies than their holders like to believe. Everything else, the great undifferentiated middle of the SaaS market, was charging software rent secured by nothing more durable than inertia.

That is the real sorting mechanism of the next two years. A firm actively working to defend an established software price against deflationary pressure is, in Helmer’s terms, testing in public whether it holds switching-cost power or merely enjoyed pricing power it never had to earn. The deflation does not destroy value so much as reveal it, separating the companies that built a power from the ones quietly renting one from the market’s inefficiency.