Chapter 7 — The Architecture of Monopoly
Power rarely announces itself as power. It often presents itself as convenience.
A platform may offer a search box, an app store, a payment route, an advertising channel, a recommendation system, or an identity layer. Each service can be useful. The systems become more difficult to evaluate when they stop being separate services and begin to reinforce one another. A person may be able to choose between products in theory while the architecture of discovery, distribution, and default settings makes one choice dramatically easier than every other.
This chapter does not argue that size itself is a moral failure. Large systems can create access, reliability, and useful standards. It asks a narrower question: when does convenience become a structure that limits meaningful choice?
Defaults shape behaviour
People do not make every decision from first principles. They follow defaults because attention is limited. A default browser, default search engine, default payment method, default recommendation, or preinstalled application can become the path of least resistance.
The ethical question is not whether defaults exist. A usable system needs them. The question is whether a default is transparent, reversible, and chosen in the user’s interest—or whether it quietly turns temporary convenience into permanent dependency.
| Design choice | Helpful version | Extractive version |
|---|---|---|
| Default setting | Easy to understand and easy to change | Hidden, sticky, or deliberately confusing to reverse |
| Data collection | Proportionate to a clear service need | Collected broadly to strengthen unrelated control |
| Integration | Interoperable and user-directed | Designed to make departure costly |
| Recommendation | Explains relevance and permits choice | Obscures alternatives or rewards only platform advantage |
These distinctions are not abstract. They shape what smaller builders can reach, what users can discover, and what public conversation can become.
The difference between scale and enclosure
Scale means a system serves many people. Enclosure means a system makes it difficult for people to act outside it.
An organisation may grow large because it solves a genuine problem well. It begins to resemble an enclosure when the same system controls the roads to the market, the rules of visibility, the information used to rank participants, and the terms under which participants can leave.
The result is not always visible to an individual user. Someone may simply notice that a small creator cannot be found, that a local business must pay to reach people who already chose to follow it, or that a rival service is technically available but practically absent from the user’s path.
Systems architecture matters because these small frictions accumulate. They determine who gets to be visible, who can compete, and whose choices remain real.
The builder’s responsibility
A builder does not need control over an entire market to learn from this problem. Even a small product creates its own defaults. It decides whether users can export their work, whether consent is understandable, whether a recommendation can be questioned, and whether an exit is treated as a betrayal or a right.
The most responsible systems design for departure as carefully as it designs for arrival. It assumes that a user may leave, compare, disagree, or seek a different tool. It treats this not as a failure of retention but as a condition of dignity.
For independent builders, this can be an advantage. They may not be able to compete on scale, but they can compete on clarity, portability, accountability, and respect.
A market needs more than choice on paper
Real choice requires more than several names on a screen. It requires discoverability, interoperable paths, comprehensible terms, and the ability to move without losing one’s entire history.
This is why discussions of market power should not be left only to economists, lawyers, or engineers. They belong to educators, creators, workers, and users because each group experiences a different part of the architecture.
An ethical technology culture asks not only, “Can we build this?” but also, “What kind of dependency does this design create?”
Reader test
Take one digital service you use every day. Ask: if I wanted to leave, what would I lose besides convenience? Data, contacts, reputation, files, income, or the ability to be found? The answer describes the system’s real power over you.
Closing reflection
Monopoly is not only a market category. It is a design pattern that appears whenever a system turns usefulness into unavoidable dependence.
The response is not to reject successful systems. It is to demand that success remain compatible with exit, competition, accountability, and the right of a person or smaller organisation to remain visible without surrendering everything to a single gatekeeper.
Source note
This chapter adapts the author’s systemic analysis The Architecture of Monopoly. It offers a conceptual framework for evaluating digital power and does not restate legal findings or monetary figures without their primary sources.
References
[1] G. K. M. Jarif Ur Rahim, “The Architecture of Monopoly.”
← Back to the book