A question for the vibe code hive mind: what would people actually want out of a vibe-coded app?

Sloppy Joe has ~20 users right now across both platforms. Site for context: https://sloppyjoe.ca/

Right now it works, with a handful of caveats I’d consider polish rather than blockers. I’ll know in a couple of days whether it clears review on both app stores, so some of this may end up moot, but I’d like to think through the architecture questions regardless.

The app store problem

To satisfy the “self-modifying app” rules, I may need to reframe Sloppy Joe as an educational coding app, something where you write the interfaces yourself. If you hook up an agent to it, there’s not much I could do to stop you, so I might as well make that path possible. So this might just be the framing I need to get past review, while the actual capability stays the same underneath.

Current workflow

Right now I connect to the MCP server via Claude Code or similar. It’s awkward to use CC on mobile (Termux, maybe?), so I’m interested in moving the whole thing onto the phone itself. The downside is losing the Claude Code harness (if that’s your jam). Also, currently billing discourages per token billing and encourages package billing. I’m pretty sure API token is token billing in most cases. The architecture already supports this in principle: I run two BEAM nodes, one that never receives updates and effectively can’t crash, and one that gets modified. Conceptually, the agent could live on the stable node.

The OS doesn’t like apps working in the background, so I’d need to make the case that this should be allowed, so the agent can keep working while the user goes and scrolls X, then notify when the app is ready. That’s part of why I took the safer route of offloading to a partner computer instead.

The annoying part of needing a computer is that I want to modify the app on the go, when I’m nowhere near one. Moving the agent onto the phone also opens the door to voice mode, where you just tell the agent what you want out loud. I’d be tempted to build a way into Sloppy Joe a way to trigger the MCP from the phone but then this is getting way too Rube Goldberg.

Where should the MCP server live?

If the agent doesn’t end up running on the phone, I need to stop self-hosting the MCP server, since right now it builds against an emulator on my infrastructure. This is fragile and annoying. The likely path is moving that build step to the user’s own machine, or at least giving people the option to run it locally if my server gets swamped. I’m assuming if you have the competence to get over the bar of installing via MCP you can install a CLI or desktop app. If you’re using iOS then you’re locked to using a Mac because Apple never thought this far ahead and all their efforts are to sell more hardware.

If this moves to the phone this collapses the need for MCP at all because the agent just runs against the phone itself. There are a couple of nice wins here at the price of a pretty fat install size.

Where do the tests live?

This also raises the question of where tests live. A mobile app release obviously doesn’t bundle its test suite, but building on the end device is new territory, so I don’t have a clean precedent to follow. If I keep tests on my own infrastructure, I’m effectively running a mini GitHub per user, which doesn’t feel sustainable. Landing them on the user’s machine (or maybe just on the phone itself) makes more sense. Tests are just text, so even if the app grows a bit, it’s nothing compared to something like WhatsApp storing images and media.

Right now I’m not forcing the agent to build tests but this seems obviously useful if people start building more complex things.

Curious what people think, especially anyone who’s wrestled with on-device agent execution, background processing limits, or figuring out where build/test artifacts should live in a system like this.

An image I generated for kicks.

image1200×799 117 KB

TLDR

Considering all the tradeoffs do people value convenience or control / privacy or install size?