In 2025, a US-based B2B SaaS platform serving enterprise customers worldwide set out to give its Mainland China users the complete product — not just the web half of it. Its origin platform ran on AWS in the United States behind a single global domain. The web application itself was reachable from China. What was missing was everything around it: the mobile app was absent from Chinese app stores, and the SMS and voice alerts the product depends on never arrived on Mainland China phone numbers.
The full arc took about six months: roughly a month of pre-contract technical and business validation, cloud infrastructure ready inside two months — the compliant, stateless China notification endpoint went live within five weeks — and around three more months to bring the app to every Chinese app store it needed and tune notification delivery to 92%+.
The web worked. The product didn’t.
China reachability conversations usually start with “is the website blocked?” For this platform, the honest answer was: the website was fine.
The product’s real China gaps sat elsewhere:
- The mobile app was unavailable. Mainland China users could not get it from the China App Store or any Chinese Android store — the mobile half of the product simply did not exist for them.
- Alerts never arrived. The platform’s time-critical notifications — SMS and voice — were sent through a leading global messaging provider whose Mainland China delivery to the three Chinese carriers did not work.
- The result was a degraded product. Enterprise users could open the web app, but outside office hours the service could not reach them, and the mobile experience was missing entirely.
For a B2B product whose value depends on timely alerts, “mostly works” is not a sellable state in any market.
Probe first, decide second
Before proposing an architecture, Chinaready measured the actual cross-border path. From an EC2 Linux host inside an AWS China region, using standard network tooling, we tested the client’s US origin endpoints for reachability, availability, performance, and latency.
The findings reframed the project:
- The origin endpoints on the US west coast were reachable from Mainland China with acceptable latency — the product is not real-time critical, so the public internet was a viable backhaul network.
- The B2B domain faced no unusual cross-border interference: DNS, TCP, and HTTP behaved.
- The broken pieces were distribution and notifications, not the web tier.
This is why the assessment exists: it moved the project from “make China work” to two specific, buildable problems.
All of this technical validation — the origin probes, cross-border calls against the shortlisted Mainland China notification APIs, and live test numbers across the three Chinese carriers — was completed in about ten days, before the contract was signed. The business case was proven before either side committed.
Three options on the table
| Option | What it buys | What it costs |
|---|---|---|
| Full Mainland China hosting | Strongest data residency; fastest in-country performance | Largest cloud footprint; longest timeline; heaviest migration |
| Stateless China notification proxy | Compliant alerts + app distribution; months faster | Web tier keeps riding the public internet |
| Do nothing | Zero spend | The product stays incomplete in China |
Full Mainland China hosting was the first option considered — for a B2B platform, in-country data residency is the conservative instinct. But the probe results showed the web tier did not need it, and the client had a hard deadline: the mobile app had to be live within about half a year.
The chosen route: a lightweight, stateless proxy endpoint inside Mainland China, fronting mobile app traffic and connecting to a compliant Mainland China SMS/voice provider that the US origin calls for notifications. The compliance posture is architectural, not procedural — the China footprint stores and processes no user personal data; accounts and personal information remain on the client’s global platform.
What we built
The division of labor was explicit.
The client’s engineering team built and deployed the proxy component on an AWS China region — deliberately small, running on ECS so version iterations and day-to-day operations stay light. Their origin platform added first-class support for the Mainland China notification service alongside the global one.
Chinaready carried the pre-contract validation and the China-side execution:
- The evidence the decision rests on — reachability, availability, and latency probes from our own AWS China host against the US origin, run before the architecture was proposed.
- Vendor selection — we shortlisted the two dominant Mainland China messaging vendors (Alibaba Cloud and Tencent Cloud), recommended one, and handed over API access already validated from the client’s origin.
- Launch verification — test numbers across all three Chinese carriers, a demo program, and staff on the verification calls.
Nothing in the validation surprised us — which is the point of validating before signing, not after.
Getting the app into Chinese stores
In parallel, Chinaready cleared the app-distribution path: curating the five leading Chinese Android app stores for the first wave alongside the China App Store, obtaining the software copyright certificate, and completing app filing. Store-by-store verification and launch took about three months in total.
None of this paperwork is technically hard. It is, however, unforgiving of sequence — copyright before store review, filing before launch — and it is exactly the part overseas teams usually underestimate.
Results and aftercare
With the app live across the China App Store and the five Android stores, the compliant notification service reached Mainland China users at the same time. Delivery was not perfect out of the gate: in the first weeks, monthly SMS success sat around 70%. The cause was not the network — Mainland China notification providers enforce rate limiting, deduplication, and anti-spam rules on their API traffic, and the platform’s default alert cadence tripped them.
Chinaready helped the client rework alert frequency and content so legitimate traffic stays clear of those limits. Monthly delivery rose to 92%+ and held.
For Mainland China users, the outcome is the complete product: the web app they already had, an app that installs from the stores they actually use, and alerts that reach them wherever they are.
What this case shows
Opening the China cloud account, the ICP filing, app filing, the software copyright certificate, store submissions — these are routine paperwork, and any competent partner can run them.
What actually protects a China launch is the work on either side: before signing, identifying the real compliance gates and validating the key technical claims — here, that the web tier was already fine and only notifications and distribution were broken; after launch, tuning the Mainland China third-party services that every China architecture ends up depending on. A 22-point delivery-rate improvement came from aftercare, not architecture.
That is the shape of the work we recommend starting with: test what actually breaks, then fix only what the evidence shows is broken. If you want that read on your own stack, start with a China Readiness Assessment, or see how we handle app distribution and SMS, push, and email replacements in practice.
