AI companies are not making money; they should learn from the Hong Kong Metro.
TechFlow Selected TechFlow Selected
AI companies are not making money; they should learn from the Hong Kong Metro.
AI Labs Can Never Make Money? MTR Gave the Answer 45 Years Ago.
Navigating Web3 tides with focused insightsAuthor: Michael Wenye Li
Compiled by: TechFlow
TechFlow Editor's Note: AI labs have burned hundreds of billions of dollars, but no one can say clearly when the money will be made back. API pricing drops 10x every year, open source chases closed source, and training costs keep piling up. This article steps out of the tech industry perspective and uses the 45-year business model of Hong Kong Metro MTR to give a highly inspiring answer: Don't think about making money from tickets, go own the property above the stations.
They Can't Make Money, and the Question Itself Is Wrong
There is a business like this: upfront investment of billions in capital, zero revenue. Core service pricing approaches marginal cost. It creates huge value for users, but the builders can hardly keep a dime. And it requires constant investment in next-generation infrastructure.
This is not talking about AI labs, but large-scale railway systems.
Many people use railways to analogize the AI industry, and most conclude: General-purpose technologies have public good attributes, and commercial viability cannot do without government subsidies.
I want to challenge this conclusion. Because Hong Kong's MTR actually solved this problem. It is one of the very few metro systems globally that is commercially self-sustaining, a listed company, pays dividends, and does not take government operating subsidies.
The Financial Structure Is Exactly the Same
MTR's core railway business has never been able to fund its own expansion. 2018 was the best year before the pandemic, with transport business EBIT at HK$2 billion. Meanwhile, capital expenditure estimated for 2024-2026 is HK$87.9 billion, almost entirely for railways. Three years of peak railway profits are only enough to cover 8% of capital expenditure. Fare revenue is never enough to build the next line, which was never its design intention.
MTR fares are kept at affordable levels through the government fare adjustment mechanism. You cannot set fares high enough to recover construction costs; no one could afford to ride, and it would violate the purpose of public transport. Each line might cover its own operating costs, but fare revenue will never support the construction of the next line.
AI API pricing faces a mirror version of the same problem. Distillation and open-source alternatives cause API prices to drop at a rate of about 10x per year; any lab pricing above marginal cost will lose volume to competitors. Each model can achieve operational profitability at the inference level, but profit margins will never support the expenditure of the next round of training.
The global common solution is subsidies. London Underground relies on TfL funding, China High-Speed Rail carries trillions in debt, and 94% of lines are unprofitable. AI is walking the same path: CHIPS Act, Stargate project, sovereign wealth fund investments, Pentagon contracts. The default endgame is quasi-public infrastructure reliant on subsidies.
MTR found another way.
Rail + Property
At the beginning of MTR's construction in 1979, designers understood that fares would never recover construction costs. So they structured the company around a completely different premise: railways will appreciate surrounding land, so hold onto the land.
MTR develops residential buildings, office towers, and shopping malls above and around stations, pocketing the value appreciation created by its infrastructure. Property profits feed back into railway operations and fund the next line. Today MTR owns 13 shopping malls and manages 47 station-top property projects; property contributes the bulk of actual profits.
The logic is clear: Don't think about capturing value from the railway service itself, go own those assets that appreciate because of the railway.
The Correspondence for AI
"When will AI labs make money?" and "When will railways support themselves through fares?" are isomorphic questions. The answer is the same: They can't, and the question itself is wrong.
A biotech startup uses frontier models to screen drug compounds, saving two years of clinical trial time. A logistics company uses it to optimize routes, saving $40 million in fuel costs. An independent developer delivers in one weekend a project that previously took a five-person team three months. In each case, the model provider only captures a fraction of a percent of the value through API fees. The provider cannot raise prices because there are four other labs and a dozen open-source alternatives providing similar capabilities. The surplus value flows to users and the broader economy.
General-purpose technologies are like this. Steam engines, electricity, TCP/IP never contributed much revenue to their creators.
MTR's revelation: Stop trying to make fares cover construction costs, go find your "property".
Four Candidate Solutions, Ranked by Defensibility
Government-granted deployment rights rank first. The government authorizes a lab to exclusively access national medical records, tax systems, or defense logistics. The domain data, system integration depth, and regulatory qualifications accumulated by the lab take years to replicate. This is MTR's own mechanism: the state grants development rights based on natural monopoly attributes.
Accumulated reinforcement learning reward data ranks second. Billions of interaction signals are used to train the next generation of models. Unlike model weights (which depreciate due to distillation), RL data is almost impossible to replicate and accumulates compound interest across generations. It cannot be monetized directly, but it is a piece of land, appreciating, yet undeveloped.
Front-loaded deployment integration ranks third. Instead of selling model interfaces to a consulting firm and letting it earn the productivity surplus, own the entire service delivery layer end-to-end. Just like Palantir embeds engineers in government agencies instead of selling software licenses. The lab does not charge law firms API fees; the lab becomes the legal research service itself, pricing based on delivered outcomes rather than consumed tokens. Switching costs will continuously accumulate with the accumulation of domain data and institutional knowledge. This is MTR's shopping mall: monetizing the passenger flow created by the railway, rather than raising fares for passengers.
Data custodianship of national datasets ranks fourth. Governments of various countries hold large amounts of underutilized datasets (patient records, tax filings). A frontier lab designated as the custodian gains exclusive access to train models and build products based on this data. But this will create a public-private data monopoly, requiring strict governance architecture: clear usage boundaries, benefits flowing back to the public, independent supervision, and truly binding accountability mechanisms.
Redefining the Problem
The labs that will survive are not those that make APIs profitable, but those that find their own "station-top property" now and start building. APIs are the railway; they will never be profitable enough. The money is in those appreciating assets around the railway.
Policy-level questions follow: Rather than subsidizing training runs, governments should design institutional mechanisms (deployment rights frameworks, data custodianship structures, productivity metrics) that allow labs to capture the surplus value created by their infrastructure.
Finally, there is an irony. AI policy discussions are dominated by the US-China framework: US free-market labs versus Chinese state-backed champion enterprises. The most reference-worthy institutional model might be neither. It could be the Hong Kong model: a 45-year-old public-private hybrid, commercially operated, achieving self-financing through institutional design rather than ideology.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
