Every few weeks, a customer asks some version of the same question: "Is there an app?" There isn't. You manage AIVA from a browser — on your phone, on your laptop, wherever you have a tab open. That answer doesn't fully satisfy people, and I understand why. In 2026, "there's no app" sounds like an oversight, the kind of gap a company fixes once it finally gets around to it. I want to explain why it isn't that, walk through the middle-ground version we actually scoped and then set aside, and lay out exactly what would have to be true before we changed course.
What people are really asking for
When we dig into the request, it's rarely "I want an app" in the abstract. It's one of three specific things, and they deserve to be treated separately rather than folded into one feature request that sounds bigger than it is.
The first is a push notification the moment a call comes in — something that buzzes on a phone the way a text message does, instead of something you have to remember to go check. The second is a faster way to glance at today's bookings between patients or clients — not a full dashboard session, just "what does my afternoon look like," answered in three seconds instead of thirty. The third, which we hear less often but always notice when we do, is wanting something to show a business partner, an investor, or a skeptical relative that looks more like "real software." An icon on a home screen carries a kind of legitimacy a bookmarked browser tab doesn't, fairly or not.
The first two are real, solvable product problems, and we've already solved most of the first one through SMS and email rather than a native push notification. The third isn't a product problem at all — it's a perception problem, and we're not going to maintain two new codebases indefinitely just to make AIVA look more like an app to people who aren't the ones actually using it day to day.
Why the browser has been enough so far
Our dashboard is responsive — it works on a phone screen without much squinting, collapsing to a single column, with today's bookings surfaced as the first thing you see rather than buried three taps deep behind a menu. Most owners check it the way they check their bank's mobile site: open the browser, stay logged in from last time, glance, close it. It's not a workflow people live inside for hours. It's a workflow people dip into for under a minute, several times a day, and a bookmarked tab handles that shape of use perfectly well.
For the notification half of the request, we already push SMS and email alerts for new bookings and missed calls, and those get read faster than most app notifications do anyway — everyone already has their messages open, whereas an app notification competes with dozens of others for a glance before it gets swiped away unread. We didn't build SMS alerts as a consolation prize for the push notifications we couldn't ship yet. We built them because, for an owner who's mid-appointment or mid-shift, a text message is a better-fitting interruption than an app badge they won't see until they next unlock their phone regardless.
That's not a dismissal of the request. It's an honest account of why it hasn't been urgent enough to jump the queue ahead of the voice pipeline, the next language, or the SMS engine.
What we scoped and quietly set aside
We got close to building something once — not a full native app, but a lighter middle ground: wrapping the dashboard as an installable home-screen web app, with its own icon and enough native-feeling chrome that it would sit on a phone's home screen the way an app does, while still being the same web codebase underneath. On paper it looked like a shortcut past the whole two-codebase problem, and for a few weeks it was genuinely on the roadmap.
We scoped it, then set it aside, for two reasons. First, it solves the "icon on the home screen" problem but not the notification problem — reliable, always-arrives push notifications still require platform-specific plumbing that a wrapped web page, of the kind Google's own guidance on installable web apps describes, doesn't give you for free, especially on iOS, where Apple's own engineering team has documented background notification support for installed web apps as historically the least consistent part of the whole approach. We'd have shipped something that looked like it fixed the request without actually fixing the part people cared about most. Second, and more honestly, it would have shipped mostly to satisfy the perception request — the "looks like real software" one — which we'd already decided wasn't a problem worth engineering time. Building a halfway app to solve a problem we didn't think was real felt like the wrong reason to ship anything, so we didn't.
We're a small engineering team building a product across four surfaces already — voice, SMS, web widget, and the dashboard itself, in twelve languages. Every new surface we add is a surface we now have to keep excellent, not just ship once.
What building the real thing would actually cost
A native app isn't a smaller version of the dashboard. It's two new codebases — iOS and Android — with their own release cycles, their own app store review queues, their own bug classes that only surface on specific device-and-OS-version combinations, and their own on-call burden. Apple's review process alone can add days to a release that would ship to the web in minutes; Android's fragmentation across manufacturers and OS versions turns "it works on my phone" into a much larger testing surface than a browser, which mostly behaves the same regardless of what it's running on.
For a team our size — and we've written before about why we've deliberately stayed small — that's not a two-week project slotted in between other work. It's a standing commitment: someone owns it, forever, at the same priority as the voice pipeline or the SMS layer, which means someone is, by definition, not spending that time on the parts of AIVA that actually answer the phone. We've watched other companies our size split their attention across a web app, a mobile app, and a browser extension, and end up with three mediocre things instead of one good one. We'd rather ship the best phone-answering AI in the market with a dashboard that just works, than a slightly worse core product with an app icon on your home screen.
What would change our mind
This isn't a permanent no. It's a "not yet, and not for the reason you'd think." We'd build a native app the moment one of two things becomes true. Either push notifications become genuinely time-sensitive enough that SMS and email lag actually costs someone something — for example, if we ever build live-call monitoring you'd want to glance at mid-call, where a few seconds of delay matters in a way it doesn't for "you got a new booking." Or enough customers tell us the browser is actively getting in their way, not that an app would be nicer to have, but that a bookmarked tab is genuinely costing them time or bookings.
Neither of those has happened yet. A mobile app sits right alongside a public API on the fuller list of things we've deliberately said no to — not because we lack the engineering to build either, but because we don't think either one is right yet. Both are close calls of the kind we keep a running account of. When one of those two triggers does happen, we'll build the app properly — not as a wrapper shipped in a rush to close the request, but as something that earns the two new codebases and the permanent maintenance burden that comes attached to them.
Until then
Bookmark the dashboard. It works, on a phone screen or a laptop, and every hour we're not maintaining an app is an hour going into the parts of AIVA that actually answer your phone — the voice pipeline, the language coverage, the booking logic that has to work correctly before any of the rest of this matters. If you want to see what that looks like without downloading anything, start free — it's the same three seconds to open as any app would be, minus the download.