TL;DR: Software accrues value by creating dependencies that compound over time and raise switching costs. As those dependencies form, they compound internally as the product embeds deeper into workflows and externally through network effects and ecosystem adoption. Dependencies inside critical systems get a value multiplier because ripping them out threatens the business itself. Resulting revenue from these embedded software systems then fund new features that create new dependencies, which is a Value Accrual Flywheel. Buzzwords like “system of record”, “gateways”, and “orchestration layer” are really shorthand for particular mixes of these dependencies, and right now AI is reshuffling which ones matter.
Value Accrual Flywheel
New technologies are changing which businesses capture value, but the core mechanisms through which they do it remain the same. Economic principles like switching costs and network effects are still at the heart of the strongest businesses in the world.
Recently we have been trying to describe the impact of these changes with terms like “system of record”, “control plane”, or “execution path”. And while these terms are helpful shorthand for understanding what a product does, they only describe the outcome, not the underlying qualities and mechanisms through which value accrues. And while principles like switching costs and network effects are a helpful starting point, they need to be broken down further to understand exactly what is changing.
In this piece we want to revisit a few basic economic principles, break them down, and fit them into a framework that can help explain the changes that we are seeing in DevOps and software more broadly. At the core of the framework is the idea that:
Software accrues value by creating dependencies that compound over time and increase switching costs.
At the time a product is introduced in a company, the organization begins to depend on it for certain responsibilities. If those dependencies compound over time, switching becomes more costly (especially for critical systems), and the product captures a larger share of the organization's economic resources. These resources allow the product to improve over time, creating additional dependencies and accruing value over a long period of time. This process is called the Value Accrual Flywheel.
Value Accrual Flywheel: Value accrual refers to the product's ability to capture economic value over time by increasing an organization's dependence on it. The flywheel consists of three stages: dependency formation, dependency compounding, and the resulting economic effects.
Dependency Formation (How Reliance Begins)
These five dependency types represent the primary ways organizations rely on software. In practice, most products create multiple dependencies simultaneously, reinforcing their importance from day one.
Take customer relationship management (CRM) software for example. These systems create enormous dependencies. They store historical records of customer relationships and contracts, have varying permissions for who can see what accounts, integrate into billing and product functionality, and are part of the day-to-day operations for sales and account management teams.
These dependencies are the foundation of value accrual. However, by themselves they are often not sufficient for long-term value accrual. To achieve this, companies must find a way to make these dependencies compound.
Dependency Compounding (How Reliance Grows)
Once dependencies are established, they have the ability to grow over time, increasing an organization’s reliance on the product. This process is called dependency compounding and it typically occurs through two primary mechanisms:
Internal Compounding: reliance increases within the organization as the product becomes more embedded in workflows and architecture.
External Compounding: reliance increases as broader ecosystem adoption strengthens the product’s dependencies. The most powerful of these factors is network effects.
Internal and external dependencies create “lock-in” making it difficult to switch away from the product.
Critical Dependency Multiplier (Which Reliance Matters?)
All of these dependencies receive a multiplier to the switching costs that they create based on the type of workflow that they are embedded in. For example, any product that creates a technical dependency for a critical business system is inherently more risky to switch away from. This could be mission critical operations where the product sits in the execution path or gates production or operations like security, audit, or incident response, all of which are required to deliver a product to the customer while remaining safe and compliant. Once products are embedded into critical business operations, replacing any of them threatens the health of business operations. Software that is ancillary to mission critical operations, such as employee perks and HR survey portals for many businesses, receive less of a multiplier. Of course, the mission criticality of software is industry and company specific.
The Output: Economic Implications
Dependencies, their compounding, and the systems they impact create outputs that affect the economics of the business.
Switching Costs: As dependencies form and compound over time, it becomes increasingly difficult for the organization to switch away from the product.
Revenue: As switching costs increase, and organizations keep the product for longer periods of time, more revenue is captured by the product.
Features & Improvements: This recurring (and potentially growing) revenue enables the product to improve existing features and add additional features that can enhance or create new dependencies, which flows back into the beginning of the flywheel.
Value Accrual: The continuous capture of revenue that compounds through this flywheel is what creates value over long periods of time.
Applying the Framework
One of the best examples of this framework in action is a version control system. These systems create deep dependencies across all categories that compound over time.
Dependency Formation: The company chooses to use GitHub as a version control system and on day-one the following dependencies are created:
Data: Captures version changes and commit notes
Governance: Embeds a permission system that determines who can merge
Technical: Integrate into CI/CD pipelines and enables GitOps
Behavioral: Becomes part of the day-to-day of a developer
Economic: For larger companies, implementation costs on day-one can be high
Dependency Compounding: Over time these dependencies start to compound, increasing the companies reliance on the product and making it more difficult to switch away.
Internal:
Data: Version changes and commit notes grow exponentially and are used in audits
Governance: Each new employee receives different permissions
Technical: New systems connect to GitHub, users log into certain accounts with its SSO
Behavioral: Employees solve Git-specific version control over time, increasing efficiency
Economic: Enormous dependencies make switching cumbersome and risky
External:
User Network Effects: Git questions from thousands of engineers on StackOverflow makes troubleshooting easier.
Data Network Effects: Aggregates code and usage patterns across millions of users.
Ecosystem Network Effects: A large ecosystem of tools, integrations, and extensions are built specifically for GitHub increasing its functionality.
Reputation: GitHub has become a trusted industry standard, reducing perceived risk for new adopters and reinforcing its position as the default choice.
Economies of Scale: As GitHub grows, it can spread infrastructure and development costs across a large user base minimizing costs of services.
Economic Implications:
As dependencies form and compound over time, it becomes increasingly difficult for the organization to switch away from the product, driving revenue to the platform. This revenue is funneled back into the product allowing it to expand into things like GitHub Actions and Copilot further increasing dependencies throughout the organization.
Version control systems are so good at this process, that multiple systems (e.g. GitHub, GitLab, and Perforce) have captured billions of dollars in value over time.
Final Thoughts
A lot of recent terminology like, “System of Record” is really just shorthand for products that exhibit one or more of these dependencies. And while these terms are vague, their increase in popularity hints at how dependencies are changing in value in the current landscape. Here are a few high level examples:
System of Record: This refers to a product that acts as a “source of truth” for a specific set of data. These systems have historically created large data dependencies, but also large behavioral dependencies, as users would access this data through a proprietary UI. Recent dialogue has questioned the value of the behavioral dependency by suggesting that a proprietary UI is no longer required and that AI agents will access the data directly.
Gateway: Gateways exist when a product has governance dependencies and operates inside of a critical system. This could be things like decision rights, permissions, or policy enforcement which dictate how the organization is allowed to operate. Gateways sit in the execution path causing them to generally have strong data and technical dependencies, which are exemplified by the critical business multiplier.
Orchestration layer: This term has become popular as startups suggest that AI can seamlessly connect products and workflows — “orchestrating” what used to be a manual process. Depending on its goal and implementation, this product likely has a small data dependency, a moderate technical dependency due to integrations, and a very large behavioral dependency, as users gravitate to this product which now sits at the center of all of their workflows.
Takeaway: Software accrues value by creating dependencies that compound over time and raise switching costs. As those dependencies form, they compound internally as the product embeds deeper into workflows and externally through network effects and ecosystem adoption. Dependencies inside critical systems get a value multiplier because ripping them out threatens the business itself. Resulting revenue from these embedded software systems then fund new features that create new dependencies, which is a Value Accrual Flywheel. Buzzwords like “system of record”, “gateways”, and “orchestration layer” are really shorthand for particular mixes of these dependencies, and right now AI is reshuffling which ones matter.
Have a great weekend,
Josh