I built a local-first Android automation workflow for AI agents — looking for feedback
I’m building AIVane, a project that lets AI agents operate Android phones locally over LAN.
The repo and skill are public.
Right now I’m trying to validate 3 things:
whether local-first is actually a differentiator
what the first compelling use case is
how much setup friction people are willing to tolerate for privacy/control
I’m not trying to sell anything here — mainly looking for honest feedback from builders:
What would you try first, and what would stop you from trying it?
Happy to share the repo/demo in the comments.
Trending on Indie Hackers
Local-first is the right instinct for Android automation. I’m building Kinetic Override in the smaller “record taps/swipes/long-presses and replay them locally” lane, and the hardest trust issue is similar: users need to see exactly what is recorded, where profiles live, and how a loop behaves before they trust any automation layer.
Local-first is the right instinct, I built a similar Android test harness and the biggest win was keeping every action replayable. After about 20 runs, adding a step log plus a hard cap of 3 retries stopped the agent from looping on flaky screens. Curious how you're handling permissions and app state changes, that part usually breaks first.
Most first SaaS launches don’t fail because of the product they fail because the value isn’t obvious fast enough.
A short, well-crafted demo can fix that.
I work with founders to create simple, high-end product videos that show exactly what the product does and why it matters within seconds.
If you’re launching soon, this is what helps turn early traffic into actual users
This is interesting — quick question:
Have you ever had parts of your workflow behave differently over time even when nothing obvious changed?
I’ve been seeing that pattern a lot with AI-driven systems.
Been working on a small runtime layer that stabilizes that kind of drift underneath workflows — not replacing anything, just keeping behavior consistent.
Curious if you’ve run into that at all.
Local-first is interesting, but I’d frame the differentiator less as “runs on LAN” and more as “safe control over real devices without sending sensitive screen/app data to a third party.”
The first use case I’d test is QA/repetitive app workflows, not general phone automation. What would stop me is setup friction unless there’s a very clear 5-minute path from install → first successful action.
Local-first is interesting, especially for something like this.
Curious how you’re handling reliability vs flexibility — does it get messy when workflows grow?
Also feels like a lot of tools underestimate how much time people spend just setting things up vs actually using them.
This direction is interesting — especially local-first.
Feels like most AI tools are over-dependent on cloud latency right now.
Curious — are you seeing real use cases where people need this locally, or is it still more experimental?