Why every vibe-coded app deserves a native front end

You built an agent. It checks your home server, tracks a trading journal, waters a plant, watches a reactor that doesn’t exist yet but might as well. It’s good. It does things. And you talk to it through a Telegram bot.

That’s not a jab — most of us end up there. Telegram already has push, already has a chat UI, already has an API a language model can call in an afternoon. Building all of that yourself, for an audience of one, is a bad trade. So the bot happens, and it works, right up until the moment it doesn’t feel like yours. Your agent’s replies show up with Telegram’s notification sound, inside Telegram’s app icon, next to your group chats. The thing you built is running inside someone else’s front door.

The alternatives aren’t better. A pinned Safari tab with “Add to Home Screen” gets you an icon that looks native and behaves like a browser tab that forgot it was a browser tab — no real push, no Siri, no share sheet that knows your agent exists. Or you open Xcode, because dammit, you want this thing native, and you get partway through a connect screen before you remember that shipping to the App Store for one user means paying Apple’s review process the same attention you’d pay if you had ten thousand users. That project sits in a folder. Most of us have one.

The moment that actually matters

Here’s the thing that’s easy to miss if you’re deep in the code: the emotional payoff of a personal AI project was never really “it works.” It’s the moment it stops feeling like a script and starts feeling like software. For most builders, that moment is a push notification. Not a Telegram message with your bot’s name in small gray text above the bubble — an actual notification, with your agent’s own name and its own icon, sitting on your lock screen next to Messages and Mail. That’s the graduation. The project you’ve been describing as “it’s just a thing I hacked together” suddenly looks like a thing you’d show someone.

We think that moment deserves a real front end, not a workaround wearing one.

What “MCP for the iPhone” means

Here’s the frame we keep coming back to: MCP already solved half of this problem. It gave your agent a standard way to say “here’s what I can do” to a model. Parlane is the other half — a standard way for your agent to say “here’s what I can do” to a phone. Same idea, different audience. Your server declares a manifest (name, icon, which surfaces it supports), and the app renders chat, voice, dashboards, and push from that — natively, using real UIKit-descended components, not a webview wearing a costume.

The part we think is genuinely new: your dashboards are JSON, not a compiled build. “Ask your agent to add a battery widget to the home screen” is a sentence you can say to your own coding agent, today, and have it be literally true — no redeploy, no App Store update, no Swift. The app is a renderer for a contract; your agent is the one authoring the interface. We didn’t build a no-code tool. We built a client for a protocol simple enough that another AI can write to it directly from a page of documentation.

What this is not

We’d rather tell you the boundaries now than have you find them later.

There’s no bundled model. Parlane doesn’t run your agent, doesn’t manage API keys, doesn’t have an opinion about which LLM you use — it renders whatever your server sends it. If your server talks to a local model on your own machine, that’s between your server and your model; the app just draws the reply.

Voice in v1 is push-to-talk, not a phone call. Hold a button, speak, on-device transcription sends the text, on-device text-to-speech reads back the reply. It’s closer to a walkie-talkie than to Siri’s live conversational mode, and we’re not going to describe it as something it isn’t. If your use case is a hands-free running conversation, v1 will feel like a step down from that. If it’s “check something and get a spoken answer,” it holds up fine.

Dashboards are deliberately not arbitrary code. Every component comes from a fixed catalog — text, charts, tables, buttons, sliders, that kind of thing — and the server sends data, never a script. That’s a constraint we chose on purpose, partly because App Store review treats declarative UI very differently from downloaded executables, and partly because we don’t want your agent’s dashboard to be a security surface. If you need something the catalog doesn’t have yet, that’s a real gap, not a hidden feature we forgot to mention.

And Android isn’t here yet. It’s a fast-follow, not an afterthought — the app is built on a stack that makes Android a port rather than a rewrite — but “fast” doesn’t mean “day one,” and we’re not going to pretend otherwise.

Why we’re building it this way

The unglamorous version of our thesis: a vibe-coder’s agent is already doing real work. The thing standing between “a script I run in a terminal” and “software I’d show a friend” isn’t more intelligence. It’s a front door. Chat that streams properly. Voice that doesn’t require you to type into Siri’s translation of your intent. A dashboard your agent can update by writing JSON instead of you writing Swift. A push notification that looks like it came from your thing.

None of that is a new idea. It’s plumbing. But it’s the plumbing that turns a personal project into something that feels finished — and that feeling is worth building a whole app around.

If you want to see the actual contract — the manifest fields, the dashboard schema, the exact shape of a push payload — it’s all written down in the docs, same as everything else here. No sales page hiding the technical part; the technical part is the point.