Every product roadmap has two lists. One is what we're building. The other, less discussed but just as deliberate, is what we've decided not to build — not because we lack the engineering to do it, but because we don't think it's right for us, or right yet. I wanted to write the second list down honestly, because "no" is a real product decision, and I think most companies only ever publish the "yes" list. We've actually done the reverse once before, cataloguing every feature that almost didn't make the yes list — this is the companion piece to that one.
No outbound or cold-calling
We get asked for this more than almost anything else — a customer wants AIVA to also place reminder calls proactively, or occasionally, to cold-call a list of leads. A diagnostic lab once asked, reasonably, whether AIVA could call patients the moment their reports were ready instead of waiting for the patient to call in. It's a sympathetic use case, genuinely useful to the patient, and we still said no to shipping it as a general feature.
We've said no to cold-calling categorically, and we're cautious even about the first, more sympathetic case. Outbound AI voice at scale is exactly how this entire category earns its reputation for robocalls and spam — the same unsolicited-commercial-communication problem TRAI has spent years building consumer protections against on the human-telemarketer side of the phone. It's not that we couldn't build it responsibly at small scale for a single customer. It's that once outbound dialing exists as a checkbox in a self-serve product, we don't trust that we — or every customer using it — would hold the line on responsible use once the temptation was sitting right there. The easier decision was to not build the temptation. If we ever do build a narrow version of this, it will be opt-in, consent-gated at the individual level, and nothing close to a general-purpose dialer — and we're in no hurry to get there.
No video calls
This comes up periodically, usually from a customer who's seen a competitor mention it. We keep asking ourselves what problem it would solve that voice, chat, and SMS don't already solve for the use cases we actually serve — answering questions and booking appointments. So far, the honest answer is none that we've found. Video adds real infrastructure and bandwidth complexity, and none of it improves the resolution of "what are your hours" or "do you have a slot Friday." We'll build it the day a real, recurring customer need shows up that the other three channels structurally can't handle. We haven't seen that need yet, and we're not going to build ahead of it just because it's a checkbox competitors have.
No mobile app, yet
Business owners manage AIVA from a browser. There's no downloaded app, and we get asked about this often enough that I know it reads as a gap. The honest calculation: a mobile app is two more platforms to build, ship, and support indefinitely, for a workflow — checking on calls, adjusting hours, reviewing performance — that most owners do a handful of times a week, not continuously throughout the day. The web dashboard fits that cadence. We'd rather put the equivalent engineering time into the voice pipeline or a thirteenth language than into a native shell around the same screens we already have on the web. We've made the fuller case for this, including the two specific things that would actually change our mind, in a separate piece dedicated to just this question — it's the single most requested item on this whole list, so it earned its own essay rather than one paragraph here.
The current "no" list, in order of how often we get asked: outbound/cold-calling, video calls, a mobile app, a public API, and chasing enterprise certifications ahead of an actual customer need for them.
No public API, yet
We connect to calendars, CRMs, and payment tools through configured integrations — that part works and customers rely on it. What we haven't shipped is a fully public, self-serve API that anyone can build against. A public API is a permanent commitment: versioning, documentation, backward compatibility, a support burden that doesn't shrink once it exists. We're not going to make that commitment casually with an eight-person team. When we build it, it'll be because we're confident we can support it properly for years, not because it's a box enterprise buyers expect checked on a features comparison page. This is the second most-requested item after the mobile app, and it also got the longer, dedicated treatment — the fuller reasoning, from the engineer who owns the conversation layer this would sit on top of, is here.
No certifications we don't need yet
We do the compliance and security work our actual customers ask for, as they ask for it, rather than collecting a shelf of enterprise logos speculatively ahead of demand. Certifications done properly are slow and genuinely expensive to earn; earning the wrong one two years early, to look bigger than we are, strikes me as a worse use of a small team's time than earning the right one exactly when a real contract needs it. This is closely related to a question we get from a slightly different angle — not "what certifications do you have" but "what do you actually do with our data" — which is worth answering directly rather than by proxy through a certification logo; we've written separately about what any business owner should ask a vendor, us included, about data privacy.
Isn't this just what a small team can't build?
The fair challenge to this entire essay: maybe none of this is really "deliberate," and it's just a longer way of saying an eight-person team doesn't have the hands to build a mobile app, a public API, and an outbound dialer all at once — with "we don't think it's right yet" doing the work of dressing up a resource constraint as a philosophy.
There's real truth in that, and it would be dishonest to claim team size plays no role — of course it does, and we've written directly about why we've kept the team at eight people rather than growing past it. But team size doesn't explain every item on this list equally well. Outbound calling is the clearest counterexample: we could staff a narrow, single-customer version of it without much difficulty at all — it's not an engineering-capacity problem. We said no anyway, because of what the feature would become once it existed as a general option, not because we couldn't build the first version. If this were purely about hands on deck, that's exactly the kind of small, containable feature we'd have shipped. We didn't, which is the part of the "no" list that's actually a choice rather than a constraint wearing a nicer word.
Why the "no" list matters as much as the "yes" list
None of this is a lack of ambition — if anything it's the opposite. Every feature on this list is something we've said no to specifically so the people building the "yes" list have more time and fewer distractions. A small team that tries to build everything a bigger competitor has ends up with a worse version of all of it. We'd rather be the best answer to a narrower set of questions than a mediocre answer to all of them. It's the same instinct, really, that keeps us from claiming a capability in marketing copy before the product has actually earned it — a "no" stated honestly now is more useful to a prospective customer than a "yes" we'd have to quietly walk back in six months.