We Rebuilt a Travel eSIM Backend Around One Question: What Can We Remove?
At ySolves, a lot of the work we do with clients isn't about adding features — it's about finding the ones that were never necessary in the first place.
Last year we did exactly that with Travelsim Asia, a travel eSIM product. The brief wasn't "build us something new." It was more like: this works, but it's clunkier than it needs to be. Travelers are busy, stressed, arriving at airports — make it faster.
So that's what we focused on.
The actual problem with travel SIMs
Anyone who's traveled knows the friction: airport SIM queues, roaming bills, or installing an app you'll use for two weeks and never open again. The apps especially always felt like overkill — account creation, onboarding, notifications you don't want.
For a product that someone uses for a single trip, that's a lot of overhead.
The decision that shaped everything
We removed user accounts entirely.
No logins, no passwords, no "sign in to continue." After purchase, you get a secure access link in your inbox. That link is your interface — you can check usage, manage your plan, top up if needed. Everything lives there.
It sounds almost too simple, but that was the point. Email is infrastructure travelers already have. Their inbox travels with them. We don't need to compete with it.
The full flow ended up being: buy online → instant delivery → tap to install → connected. That's it. Nothing to download, nothing to set up, nothing to remember.
What this reinforced
Honestly, mostly things we already suspected but needed to actually build to believe.
Most software is overbuilt. Not because developers are careless, but because adding features feels productive and removing them feels risky. The instinct when something is broken is to patch it with another layer — another screen, another step, another confirmation.
But friction kills conversion. Especially for something as immediate as travel internet. If someone's landing in Bangkok and just needs to get online, every extra tap is a reason to give up.
Simplicity is also easier to maintain. By cutting the account system, we cut a whole surface area — password resets, session management, the login flow, all of it. Less to break, less to support, less to iterate around.
The question we now ask first
Before scoping anything now, we try to ask: what can disappear entirely? Not which tools to use, not which features to build — but which steps could just not exist.
It's a harder question than it sounds. Removal requires more confidence than addition. But when it works, it really works.
If you want to see how it plays out in practice: travelsimasia.com
And if you're working on something that's gotten more complicated than it should be: ysolves.com
Top comments (0)