Why I built the app I couldn't afford to use.

Ximos didn't start as a company. It started on May 1st, with one goal: I wanted to see a phone's screen and camera from my own phone, for basic security reasons — as a guard, not a product idea. I was an 11th-grade student in Rangpur, Bangladesh, and this was meant to be personal, nothing more.

I was using a well-known parental-control app at the time — AirDroid. Screen mirroring worked on the free plan; camera casting didn't, and couldn't even be trial-run once. The way to unlock it was a reward-ad system: watch ads to earn points, 5,000 of which unlocked three days of Pro access, once per month. Each ad took three to four minutes to complete for 5 to 15 points, and the daily reward limit capped out after 10 to 20 ads. On a good day that was maybe 150 to 300 points. Even being generous and assuming 500 points a day, reaching 5,000 took about ten days of watching ads for roughly an hour daily — to unlock three days of a feature that, with the free plan's 200MB monthly data cap burning out in three or four days, was barely usable for an hour before running dry again. Ten to twelve days of ad-watching for about an hour of actual use. That math is what started this.

So I began building a smaller version for myself. The first attempt, on May 1st, used WebSockets and Firebase, tested entirely on localhost through a browser on my own phone — camera access working, but with constant hanging and lag that made it barely functional. That first build didn't even have a real name yet; I called it "xim remote."

The next problem was practical: if I only built this for viewing a camera once, how would I fix bugs or push updates without physically getting the phone back? That question is what led to adding screen streaming and remote control in the first place — not as a monitoring feature on its own, but as a way to maintain the app remotely. Everything since grew from that starting point.

Getting there took far longer than expected. I spent weeks failing at implementing WebRTC properly — going back to improving the WebSocket version out of frustration each time, with no real improvement, before finally getting a working WebRTC connection. Even then, it only worked on the same Wi-Fi network, using Google's public STUN server. Testing with a second phone on a different network failed outright, and that's when I learned WebRTC needs a TURN relay server to work reliably across networks — and that reliable TURN infrastructure isn't free. Finding a usable free-tier TURN provider took about another week of dead ends before landing on one that worked.

The project's name changed twice before settling. It first went up as xim-remote.pages.dev on Cloudflare Pages — free hosting, because there was no budget for anything else, and the WebSocket-based version still lagged badly enough that early testing was genuinely frustrating. It became ximdroid.pages.dev next, and only later, once I bought a proper domain, became Ximos — with the company registered as Ximexa LLC, a name originally meant for a separate AI chatbot project I'd also been building at the same time, alongside schoolwork, alongside everything else.

Once XimosKid worked well enough to be genuinely useful, the question became whether to keep it private. I decided against that — partly because of the amount of work already in it, and partly because I'd hit the same reward-ad friction with more than one parental-control app before this, not just AirDroid. If the problem was universal, the fix should be too.

I considered open-sourcing everything, then didn't — not because of secrecy, but because publishing the full codebase risked two different failure modes: someone spending a year or two rebuilding it from scratch and burning out before finishing, or someone with less good intent using the architecture to build something closer to actual spyware. The compromise was to open-source the core service logic — the part that proves what the app actually does with each permission — while keeping some implementation details private.

That decision came with a responsibility I take seriously: an app with access to a camera, a screen, and a microphone carries real risk if it's built carelessly, or documented dishonestly. That's the reason this site now has a Trust Center with independent MobSF scan results instead of just marketing copy, and a Docs page with real source code instead of vague reassurance. It's also why, when a security review of our own claims surfaced a contradiction — a hideable app icon next to a promise that XimosKid "never disguises itself" — the fix was to document the trade-off honestly, including a real screenshot of the persistent notification, rather than quietly drop the promise.

Ximos runs on pay-as-you-go pricing instead of a subscription, because most families using a tool like this only need it for a stretch of weeks, not a permanent monthly charge — that was the exact problem AirDroid's model never solved for me. It isn't the main way this project is meant to sustain itself long-term; that's closer to a bet on something larger under the Ximexa name. But Ximos still has to cover its own hosting and TURN-server costs, which is the entire reason the ad-reward and pay-as-you-go system exists: revenue from it is capped at roughly 20% margin above what keeps the service running, by design, not as a marketing promise.

— Ximexa, founder of Ximos