Mohamad Merhi eSimy.io: a travel eSIM store built and run solo
The Problem
A travel eSIM store where the checkout, the transactional email, and the front-end performance all had to work, with no team behind any of them.
Constraints
- One person building and operating it, next to a full-time engineering job.
- No server to run. Anything that needs patching or monitoring is recurring cost for a side product.
- Payments handled by a provider, so no card data touches my own stack.
- The order confirmation is the product. If the email does not arrive, the customer has paid for nothing they can see.
- Search visibility and Core Web Vitals treated as build requirements, not a tuning pass after launch.
My Role
Everything. Front end, backend, payment integration, transactional email, SEO and performance work, and running it in production.
What I built
An Angular front end styled with Tailwind, over Firebase as the whole backend: Cloud Firestore for the catalogue and orders, Firebase Authentication for accounts, and Cloud Functions for the server-side steps that cannot happen in the browser. PayPal handles checkout. Resend delivers the transactional email that carries the order confirmation. There is no server in the stack that I have to keep alive.
Decisions and trade-offs
Firebase, despite .NET and SQL Server being the stack I know best
The entire backend is Firestore, Firebase Authentication, and Cloud Functions, on a product where I would otherwise have reached for ASP.NET Core over SQL Server.
For a product I run alone in evenings, the cost that matters is not writing the code, it is operating it for years. Firebase removes the server from the equation. What I gave up is real: less control over query shape, and a data model I have to design around the platform's limits rather than the other way round.
PayPal rather than a card processor
Checkout runs through PayPal instead of a card form embedded in the site.
Integrating PayPal meant never handling card data myself, and not owning the compliance surface that comes with it. The cost is less control over how the checkout looks and behaves, on the one screen where that matters most.
A dedicated email provider for the confirmation
Order confirmations go out through Resend rather than whatever send mechanism was nearest to hand.
An eSIM has nothing to unbox. The confirmation email is the entire delivered artefact, so treating delivery as a first-class dependency rather than an afterthought is proportionate. It is one more service to keep an account with, which is the trade.
SEO and Core Web Vitals as build constraints
Structured metadata and performance budgets shaped the front end during the build rather than being tuned in afterwards.
Retrofitting page weight and layout stability costs far more than not creating the problem, so the metadata and the performance budget were part of the build rather than a pass afterwards. The cost is that some things I could have built quickly, I built carefully instead.
In the build
- The full path from browsing plans to a paid order and a delivered confirmation.
- PayPal checkout, so the payment step carries a name travellers already trust.
- Transactional email through a dedicated provider rather than a best-effort send.
- Firestore, Firebase Authentication, and Cloud Functions in place of a backend I would have to operate.
- Structured metadata and a front end built against Core Web Vitals from the start.
Outcome
- Live at esimy.io, running the complete path from browsing plans to a paid order and a delivered confirmation email.
- Built and operated by one person, with no server to keep alive.
- The second product where I own the whole stack, this time on Firebase rather than .NET and SQL Server.