Building a Global eSIM Platform: Why I Chose This Stack Over Traditional SIM Cards

Eighteen months ago, I sat in a coffee shop in Bangkok with a dead phone and a stack of physical SIM cards from six different countries. I'd just paid $40 for a "global" roaming plan that barely worked. That moment — frustrated, overcharged, and disconnected — is where iWanteSIM was born.

This isn't a polished startup story. It's the messy, real account of building a global eSIM platform from zero — the architecture decisions that kept me up at night, the carrier integrations that nearly broke me, and why I chose this stack over the traditional SIM card model that's dominated telecom for 30 years.

If you're a developer curious about what it takes to build in the telecom space, or a founder evaluating whether eSIM is worth betting on, this is for you. No fluff. Just the real stack, the real problems, and the real numbers.

The Problem With Traditional SIM Cards (And Why It's 2026)

Let's be honest: physical SIM cards are a relic. They were designed in 1991 for a world where you bought one phone, signed one contract, and stayed in one country. That world doesn't exist anymore.

Here's what travelers actually deal with:

• Airport SIM kiosks that charge 3x the local rate — and sometimes sell you a plan that doesn't even work across the border
• Roaming plans that cost $10/day for 500MB of throttled data — enough to check email, not enough to navigate an unfamiliar city with Google Maps
• SIM swapping — losing your primary number, missing 2FA codes from your bank, juggling tiny plastic cards in a moving taxi
• Coverage gaps — one SIM works in France but dies the moment you cross into Switzerland, and now you're hunting for a new SIM at a Swiss train station at 11 PM
• e-waste — the telecom industry manufactures over 4.5 billion plastic SIM cards every year. Most end up in landfills within months

The GSMA estimates that over 4.5 billion eSIM-capable devices will be in circulation by 2027. Apple went eSIM-only with the iPhone 14 in the US market back in 2022. Samsung, Google, and every major Android manufacturer now ship eSIM-capable devices. The hardware is ready. The GSMA standards are mature. The only thing missing was a platform that made buying and activating an eSIM as easy as ordering a coffee.

So I built one.

The Architecture: What I Actually Built

Before diving into code, I needed to answer one question: what does a global eSIM platform actually do under the hood?

At its core, an eSIM platform is a connectivity marketplace. It sits between travelers (who need data) and mobile network operators (who sell it). But unlike a traditional MVNO, you don't own spectrum, towers, or physical infrastructure. You're orchestrating digital SIM profiles across hundreds of carriers worldwide — and that changes everything about how you design the system.

Here's the high-level architecture I landed on after 18 months of iteration:

• Frontend: Next.js 14 with App Router — server-side rendering for SEO-heavy country pages (200+ country-specific landing pages), client-side interactivity for the plan selector, coverage map, and checkout flow. Static generation for blog content, ISR (Incremental Static Regeneration) for pricing pages that change frequently
• API Layer: Node.js with Express behind an NGINX reverse proxy, deployed on Cloudflare Workers for edge routing and geo-based redirects, with a dedicated VPS cluster for stateful operations like eSIM provisioning and payment processing
• Database: PostgreSQL 16 (primary) with connection pooling via PgBouncer — handles orders, customer profiles, plan inventory, and carrier relationships. Redis for caching plan availability and pricing with per-carrier TTLs — eSIM inventory changes by the minute, and stale pricing is a trust killer
• eSIM Provisioning: GSMA RSP (Remote SIM Provisioning) via SM-DP+ (Subscription Manager Data Preparation) — this is the actual protocol that delivers eSIM profiles to devices. We integrate with multiple SM-DP+ providers for redundancy
• Carrier Integration: REST APIs, SOAP endpoints, and SMPP (Short Message Peer-to-Peer) for SMS-based activation fallback on older devices. Each carrier gets an adapter module behind a shared interface
• Payment Processing: Stripe with multi-currency support — travelers pay in USD, EUR, GBP, AUD, JPY, and 20+ other currencies. Webhook-based order confirmation with idempotency keys to prevent double-charging during network hiccups
• Monitoring & Observability: Datadog for API health and latency, Sentry for error tracking with source maps, custom Prometheus metrics for activation success rates per carrier, and Grafana dashboards for real-time order funnel visualization
• Infrastructure: Docker containers orchestrated with Docker Compose (we're a small team — Kubernetes would be overkill), deployed on Hetzner and AWS Lightsail for geographic distribution, with Cloudflare for CDN, DDoS protection, and DNS

The stack isn't exotic. It's boring technology applied to a hard problem. And that was intentional — I'd rather debug a well-understood Postgres query than a bleeding-edge distributed database at 3 AM when a customer in Tokyo can't activate their eSIM.

Why This Stack? The Decisions That Mattered

1. Next.js Over a SPA: SEO Is Everything in Travel

I started with a React SPA (Create React App, classic 2023 move). Within a month, I realized I'd made a catastrophic mistake. Our country-specific pages — /japan-esim, /europe-esim, /thailand-esim — were invisible to Google. Client-side rendering meant crawlers saw empty divs with loading spinners.

Switching to Next.js with SSR was a two-week migration that paid for itself in 30 days. Organic traffic from "best eSIM for Japan" and similar long-tail queries jumped 340%. For a travel product with 200+ location-based landing pages, SEO isn't a nice-to-have — it's the primary acquisition channel. Every country page is a potential entry point from Google.

I also use Next.js ISR (Incremental Static Regeneration) for pricing pages. They rebuild every 15 minutes in the background, so Google always sees fresh content with current prices, but users never hit a cold server render. Best of both worlds.

Lesson: If your product has hundreds of location-based pages, server-side rendering isn't optional. It's table stakes. And ISR is the secret weapon for content that changes frequently.

2. PostgreSQL + Redis: The Pricing Problem

eSIM pricing is volatile. Carriers update rates weekly, sometimes daily. A plan that costs $4.99 today might be $5.49 tomorrow. If a customer sees one price and gets charged another, you've lost their trust — permanently. In travel, trust is everything.

I built a pricing pipeline that:

1. Polls carrier APIs every 15 minutes for rate changes using a cron-based worker
2. Writes to PostgreSQL as the source of truth with full audit logging (who changed what, when, and the delta)
3. Caches the latest prices in Redis with a 5-minute TTL per carrier
4. Invalidates the Cloudflare CDN cache for affected country pages automatically via API
5. At checkout, re-verifies the price against the carrier API in real-time before charging the customer

This means the plan selector always shows near-real-time pricing, and the checkout flow verifies the price hasn't changed between page load and purchase. If it has, we surface the difference before charging — no surprises, no angry support tickets.

The audit log in Postgres has saved us more than once. When a carrier claimed we were showing outdated prices, we could point to the exact timestamp and API response that set the current rate. Documentation is defense.

3. The Carrier Integration Nightmare (And How I Survived It)

This is the part nobody talks about in "building in public" posts. Integrating with mobile carriers is hard. Not technically hard — the GSMA RSP spec is well-documented and surprisingly clean — but operationally hard.

Here's what I learned the hard way over 18 months:

• Every carrier has a different API. There's no universal standard. Some use REST with JSON, some use SOAP with XML envelopes (yes, in 2026), some require SFTP file drops with CSV order batches processed every 4 hours. I built an adapter pattern — each carrier gets its own integration module that conforms to a shared TypeScript interface. Adding a new carrier means writing one adapter class, not refactoring the entire platform. We're at 47 carrier adapters and counting.
• Rate limiting is unpredictable and undocumented. One carrier allows 100 requests/minute. Another allows 10. A third has no documented limit but starts returning 429s after exactly 50 requests in a rolling 60-second window — I had to discover that through trial and error. I built a token-bucket rate limiter per carrier with automatic backoff and a shared Redis counter. It's saved us from countless production outages.
• Activation failures are inevitable. About 2-3% of eSIM activations fail on the first attempt. Reasons range from device incompatibility (some Android manufacturers implement eUICC differently) to carrier provisioning delays (a profile that should take 30 seconds sometimes takes 5 minutes). I built a retry queue with exponential backoff (30s, 2min, 10min, 1hr) and automatic customer notification at each stage. Transparency turns a technical failure into a trust-building moment — customers are remarkably understanding when you tell them exactly what's happening and what you're doing about it.
• Time zones will break your billing. A plan activated at 11:59 PM UTC on Monday might expire at 11:59 PM UTC on the following Monday — but the customer is in Tokyo, where it's already Tuesday. I learned to store all durations in hours (not days) and display expiry in the user's local timezone using Intl.DateTimeFormat. Sounds obvious in retrospect. Wasn't obvious at 2 AM debugging why Japanese customers were seeing "expired" plans that still had 23 hours left.
• Carrier sandboxes don't match production. Every carrier provides a test environment. None of them behave like production. Different rate limits, different error messages, sometimes entirely different API versions. I now budget 2-3 days of production testing per carrier integration, with a dedicated test device and a real eSIM profile purchase. There's no substitute for testing with real money on a real network.

The SM-DP+ Protocol: How eSIM Profiles Actually Reach Your Phone

This deserves its own section because it's the core technology that makes everything possible — and it's surprisingly elegant once you understand it.

When a customer buys an eSIM plan on iWanteSIM, here's what happens behind the scenes in real-time:

1. Order received → Our API validates payment via Stripe, checks plan availability with the carrier's inventory API, and generates a unique order ID
2. Profile generation → The carrier's SM-DP+ server generates a unique eSIM profile (essentially a digital SIM card) bound to the customer's device EID (eUICC ID). This profile contains the IMSI, authentication keys, and carrier network configuration
3. QR code delivery → We generate a QR code containing the SM-DP+ activation URL with the matching ID embedded. The customer scans it, and their device's eUICC (embedded Universal Integrated Circuit Card) initiates a secure TLS session with the SM-DP+ server to download and install the profile over the air
4. Activation confirmation → The device registers on the carrier's network using the newly installed profile. We receive a confirmation via the carrier's webhook API and update the plan status from "provisioning" to "active"

The entire flow — from payment to active data connection — takes under 90 seconds on a good connection. Compare that to finding a SIM kiosk, waiting in line, showing your passport, and manually configuring APN settings. The difference isn't just convenience — it's a completely different product category.

The GSMA's SGP.22 (RSP Technical Specification) and SGP.32 (IoT eSIM) standards govern this entire process. If you're building in this space, read them. They're dense — SGP.22 is over 200 pages — but essential. The spec covers everything from profile download and installation to remote profile management and deletion. Understanding it is the difference between building a reliable platform and building a house of cards.

For a deeper dive into how eSIM technology works, I wrote a comprehensive guide on What Is an eSIM? that breaks down the technical details in plain English.

What I'd Do Differently

Building in public means being honest about mistakes. Here are mine, unfiltered:

• I should have started with a monolith. I over-engineered the initial architecture with microservices — separate services for billing, provisioning, notifications, and analytics. For a team of three, this was insanity. The operational overhead of managing inter-service communication, distributed tracing, and deployment coordination ate 40% of our engineering time. I consolidated into a modular monolith after six months and deployment velocity doubled. Microservices solve organizational scaling problems, not technical ones. If you're a small team, keep it simple. You can extract services later when you actually need to.
• I underestimated customer support complexity. eSIM activation isn't always smooth. Some Android manufacturers implement eUICC differently. Some iPhones need a specific iOS version (we still get tickets from people on iOS 15). I should have built the troubleshooting flow — device compatibility checker, step-by-step activation guide with screenshots, and automated diagnostics — before launch, not after the first 500 support tickets. Our eSIM activation guide now handles 90% of common issues automatically, but it took months to get there.
• I should have launched with fewer countries. I launched with 80+ countries because I wanted to look "global" and impressive. In reality, 80% of our first-month revenue came from 12 countries (Japan, USA, Thailand, UK, France, Italy, Spain, Germany, Australia, South Korea, Singapore, UAE). I should have focused on those 12, perfected the experience, and expanded gradually. Instead, I spent weeks debugging carrier issues in markets with literally zero customers. Vanity metrics are expensive.
• I should have invested in monitoring earlier. For the first three months, I had no idea what our activation success rate was. I'd find out about carrier outages from customer support tickets. Now we have per-carrier Prometheus metrics, Grafana dashboards, and Slack alerts when any carrier's success rate drops below 95%. The peace of mind is worth every minute of setup.

The Numbers (Because Building in Public Means Sharing Real Data)

After 18 months of building and iterating, here's where we stand:

• 200+ countries covered with eSIM plans starting at $1.00
• 12,000+ travelers have used iWanteSIM across 180+ countries
• 4.9/5 average rating across verified reviews
• 92% activation success rate on first attempt (up from 84% at launch — every percentage point represents hundreds of fewer support tickets)
• Average activation time: 47 seconds from QR scan to connected (down from 2+ minutes at launch)
• Customer support volume: Down 60% since launching the interactive activation guide and device compatibility checker
• 47 carrier integrations live, each with its own adapter module behind a shared interface
• 99.7% API uptime over the last 90 days — the provisioning pipeline is the one thing that absolutely cannot go down

These aren't vanity metrics. Every number represents a real problem we solved — a failed activation we debugged at 3 AM, a confusing UI we redesigned after watching session recordings, a carrier integration we stabilized after weeks of back-and-forth with their engineering team.

Why eSIM Wins Over Traditional SIM Cards

I didn't choose eSIM because it was trendy. I chose it because the economics and user experience are fundamentally better in every dimension that matters:

• Zero physical inventory. No manufacturing, no shipping, no retail distribution, no SIM cards lost in the mail. A digital SIM profile costs fractions of a cent to deliver. The marginal cost of serving one more customer approaches zero.
• Instant delivery. Customer buys → QR code appears → scan → connected. No waiting for a SIM card to arrive in the mail. No hunting for a SIM kiosk in a foreign airport at midnight.
• Multi-profile support. Modern phones support 8+ eSIM profiles simultaneously. Travelers can keep their home number active for calls and 2FA while using a local data plan for everything else — no more SIM swapping, no more missed authentication codes.
• Environmental impact. The telecom industry produces 4.5 billion plastic SIM cards annually. Most are used for weeks or months, then discarded. eSIM eliminates that waste entirely — no plastic, no packaging, no shipping carbon footprint.
• Remote provisioning. Carriers can update, replace, or revoke eSIM profiles over the air. No physical access needed. This is transformative for IoT — imagine updating the connectivity profile on 10,000 asset trackers without touching a single device.

Traditional SIM cards had a 30-year run. They served their purpose. But in a world where people change countries more often than they change phone numbers, the plastic SIM card is obsolete. The future of mobile connectivity is digital, instant, and global.

What's Next

I'm currently working on three major initiatives:

• IoT eSIM support — connecting devices beyond phones (cars, drones, asset trackers, smart meters) using the GSMA SGP.32 standard. This is a fundamentally different challenge — IoT devices don't have screens to scan QR codes, so the entire provisioning flow needs to be API-driven and automated.
• AI-powered plan recommendations — analyzing travel itineraries to suggest the optimal eSIM plan based on countries visited, trip duration, and typical data usage patterns. If you're spending 3 days in Japan and 4 days in South Korea, you shouldn't need to manually compare 20 different plan combinations.
• Enterprise API — letting travel agencies, airlines, and booking platforms embed eSIM purchasing directly into their checkout flows. Imagine booking a flight to Thailand and getting an eSIM offer before you even land.

If you're building in the telecom or travel tech space, I'd love to connect. The eSIM ecosystem is still young — GSMA estimates we're at less than 15% of eventual market penetration — and there's room for a lot more innovation. Drop a comment below or reach out. I read every response.

---

This article is part of our "building in public" series at iWanteSIM. If you're curious about how eSIM technology works under the hood, check out our What Is an eSIM? guide. Ready to try it yourself? Our eSIM activation guide walks you through setup in under 2 minutes.