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, either because we don't think it's right for our customers or because it isn't right yet.
Most companies only publish the "yes" list. Feature pages, comparison charts, and launch posts all describe what exists. That leaves buyers guessing about the gaps, and often discovering them after they've signed up.
We'd rather write the second list down honestly. These are the features we've deliberately not built in Aiva Chat, the AI receptionist we make for small businesses: an outbound dialer without guardrails, video calls, a mobile app, a public API, and certifications chased ahead of real need. For each, we explain the reasoning, what we offer instead, and what would change our mind.
There's an obvious objection, that this is a small team dressing up its limits as philosophy, and it's partly true; we deal with it further down. If you're evaluating vendors right now, the last two sections on judging a vendor's gaps are written for you.
We've done the reverse before, cataloguing the features that almost didn't make the yes list. This is the companion piece.
What a deliberate "no" list is
A deliberate "no" is a feature a team could build, has been asked for, and has chosen not to build, for now or for good. It's different from a backlog item nobody has gotten to. The decision is made, and the reasons are stated.
For a small company, the "no" list does real work. Every feature built has to be maintained, documented, supported, and kept working as everything around it changes. Saying no to one thing is how the things on the "yes" list get the attention they need.
For buyers, a published "no" list is useful in a different way. It tells you where the product's edges are before you hit them, and it tells you something about how the company makes decisions. A vendor that can explain why it hasn't built something is usually a vendor that thinks carefully about what it has built.
Here's ours, item by item.
The current "no" list: outbound without guardrails, video calls, a mobile app, a public API, and chasing certifications ahead of an actual customer need for them.
The features on our "no" list
No outbound calling without guardrails
Outbound is one of the most obvious things to want: calling people back, following up on leads, or letting customers know something is ready. Aiva Chat does place outbound calls, including bulk campaigns from a CSV or your contacts. What we said no to is shipping that without limits.
Outbound AI voice at scale is how this category earns its reputation for robocalls and spam, the same unsolicited-commercial-communication problem TRAI has built consumer protections against on the human-telemarketing side. So every campaign skips numbers on your do-not-contact list, only dials inside an 8 AM to 9 PM window, and runs content safety checks, and STOP replies are honored on SMS. Those aren't settings you can switch off to go faster.
No video calls
It's a reasonable ask, especially when competitors mention it. We keep asking what problem video would solve that voice, chat, and SMS don't already solve for answering questions and booking appointments. So far, we haven't found one.
Video adds real infrastructure and bandwidth complexity, and none of it improves the answer to "what are your hours?" or "do you have a slot Friday?" We'll build it the day a recurring customer need shows up that the other channels structurally can't handle.
No mobile app, yet
Owners manage Aiva Chat from a browser. There's no downloaded app, and we know that reads as a gap.
The calculation: an app is two more platforms to build, ship, and support indefinitely, for tasks most owners do a few times a week. The web dashboard fits that cadence. We've made the fuller case, including what would change our mind, in why Aiva Chat doesn't have a mobile app.
No public API, yet
Aiva Chat connects to Google Calendar, HubSpot, and your own Stripe account through built-in integrations, plus signed webhooks and custom actions that call your own systems. What we haven't shipped is a public, self-serve API anyone can build against.
A public API is a permanent commitment: versioning, documentation, backward compatibility, and a support burden that doesn't shrink. We'll build it when we're confident we can support it for years. The longer reasoning is in why Aiva Chat doesn't have a public API yet.
No certifications ahead of need
We do the security and privacy work real customers need, when they need it, rather than collecting enterprise logos speculatively. Aiva Chat doesn't currently hold formal enterprise compliance certifications, and we won't imply otherwise.
Certifications done properly are slow and expensive. Earning the wrong one two years early, to look bigger than we are, is a worse use of a small, bootstrapped team's time than earning the right one when a real contract needs it. A better question for any vendor is what they do with your data, and we've written about what to ask an AI phone vendor about data privacy, us included.
How we decide what to say no to
We don't have a formal scoring system, but the same questions come up every time.
Step 1: Name the recurring problem
Is there a real problem, raised repeatedly by the businesses we serve, that this feature solves? A competitor having it doesn't count. One loud request doesn't either.
Step 2: Check whether existing channels already solve it
If voice, website chat, SMS, webhooks, or custom actions already cover the job, a new feature adds maintenance without adding much value.
Step 3: Count the permanent cost
Some features are cheap to build and expensive to keep. Public APIs and native apps are the clearest examples. We count support, documentation, and compatibility, not just build time.
Step 4: Ask what it becomes in the wrong hands
For features like outbound calling, building it is the easy part. The harder question is what the feature turns into once it's a self-serve checkbox, and whether we'd trust everyone using it to hold the line.
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.
Our "no" list at a glance
| Asked-for feature | What Aiva Chat offers instead | Why not (yet) | What would change our mind |
|---|---|---|---|
| Unguarded outbound dialer | Campaigns with do-not-contact checks, calling hours, safety checks | Invites robocall-style misuse | A model that doesn't tempt misuse at scale |
| Video calls | Voice, website chat (text and voice), SMS | No recurring problem it solves | A need the other channels can't handle |
| Mobile app | Web dashboard on any device | Two more platforms for occasional tasks | Truly time-sensitive alerts, or the browser getting in the way |
| Public API | Built-in integrations, signed webhook events, custom actions | Permanent versioning and support burden | A stable internal data model |
| Certifications ahead of need | Security and privacy work done for real requirements | Slow and costly to earn speculatively | A real customer contract that requires one |
The middle column matters most for buyers. Most "missing" features have a workable route today. A business that wants leads in a CRM Aiva Chat doesn't integrate with natively can usually send them there through a signed webhook. An owner who wants to check calls on the go can open the dashboard in a phone browser.
Where the alternative is genuinely worse, we'd rather say so. Aiva Chat can book video or phone appointments, with a fixed meeting link you supply (a Zoom room, for example) sent in the confirmation, but it doesn't take calls by video itself. If your business truly needs that, or a certification we don't have, Aiva Chat isn't the right fit today, and it's better to know that before the trial than after.
Isn't this just what a small team can't build?
The fair challenge: maybe none of this is deliberate, and "we don't think it's right yet" is a resource constraint wearing a nicer outfit.
There's truth in that. We're a small, early-stage team, and that shapes what we take on. It would be dishonest to claim otherwise.
But team size doesn't explain every item equally. Outbound calling is the clearest counterexample: we built it, so capacity wasn't the issue. Dropping the do-not-contact checks and calling-hour limits would have been less work, not more. We kept them because of what the feature would become without them. If this were purely about hands on deck, the unguarded version is exactly the shortcut we'd have shipped.
Mistakes buyers make when comparing feature lists
Counting checkboxes instead of jobs
A longer feature list doesn't mean a better fit. Ten features you never use cost you nothing, but one missing capability you rely on daily costs a lot. Compare products against the jobs you need done.
Assuming a missing integration means no connection
Many tools accept a webhook URL even without a native integration. Ask how a product would connect to your system before ruling it out.
Taking roadmap promises at face value
"Coming soon" is not a feature. Buy based on what works today, and treat anything else as a bonus if it arrives.
Ignoring how a vendor talks about limits
A vendor that can't name a single thing its product doesn't do is either not thinking carefully or not being straight with you. Both are warning signs.
Skipping the trial with real work
The fastest way to find a dealbreaker is to run the product on your own calls. Our guide to what to test during a free trial lists the checks worth doing.
How to evaluate a vendor's gaps
- Ask for the "no" list directly. A thoughtful vendor will have one and explain it.
- Ask what the workaround is. Most gaps have one, and its quality matters.
- Ask what would change their mind. Specific answers suggest real reasoning.
- Check whether gaps affect your daily work. Edge-case gaps matter less than core-workflow gaps.
- Verify claims during a trial. Test the features you depend on, not the ones in the demo.
- Prefer honest limits over vague promises. They're easier to plan around.
Conclusion
The judgement behind every item here is the same: a small team that tries to match a bigger competitor feature for feature ends up with a worse version of all of it. We'd rather do fewer things properly and tell you plainly where the edges are.
For you, the practical question is whether any of these gaps sits in your daily work. A missing mobile app rarely matters to an owner who checks calls a few times a week. A missing certification can rule Aiva Chat out entirely for a business whose contracts require one, and it's far better to learn that from this page than three weeks into a trial.
It's the same instinct that keeps us from claiming a capability before the product has earned it. If something on the list is a dealbreaker, we'd rather you know now.
Ready to see what's on the "yes" list?
If nothing above ruled Aiva Chat out, the next check is your own calls. Put your hours and services into a trial assistant, connect the calendar, and push it toward the edges this post describes, such as asking for something it should hand to a person.
You can call +1 (970) 972-0974 to hear it first, or compare plans and limits. Then start your 14-day free trial with no card, or book a demo and ask us directly about anything on the "no" list that worries you.
Posts from the people building Aiva Chat in Rajkot — how the product works, what we have learned building it, and guides for getting the most out of an AI receptionist.