2025 - Present
Private client workeSIM Commerce Platform
Owning a travel eSIM storefront end to end, checkout, payments, automated QR fulfillment, and the cross-domain auth that ties a multi-site product together.
Senior Full-Stack DevOps Engineer · final reviewer for all production releases
- path from payment to installed eSIM
- Zero-touch
- as the company's only engineer, uptime and releases held
- 6 months
- cross-domain auth across all company web properties
- 1 identity
- competitor price intelligence, delivered to Slack
- Daily
The Problem
A travel eSIM is bought at the worst possible moment for support: hours before a flight, or standing in an arrival hall on airport Wi-Fi. The product is a QR code that has to arrive instantly and work the first time, because the person buying it may have no other connectivity to ask for help.
I owned this platform as the company's sole engineer for six months: a production commerce system with paying customers, uptime to protect, and a release schedule to keep, while requirements came directly from the CEO and marketing, not from tickets.
Around the storefront, the business ran on manual effort: fulfillment steps that depended on a human being awake, and competitor pricing research that meant someone opening rival sites and taking notes, so in practice it rarely happened.
The Constraints
Paying customers from day one
This wasn't a greenfield build, it was a live commerce platform. Every change shipped against real orders and real money, where a mistake means refunds and lost trust, not a bug ticket.
The customer may be offline
Delivery has to assume one bar of airport Wi-Fi: the QR must arrive by email and live in the account, re-sends must be safe, and nothing in the flow can require the customer to already have data connectivity.
One engineer, whole company
Uptime, releases, features, and infrastructure as a team of one. Any workflow that needed a human in the loop was a workflow that would eventually fail at 2am, so fulfillment had to automate itself.
Many domains, one customer
The storefront lives alongside the company's other web properties on different domains. Customers had to be recognized across all of them, which makes authentication a cross-domain problem, not a login form.
The Architecture
A Next.js storefront with checkout on Vercel, an Express/MongoDB commerce API on Render, and automation wrapped around the moment that matters most: payment success → provision the eSIM → deliver the QR. A shared identity spans the company's domains, and a price-intelligence loop feeds the team in Slack.
- Fulfillment is event-driven off payment success: provisioning the eSIM profile and generating the QR happens automatically, with retries and alerting on failure, no human sits between 'paid' and 'connected.'
- Delivery is idempotent and recoverable: the QR lives in the customer's account and in email, and re-sending is always safe, designed for someone standing in an airport with unreliable Wi-Fi.
- Cross-domain authentication gives one customer identity across the storefront and the company's other web properties, so nobody re-registers because they arrived from the wrong subdomain.
- The competitor price monitor (its own service) scrapes rival eSIM plans, diffs pricing over time, and posts only meaningful movement to Slack, replacing manual market research with a daily signal the team actually acts on.
The Trade-offs
Every architecture is a set of bets. These are the ones I made, and what I gave up to make them.
Fulfillment
For a customer boarding a flight, any human step is both the bottleneck and the failure mode. Automation with a visible failure queue means the happy path takes seconds and the unhappy path pages someone, instead of a customer landing with no data and no answer.
Payments
With one engineer responsible for everything, minimizing the compliance and security surface is architecture, not cowardice. Webhooks drive order state with reconciliation on top, so the platform never touches card data but never loses an order either.
Authentication
Separate logins were the easy build and the wrong product: duplicate accounts, lost carts, and support tickets. The cross-domain session cost harder cookie and security work up front, and removed an entire category of customer confusion permanently.
Market intelligence
The team lives in Slack. Alerting only on real movement pushes decisions to where the team already works and keeps the channel high-signal, a dashboard would have added a place to check, not a habit.
The Outcome
The platform runs in production with real customers, releases stayed on schedule through the sole-engineer months, and I have since onboarded the first engineer to join me.
- Own checkout, payments, and automated QR fulfillment in production, the full path from 'buy' to 'connected' runs without manual steps.
- Kept uptime, release schedules, and feature delivery for six months as the company's only engineer, while building a real-estate platform for a second business in parallel.
- Shipped cross-domain authentication so one customer identity works across every company web property.
- Replaced manual competitor research with automated price monitoring and daily Slack alerts the team acts on.
- Now final reviewer for all production releases as the engineering team grows, with AI-assisted code review wired into the pull-request workflow.
Lessons Learned
Automate the moment of truth first
The payment-to-fulfillment seam is where a commerce product wins or loses trust. Automating that seam (before dashboards, before features) is what let one engineer run a platform that delivers in seconds at any hour.
Idempotency is a customer-experience feature
Safe re-sends, replayable webhooks, retryable provisioning, these read like plumbing, but they're exactly what makes an instant-delivery product feel reliable on bad airport Wi-Fi. Design every operation to be safely repeatable.
Sole-engineer systems must fail loudly
With no team watching dashboards, silence had to mean healthy. Every failure path posts to Slack or pages me, the discipline that makes a one-person on-call rotation survivable is the same one that makes a team's on-call humane.