A developer got tired of Firebase and Ngrok for cross-device automation, so they built their own message queue in 100 lines of Flask and SQLite. No external dependencies. No third-party services. Just a minimal Python app that lets a cloud server send jobs to an Android phone and wait for results.
It's called Intent Bus, and the interesting bit isn't the tech stack - it's the simplicity. Most developers reach for Firebase Cloud Messaging or set up Ngrok tunnels for this kind of thing. Both work, but they're heavy. Firebase locks you into Google's ecosystem. Ngrok is great for development but gets expensive at scale. This approach is just a database, a web server, and 100 lines of code.
How It Actually Works
The system has three parts: a Flask server running in the cloud, an Android app polling for jobs, and a SQLite database acting as the message queue. The cloud server creates a job - "take a screenshot," "check battery level," whatever - and writes it to the database. The Android app polls every few seconds, grabs the job, executes it, and writes the result back to the database. The server waits for the result and returns it to the calling application.
The clever bits are in the details. The system uses atomic locking to make sure only one device picks up each job. If multiple phones are polling the same queue, they won't collide. It also uses visibility timeouts - if a job isn't completed within a set window, it gets returned to the queue. That means transient failures don't kill the whole system.
There's no websockets, no long polling, no push notifications. Just HTTP polling every few seconds. That sounds inefficient, but for automation tasks where latency isn't critical, it's more than fast enough. And it's drastically simpler to debug and maintain than a websocket-based system.
Why This Approach Matters
Most developers over-engineer this problem. Cross-device communication feels complex, so we reach for complex tools. But if your use case doesn't need sub-second latency, polling a database is often the right answer. It's stateless, it's simple, and it scales surprisingly well if you index your database properly.
The SQLite choice is interesting too. For a single-server setup handling moderate traffic, SQLite is faster than Postgres or MySQL because there's no network overhead. Everything happens in-process. It's only when you need horizontal scaling - multiple servers reading the same queue - that you'd switch to a networked database. For most automation tasks, that's overkill.
The other benefit of this approach is you own the entire stack. No API keys to rotate, no rate limits to hit, no external service that could deprecate the feature you depend on. It's just your server, your database, and your code. If something breaks, you can fix it. If you need to add a feature, you can add it. That level of control is rare in 2025.
What You Could Build With This
The developer built this to automate their Android phone from a cloud server - taking screenshots, running scripts, checking system stats. But the pattern works for any scenario where you need reliable job distribution across devices. Home automation. IoT sensors reporting data. Distributed scraping. Background processing tasks that need to run on specific machines.
The beauty is the simplicity. You don't need to understand message brokers or queue systems. If you know Flask and SQL, you can build this in an afternoon. And because it's so minimal, you can modify it for your exact use case without fighting against a framework.
For small businesses, this kind of approach is particularly appealing. You can automate workflows without paying for enterprise tools or dealing with vendor lock-in. A local server, a phone or two, and you've got reliable cross-device automation for essentially zero ongoing cost.
The Trade-Offs
This isn't a replacement for Firebase in every case. If you need instant push notifications or you're coordinating thousands of devices, you'll want something more robust. Firebase is built for scale. Intent Bus is built for simplicity.
But for the 80% of use cases where you just need jobs to run reliably and you don't care if there's a few seconds of latency, this approach is cleaner. Less moving parts. Less surface area for bugs. Less vendor dependency. That's worth a lot.
The other limitation is horizontal scaling. Because SQLite locks the entire database on writes, you can't have multiple servers writing to the same queue without hitting bottlenecks. The developer knows this and suggests switching to Postgres or Redis if you need multi-server support. But for single-server setups, SQLite is perfect.
What This Signals
There's a broader trend here. Developers are getting tired of complex infrastructure for simple problems. We've spent the last decade reaching for microservices and distributed systems by default, even when a monolith would work fine. Now there's a counter-movement: build the simplest thing that works, and only add complexity when you actually need it.
Intent Bus is part of that. It's a reminder that you don't need a managed queue service for every automation task. Sometimes a database, a polling loop, and 100 lines of code are enough. And when they are, you get something you can understand, modify, and maintain without external dependencies.
That's powerful. Not because it's cutting-edge, but because it's yours.