Built a home screen widget because my own app was too slow for my own ideas
so I've been building UluP Spaces (visual project mapping, nodes on a canvas instead of lists) for a couple months now. solo, indie, the usual.
this weekend's problem: I kept having ideas at the worst possible times to write them down. and even my own app, which is already fast, required too many steps for a 3-second thought — open app, find project, find the right node. by the time I did all that the idea was half-forgotten.
so I built an android home screen widget. one button. tap it, type, save, done. no app opening. the text lands in an auto-created "Inbox" project and I sort it out later when I actually have time.
technical bit that might be interesting to other indie devs shipping capacitor apps: the widget is native java, it never touches the webview. it just calls my own public REST API directly with an api key stored on-device. same api anyone else could build an integration on top of.
live now, already using it daily myself. small feature but it's the kind of thing that changes how much friction there is between having a thought and not losing it.
Really solid approach — curious how you're thinking about this, what's been the hardest part to figure out so far?
Worth noticing that by having the widget hit your public REST API with a device key instead of going through the webview, you've accidentally shipped your integration story before you shipped any integrations — that's the same path a Shortcuts action or a desktop capture tool would take.
That's a sharp way to put it — didn't think of it that way but you're right. The moment the "client" is just an HTTP call with a key, it stops mattering whether that client is a widget, a Shortcuts action, a menu-bar tool, or someone else's integration entirely. Same door, different knocker.
No iOS app yet, so a Shortcuts action isn't something I can ship immediately, but this is a good argument for why that's now a much smaller lift than it would've been a month ago — the API doesn't care what's calling it. Desktop equivalent (a quick-capture from the menu bar/tray on UluP Desktop) is genuinely closer now too, for the same reason.
Appreciate you naming the pattern — makes it easier to think about what else falls out of the same shape for free.
Capture friction is what kills most idea tools, so one tap straight to an Inbox makes a lot of sense. Since the widget calls your API directly, what happens when the phone is offline: do notes get queued on the device and retried? Losing a thought captured on the subway would defeat the whole point.
Good catch, and no — right now it doesn't queue anything. If the request fails, the note is gone, just a toast saying it failed. Which is, as you point out, exactly the scenario where this feature matters most and currently fails hardest.
Fixing this properly means a local queue on the device (WorkManager retry when connectivity returns, or just a local file as a buffer) instead of a fire-and-forget HTTP call. Not built yet, but you've convinced me it should be before this, not after.
The insight underneath this is that capture and analysis are different mental modes and mixing them kills both. Your full canvas app is where you think spatially about a project. The widget is where you dump a raw fragment before it disappears. Forcing both through the same interface means either the capture is too slow or the analysis is too shallow.
We see the same split in our SEO tool. The full audit runs 2,000 pages across 100+ factors — that is the canvas. But the thing people reach for first is the 30-second instant scan that just tells them the one thing to fix right now. Two interfaces for two mental modes, same data underneath.
The native Java widget bypassing the webview entirely is the right call for a Capacitor app. WebView cold start on Android adds enough latency to break a three-second interaction.
That capture/analysis split is a good way to name what I was doing intuitively. Appreciate the SEO tool parallel — same shape, different domain: quick surface pass vs. deep dive, and mixing them into one interface serves neither well.
On the WebView point: yeah, that was non-negotiable once I thought about it. A cold WebView start is already noticeable inside the full app; for a "should take 2 seconds" widget it would have killed the whole premise.
This is actually a great example of how a small feature can make a product feel much more useful. The ‘3-second thought’ problem is real if capturing the idea takes longer than the thought itself, there’s a good chance it gets lost. I also like the fact that you built the widget around the existing workflow instead of trying to make users change their habits. The native Java + direct REST API approach is pretty interesting too.
Thanks — the "fit the existing workflow" part matters more to me than the native code, honestly. I've abandoned features before that were technically neat but asked users to change how they already work. This one just removes a step instead of adding a new habit.