Building Evoke to solve my own frustration - Simple tools should be readily available!
I'm building Evoke .
It's an app that lets you quickly spawn simple tools (I call them micro apps) on your phone.
Here's the back story:
The trigger
I wanted a custom timer for my physiotherapy. I did find an app on Android which I used for a couple of days. But personalizing it further or creating more timers required pay plans
So I thought well, it's 2026. I should be able to build using AI, right? There are vibe coding platforms that can help be build an app. but:
-
That would involve building APK, installing on my phone or publishing it, etc for every app I want to build just for myself
-
The publicly available apps are not personalized, they are built to be generic, which sometimes make it more complicated than they are supposed to be
This led me to the idea of Evoke
The Idea
Simple tools like timer, to-do lists, habit, trackers, etc can just be spawned on your smartphone itself, without needing build and APK for each. Evoke helps you do exactly that:
Give it a simple prompt => It will spawn a micro app for you that you can save for later use. You can modify it to personalize for yourself. You can spawn even AI powered micro apps, so they can talk to AI through my backend.
For example, if changing tone of your message is a frequent use case, instead of writing a prompt every time, you can simply create a micro app and give it buttons for each tone (e.g. friendly, professional ).
Every time you need to change the tone of a message, Just enter the message and tap the button.
What Next?
-
I have published a beta version of the app on Android. Soon I'll be adding a pro plan to it so people can use it a lot more (and I get revenue :) ).
-
iOS is right next
-
I have a lot of cool features in mind for my own user. But for adding new features to the published app, I'll be waiting for some insights of early users
I'm looking for some early users and feedback to help me make it more useful for others. Thank you
The physio timer story is good, that's a real itch. My worry is that people who want a custom timer badly enough to go prompt one are a rounding error, and everyone else just downloads the free one with ads.
yes. thats what I've been thinking
One approach in my mind, to solve for some common tools like timer, give them as preloaded micro app.
so users looking for custom timer can just download evoke with a pre-installed custom timer. they can simply use it without ads, or they can customize it using prompts.
once on the app they they may discover that they can also create other tools and micro apps.
The interesting problem isn't creating micro apps faster—it's deciding when a custom tool is worth creating instead of adapting to existing ones. I'd keep validating whether users want infinite personalization or a faster path from recurring frustration to a useful workflow.
Thank you. That's a great callout.
One of my goals right now is not to add more features, but to get more users, gain insights, and figure out what direction makes more sense for Evoke
I think that's a sensible priority.
One thing I'd pay close attention to is not just what users ask you to build, but what repeatedly causes them to create a new micro app instead of extending an existing one.
That decision probably reveals more about the long-term opportunity than any individual feature request.
The physiotherapy timer is a good wedge because it has repeated use and obvious personalization, unlike a one-off micro app. I'd track whether people reopen the same generated tool five or more times and modify it after real use; generation count alone will flatter curiosity. The hard boundary is permissions: what can a micro app access on-device without turning every tool into a security review?
Honestly, I didn't think of this one ^ Will capture these metrics.
Thanks
That metric gets sharper if reopen and edit stay separate. Five reopens shows recurring utility; an edit after the third use shows the tool is becoming personal rather than merely reusable. Keeping both events visible will stop one good number from hiding the other.
Right now, no access outside the sandbox.
Native capabilities I imagine to be very useful are : notification, file storage (say for uploading or downloading) or camera
I have very little knowledge in app development to say that with certainty, but the security review/permission will be for Evoke, the micro apps just access what Evoke provides (via native bridge that I will build)
What I will likely never allow - network access outside of my own backend, access to other app's data, any elevated access, etc
The native bridge is the right choke point, but I'd make each capability explicit per micro app instead of granting Evoke a broad bundle. A timer needs notifications, a receipt tool may need camera, and neither should inherit file access. Showing the generated tool's capability manifest before first run will make the security model legible.