Six months ago, I sat in a coffee shop in Manila staring at a pile of physical SIM cards I'd collected from a dozen countries. Each one represented a different carrier, a different activation process, and a different headache. That moment crystallized something I'd been thinking about for years: the entire model of physical SIM cards is broken, and eSIM technology is the fix the world has been waiting for.
This is the story of how we built iWanteSIM — a global eSIM platform that now serves travelers in over 200 countries. I'm writing this in the open because I believe the technical decisions behind platforms like ours deserve the same scrutiny as any open-source project. If you're building in the connectivity space, thinking about carrier integrations, or just curious about what happens when you try to replace a 30-year-old technology, this one's for you.
The Problem With Physical SIM Cards (And Why It's Finally Over)
Let's be honest about what a physical SIM card actually is: a piece of plastic with a tiny chip that locks you into one carrier's network. It's a distribution nightmare — manufacturing, shipping, retail placement, and activation all add friction. For travelers, it means either paying extortionate roaming fees or hunting down a local SIM shop the moment you land.
The numbers are staggering. The GSMA estimates that over 5 billion SIM cards are manufactured annually. That's 5 billion pieces of plastic that need to be produced, packaged, shipped, and eventually discarded. The environmental cost alone should make us rethink this model, but the user experience cost is even worse.
eSIM technology changes everything. An embedded SIM is exactly what it sounds like — a SIM card that's soldered directly onto your device's motherboard, programmable over the air. No plastic. No shipping. No store visits. You land in Tokyo, open an app, tap a few buttons, and you're connected. That's the promise, and it's what we set out to deliver at scale.
The shift from physical SIM cards to eSIM is the biggest change in mobile connectivity since the smartphone itself.
The Architecture: What Powers a Global eSIM Platform
When we started designing the iWanteSIM backend, we knew we were signing up for a distributed systems challenge. You're not just building a web app — you're building a platform that has to talk to dozens of mobile network operators (MNOs) across different continents, each with their own APIs, authentication schemes, and data formats.
Here's the stack we landed on, and more importantly, why:
The Core: Node.js + PostgreSQL
We chose Node.js for the API layer because eSIM provisioning is fundamentally I/O-bound. When a user purchases a plan, your system needs to talk to the carrier's SM-DP+ (Subscription Manager Data Preparation) server, generate an eSIM profile, and deliver it — all within seconds. Node's event-driven architecture handles these concurrent operations beautifully without the thread-pool overhead you'd get with something like Java Spring.
PostgreSQL is our source of truth. We track every eSIM profile, every activation, every data session. The relational model maps cleanly to our domain: users have orders, orders have eSIM profiles, profiles have data plans, data plans have usage records. We use JSONB columns sparingly for carrier-specific metadata that doesn't fit a rigid schema — because every carrier has their own quirks, and you can't normalize your way out of that.
The Integration Layer: A Carrier Abstraction Pattern
This is where things get interesting. Each carrier partner exposes a different API. Some use GSMA-standard RSP (Remote SIM Provisioning) protocols. Others have REST APIs with OAuth2. A few still use SOAP (yes, in 2026, SOAP is alive and well in telecom).
We built a carrier abstraction layer that normalizes all of this into a single internal interface:
-
Profile Manager — handles eSIM profile generation, download, and revocation
- Activation Service — manages the handshake between device and carrier when a user activates a plan
- Usage Tracker — polls carrier APIs for data consumption and enforces plan limits
- Fallback Router — if one carrier's API is down, routes provisioning to a backup partner
Each carrier gets its own adapter that implements these interfaces. When we onboard a new carrier — say, a provider in Brazil — we write one adapter, test it against their sandbox, and deploy. The rest of the platform doesn't need to know anything changed.
Building the carrier abstraction layer — one adapter at a time. The key insight: standardize internally, adapt externally.
API Design: Why REST Won (And GraphQL Didn't)
We had the GraphQL vs REST debate early on. GraphQL is elegant for client-side flexibility, but eSIM provisioning isn't a read-heavy social feed — it's a transactional pipeline with well-defined operations. A user buys a plan, we provision a profile, they activate it. These are discrete steps, not graph traversals.
Our public API follows RESTful conventions with a few opinionated choices:
-
Idempotency keys on all mutating endpoints. When you're dealing with carrier billing, duplicate charges are unacceptable. Every POST/PUT requires an Idempotency-Key header, and we deduplicate at the application layer before touching any downstream system.
- Webhook-first design. eSIM activation isn't instant — it can take 30 seconds to 2 minutes depending on the carrier. Instead of making clients poll, we push events via signed webhooks. Activation started, profile downloaded, plan active — each state change fires a webhook.
- Rate limiting with carrier-aware backpressure. Carriers have rate limits too. If a partner tells us "max 50 activations per minute," our API gateway respects that upstream constraint and queues excess requests rather than failing them.
The API is documented with OpenAPI 3.1, and we generate client SDKs for our mobile apps directly from the spec. This keeps the contract honest — if the spec says a field is required, the generated types enforce it at compile time.
Carrier Integrations: The Hardest Part Nobody Talks About
If you're thinking about building in the telecom space, here's the part that will humble you: carrier integrations are not a technical problem. They're a relationship problem.
Getting an MNO to give you API access for eSIM provisioning involves legal agreements, compliance audits, and months of back-and-forth. Each carrier has different requirements for KYC (Know Your Customer), different data retention policies, and different interpretations of GSMA specifications.
We learned this the hard way with our first carrier partner in Southeast Asia. We had the integration working in their sandbox within two weeks. Getting production access took four months — not because of technical blockers, but because their legal team wanted to review every line of our privacy policy, our data flow diagrams, and our incident response plan.
Now we front-load the legal and compliance work. Before we write a single line of integration code, we have our legal team review the carrier's requirements, we prepare a compliance package, and we set expectations internally that "carrier onboarding" means 8-12 weeks, not 2.
On the technical side, the GSMA's RSP specification (SGP.22 for consumer devices) is the standard we target. It defines how eSIM profiles are created, downloaded, and managed. But here's the reality: every carrier implements it slightly differently. Some add custom fields to the profile metadata. Some require additional authentication steps. Some have different interpretations of error codes. Our adapter pattern handles this, but it means we maintain a growing library of carrier-specific quirks documented in our internal wiki.
Coverage: How We Built a 200+ Country Network
One of the most common questions we get is: "How do you offer coverage in 200+ countries?" The answer is a combination of direct carrier partnerships and wholesale agreements.
We have direct integrations with major MNOs in about 40 countries — these are the carriers where we've built custom adapters and have direct API access. For the remaining 160+ countries, we work through aggregators and wholesale partners who already have relationships with local carriers and provide us with a unified API.
The trade-off is control vs. speed. Direct integrations give us better pricing, faster provisioning, and more visibility into network status. Wholesale agreements let us expand coverage rapidly without negotiating 160 separate contracts. We're gradually converting wholesale countries to direct partnerships as our volume in each region grows.
200+ countries, one platform. The real work is making it feel seamless to the user.
The Pricing Model: Why eSIM Plans Start at $1.00
Traditional roaming charges are predatory. Carriers charge $10-15 per day for international data that costs them pennies to provide. The reason they get away with it is lock-in — most people don't want the hassle of swapping SIM cards.
eSIM breaks that lock-in. When you can switch carriers in 30 seconds from an app, carriers have to compete on price and quality. Our plans start at $1.00 because the marginal cost of provisioning an eSIM profile is near zero — there's no plastic to manufacture, no retail markup, no shipping. The only real costs are the wholesale data rates we negotiate with carriers and our infrastructure.
We pass those savings through. A 1GB plan for Europe costs $3.50. A 5GB plan for Asia costs $12.00. Compare that to $10/day roaming from your home carrier, and the math speaks for itself.
For a deeper look at how eSIM pricing works across different regions, check out our eSIM plans page where we break down every available option.
What I'd Do Differently
Building in public means being honest about the mistakes. Here are three things I'd change if I were starting over:
1. Start with the compliance layer, not the code. We built a beautiful provisioning system before we had carrier agreements in place. We should have secured at least two carrier partnerships first, then built the system around their actual APIs rather than the GSMA ideal.
2. Invest in observability from day one. When an eSIM activation fails, you need to know exactly where — was it the carrier API? The profile generation? The user's device? We initially had basic logging and spent too many hours grep-ing through log files. Now we use OpenTelemetry with distributed tracing across every service, and it's saved us countless hours of debugging.
3. Don't underestimate the device compatibility matrix. Not all phones support eSIM the same way. iPhones (XR and newer) are consistent. Android is a fragmented landscape — Samsung, Google Pixel, and newer Xiaomi devices support eSIM, but the implementation details vary. We maintain a comprehensive device compatibility list that we update constantly as new models launch.
The Road Ahead
We're not done. The eSIM market is projected to grow from $9.8 billion in 2024 to over $25 billion by 2030. Every new smartphone sold today is eSIM-capable. Apple removed the physical SIM tray entirely from US iPhones starting with the iPhone 14. The writing is on the wall.
Our roadmap includes deeper carrier integrations in Africa and South America, a B2B API for travel companies that want to bundle eSIM with flight bookings, and a machine learning model that predicts which plan a user needs based on their travel itinerary — no more guessing whether 1GB or 5GB is enough for a week in Paris.
If you're a developer interested in the connectivity space, the door is wide open. The incumbents are slow, the technology is standardizing, and travelers are desperate for better options. The stack I've described here — Node.js, PostgreSQL, carrier abstraction patterns, RESTful APIs — is battle-tested and ready for anyone to adopt.
Physical SIM cards had a good 30-year run. But their time is up. The future of mobile connectivity is embedded, programmable, and global. We're building it. Come join us.
This article is part of our building-in-public series. Follow along as we share the technical decisions, carrier negotiations, and architecture challenges behind iWanteSIM. Have questions about the stack? Drop them in the comments — I'll answer everything I can.
Top comments (0)