I built one link for App Store, Google Play, and web fallback
I built Smart Linker because I kept seeing the same small but annoying problem around mobile app distribution.
You often need one link for the App Store, another for Google Play, and sometimes a third fallback link for desktop users. Then those links get copied into QR codes, launch pages, emails, ads, social bios, and support replies.
If one destination changes later, the public link is already everywhere.
Smart Linker keeps the public link stable and lets you update the underlying destinations later.
What it does:
- routes iPhone visitors to the App Store
- routes Android visitors to Google Play
- routes desktop visitors to a web fallback
- generates QR-ready links
- supports custom domains
- provides basic click analytics
What it does not do:
- attribution
- deferred deep linking
- retargeting
- MMP workflows
- SDK-based app integration
That is intentional. Branch and AppsFlyer are useful when you need attribution and deep linking infrastructure. I wanted something much narrower for teams that just need app install routing without SDK setup.
The product is live here:
I also listed it on SaaSHub:
https://www.saashub.com/smart-linker
Would appreciate feedback from anyone who has had to manage app install links, QR codes, or App Store / Google Play campaigns.
This is a useful wedge because you are deliberately avoiding the heavy Branch/Appsflyer category and solving the smaller pain cleanly: one stable public link that keeps working even when app destinations change later.
That matters more than it sounds. Once links are printed into QR codes, launch pages, ads, bios, emails, and support docs, changing them becomes messy fast. So the real value here is not just routing by device. It is keeping app distribution surfaces stable after launch.
One thing I’d pressure-test is the brand frame. Smart Linker is clear, but it may make the product feel like a tiny link utility, while the actual product could become a lightweight app distribution layer for indie apps, SaaS teams, and mobile launches.
Xevoa .com would fit that broader workflow direction better if you want the product to feel more durable than “smart links.” The product itself can stay simple, but the name should leave room for custom domains, QR flows, analytics, campaign links, and future mobile distribution workflows without sounding boxed into one feature.
Since links get embedded everywhere quickly, this is worth thinking through early before the public naming frame spreads across directories, QR codes, and launch assets.
Thanks, Aryan — this is very useful feedback.
You’re right that the main value is not just routing by device, but keeping distribution surfaces stable after launch: QR codes, support replies, launch pages, emails, and app store links.
I’m intentionally keeping the first version narrow because I don’t want to blur it into attribution, deferred deep linking, or MMP workflows too early. But the broader “mobile distribution workflow” framing is worth thinking through.
The naming point is also fair. I’m going to keep pressure-testing whether Smart Linker is clear enough as the product scope grows.
That's exactly the distinction I was thinking about.
The part I'd be interested in unpacking isn't whether to keep the first version narrow.
It's whether that narrow scope is simply the wedge into a larger category, or whether it's already defining the category the product belongs in.
Those can look identical early on but eventually lead to very different positioning decisions.
Happy to explain what I mean if it's useful. What's the best email to reach you on?