The Hidden Coordination Layer: Why Network Costs Shape Platform Evolution

A strategy note for platform product teams

I was reading an ACG Research’s report on how application-driven traffic is reshaping the economics of mobile and fixed networks. A small set of applications drives almost all delivery cost: seven apps account for roughly 96% of mobile network costs. While nine account for about 92% on fixed. Most of that bill doesn’t sit with the app makers. Instead, it lands in the radio access network (RAN) on mobile and the access layer on fixed, precisely where capacity scaling is most expensive. And although mobile transport averages around $0.33/GB versus $0.06/GB on fixed, households push so much traffic that fixed ends up at about $21.22 per subscriber per month versus $5.40 on mobile (approx. 393% higher).

That’s the hidden architecture of the digital economy. It’s the classic winner-takes-most dynamic of platforms: a small number of players create most of the value and costs in the ecosystem. In other words, it shows how super-platforms dominate not just user attention but also the economics of the underlying infrastructure.

The report is explicit about how operators will (or need to) respond. Basically, leaning into subscriber-aware policy, application classification (including encrypted traffic analysis), QoE scoring, and intent-based optimization to protect experience and defer CapEx. Where per-app controls are restricted or unreliable, they’ll probably need to default to shaping by application category/class. From the economic perspective, the report recommends pushing for interconnection, regional caching agreements and pursuing compensation/fair-share cases. All this supported by per-app TCO models that show costs landing in the RAN (approx 85% mobile TCO) and access ( approx 75% of fixed TCO), with the burden concentrated in a few apps.

So, what’s in it for platforms?

If you build platform products, then ACG’s findings matter. They actually define the surface platform products run on. And the actions CSPs take to alleviate network stress (as recommended in the report) constitute the durable baseline platforms should assume. They the real map of constraints to design to. Simply put, if costs concentrate in layers you don’t control, product–market fit isn’t enough. Treat the network as a complement. Design to its constraints and contract for the outcomes you need.

Design to the binding constraint. Make P95 latency, jitter, and cost-to-serve first-class product requirements. Set sensible defaults (bitrate ladders, interaction windows, session cadence, on-device vs edge) so the experience degrades gracefully at peak. Let the client (access class and live load) adapt in real time.

Buy outcomes, not best-effort. When operators offer them, contract for experience metrics: latency/jitter objectives, QoE or MOS targets, and prioritization by class at busy hours. Tie SLAs to what users feel, not raw throughput. Price features against the cost of a stabilized session or interaction.

Co-locate value. Push encoders or inference to hot PoPs when necessary. Use a simple rule: if tail latency or retries are driving churn, move compute closer. If not, stay in the core. Prove it with A/Bs on edge-hit ratio, tail-latency percentiles, and session success.

Govern the interface. Publish performance intent so networks can optimize without content inspection. Make class-level metadata (e.g., conversational AI, interactive gaming) the default, with optional per-app markers where lawful and reliable for premium tiers. This approach survives encryption and neutrality shifts.

Sequence features to cost curves. Don’t ship the same defaults everywhere. Launch heavier formats only where your latency and cost budgets clear. Do a soft-launch elsewhere with constrained settings. Make this a formal gate in the release process.

Build the ecosystem contract. Treat interconnection, regional caching, and outcome SLAs as part of your unit economics, not post-hoc ops. Offer predictable traffic growth and verified cost relief to operators. In return, buy the delivery guarantees your UX requires.

Instrument what matters. Don’t just ship. Instead, watch the dials that tie cost to experience: your cost-to-experience curve (cost per successful session vs tail latency/jitter), SLA attach rate and the retention lift it brings, before/after edge ROI, and the share of traffic running under performance intent. When those lines trend up, you’re not fighting the network, you’re growing with it.

Organize for it. Give clear ownership of network economics inside product. Have PM/data lead who sets budgets (latency, jitter, cost per interaction), runs market-by-market gates, and negotiates outcome contracts with operators.

Two Short Examples: Building With the Network

To make it concrete, here are two short examples (cloud gaming and AI assistants) to show how to anchor them to the real world.

Cloud gaming. Evening peaks in dense cells are where the RAN bites. Design for that constraint. Bound bitrate by access class and live load. Prefer shorter sessions where contention is predictable. Place encoders at hot PoPs. Buy gaming-grade outcomes (latency/jitter objectives with class-based prioritization). Not best-effort.

AI assistants. Lab-instant isn’t street-instant. Push inference to the nearest PoP. Price per low-latency interaction. Publish class-level performance intent (conversational AI) so networks can stabilize QoE without content inspection. Use per app markers only where lawful and reliable. Keep them for premium tiers.

Ecosystem and economics (this is platform strategy)

This isn’t just network plumbing. This is how you price and govern a two-sided ecosystem. Today, OTTs capture demand-side revenue while CSPs carry supply-side cost, an externality that shows up in the RAN/access bill.

Think of outcome SLAs as converting QoE risk into a contract. Edge credits and interconnect + caching let both sides share the gains when you shorten paths, cut retries, and push CapEx to the right. And because these agreements sit on the same primitives operators already run (classification, QoE, intent) you’re wiring economics to operations. Net result: you re-price the externality into the product your users actually buy.

Metrics a platform team should track

• Cost-to-experience curve: cost per successful session/interaction vs P95 latency/jitter (pre/post edge, outcome SLA, etc).
• Edge efficacy: edge hit ratio, retry rate in hot PoPs, tail-latency percentiles
• Contract impact: SLA attach rate and retention uplift vs best-effort cohorts
• Interconnect/caching ROI: operator-verified cost relief vs your OpEx.

Limitations

ACG Research notes that these figures are global averages, not your mix. Models typically exclude outside plant, fiber install, and spectrum. Outcomes vary with household usage patterns, peak-hour load and the share of encrypted traffic. Therefore, you need to treat the numbers as directional constraints. Although the above recommendations broadly apply, you should still calibrate locally, validate against your own telemetry and economics before locking your roadmap or commercial terms.

Closing the loop

Platforms scale on top of someone else’s cost curve. For digital products, that curve lives in RAN and access. A few apps drive most of the bill. That makes network economics part of product design, not a post-launch fire drill.

Start by treating the constraint as a requirement. Put it on the roadmap. Ship with guardrails that hold at peak. Then treat the network as a product interface you can shape: contract for outcomes, place compute where it pays, and publish performance intent so operators can help without inspecting content.

Think in ecosystem terms. Use interconnect and caching to shorten paths. Share verified savings when retries fall and tail latency improves. Price that value into your offer. Do this and you reduce the odds of blunt throttling later. With this you are also making your economics legible to the people running the pipes.

Own the governance. Give one leader clear remit for network economics. Measure what matters, market by market, and adjust when the metrics move. The feedback loop is the strategy.

Contract for the experience you promise, instrument the tail, and ship accordingly, usage will climb. Do none of that, and 7–10pm will write your roadmap, no matter how good the feature looks in the lab.