In 2025, a US-based workflow-automation platform set out to give Mainland China users the product’s core experience — the mobile app. On a workflow product, the app is not a companion: statuses, approvals, and alerts are the point. But for Mainland China users, the app could not be installed at all, and even users who side-loaded it received none of the SMS and voice notifications the workflows depend on.
From kickoff to first version live took under a year, with SMS and voice notifications working on day one. The route: a deliberately minimal set of components inside China, and one Chinese vendor replacing an entire global mobile stack.
Install was the first blocker
The platform ran globally on two large public clouds, with a heavily Google-shaped mobile stack: a global CDN with no Mainland China PoPs at all, a global mobile push service that does not reliably reach Mainland China Android devices, and Twilio for SMS and voice worldwide. In-app analytics, crash-reporting, and feature-flag SDKs all fought cross-border latency and data loss.
For Mainland China users the result was binary:
- The app could not be installed. It shipped via the US App Store and Google Play; Mainland China users live in the China App Store and Chinese Android stores, where the app was absent.
- Notifications never arrived. Twilio’s PRC messaging restrictions — documented publicly in the vendor’s own notice — mean Mainland China numbers are not reachable through its service.
- The web app worked, slowly. Usable as a fallback, but nowhere near the experience the product sells.
Evidence killed the cheap option
Two candidate architectures were on the table:
| Option | What it buys | What it risks |
|---|---|---|
| Pure cross-border CDN acceleration | No components in China; smallest footprint | Latency to the core database; push and notifications still broken |
| Minimal in-country component set | Caching and a static-asset CDN inside China; a real mobile experience | More to operate; backhaul path must be chosen well |
Chinaready ran network performance tests against the product’s public API endpoints, and the product team read the data the same way we did: for timely workflow updates on mobile, cross-border acceleration alone would not close the gap. App-to-core-database latency has to be solved with components inside the country.
So the decision became: the smallest workable component set at a China site — backend components, a proxy, and the static-asset CDN the mobile app needs — with the public internet as the first backhaul path, and a planned optimization pass (including evaluating dedicated connectivity) once real user experience data came in.
Two parallel tracks
After signing, the work split into a cloud track and a release track, run in parallel.
Cloud infrastructure. Working to the product team’s own workflow, we stood up dev, staging, and production environments on both AWS China and a Chinese cloud platform — two platforms, three isolated environments each, with web console access and API keys handed to the team. This was the largest product team we have supported, and the environment provisioning was exactly as tedious as it sounds. It was also the foundation everything else ran on.
Mobile dependencies. Before signing, Chinaready had recommended testing the third-party mobile services early, and recommended the replacement: a leading Chinese internet vendor’s one-stop mobile suite covering push notifications, crash reporting, app monitoring, and product analytics — plus SMS and voice. A demo app we supplied let the product team finish the SDK integrations in two to three weeks, configuring and debugging everything from one web console instead of learning five separate Chinese products.
Compliance before submission. We took an early China-runnable build of the app, ran it through mobile-app analysis tooling, and returned a list of compliance remediation requirements while there was still time to act on them. That is why the first app-store submission passed on the first attempt — the weeks before launch were not consumed by surprise remediation demands from unfamiliar stores.
Throughout, the teams ran continuous delivery with frequent testing, coordinating across time zones through online meetings and Slack.
Results
- First version live in under a year, running under Chinaready’s ICP license and store-operations arrangement: ICP filing, PSB filing, software copyright registration, and app filing all handled end to end.
- SMS and voice notifications worked from day one of v1; subsequent versions added mobile push, app monitoring, and product analytics.
- Releases have stayed on schedule since, with stable version iteration on top of the environments and pipelines set up at the start.
What this case shows
Two lessons generalize. First, the cheapest architecture is the one the evidence supports: probe data killed the pure-CDN option before it could waste months, and the minimal-footprint design that replaced it shipped faster than a full deployment would have. Second, swap complexity, don’t add it: replacing a five-vendor global mobile stack with one Chinese vendor’s integrated suite — one console, one integration effort — removed most of the cognitive load of adapting to the Chinese ecosystem.
And the unglamorous part matters: three isolated environments on two clouds, provisioned correctly on day one, is what “stable iteration since” is built on. If your product lives on a global mobile stack that stops at the border, start with which parts of your stack break first, then plan the route — a China Readiness Assessment gives you the map, and Mobile App Distribution is the track this case ran on.
