What is actually implemented?
Can you see the feature working in the product today, or is it a roadmap item, a placeholder, or a marketing claim? Test it yourself.
Compare
Evaluate Automix with neutral criteria — not a fabricated scorecard.
This page does not present a feature-by-feature comparison table with competitor names and checkmarks. That format is easy to rig and often relies on unverified or outdated competitor claims. Instead, here is a neutral evaluation framework you can apply to Automix and any alternative — so you can make your own assessment with your own evidence.
No competitor scorecardNo named-competitor comparison table with checkmarks, ratings, or verdicts.
No unverified claimsNo statements about what other platforms can or cannot do, unless verifiable from their own public documentation.
Source-observed self-assessmentOur own answers are based on what the source code and workspace show, not on marketing aspiration.
Why not a comparison table
Most comparison tables are marketing, not analysis.
A table that lists your product next to competitors with green checks and red crosses is designed to make you win. It is not designed to help the buyer decide.
Common problems with vendor-produced comparison tables: competitor features are often mischaracterised or outdated; the comparison dimensions are chosen to favour the vendor's strengths; checkmarks and crosses are assigned by the vendor, not by testing; and the table rarely accounts for configuration-dependent features — where a platform may have the capability but require setup that the vendor's marketing ignores.
Instead of producing that kind of table, this page offers a set of neutral evaluation criteria. Each criterion is a question you can ask of Automix and any alternative. The answers are yours to determine — by testing the product, reading the documentation, and evaluating what is actually implemented versus what is marketed.
Evaluation criteria
Eight questions to ask any platform.
Apply these to Automix and to any alternative you are considering. The honest answer to each is more useful than a vendor's checkmark.
What requires your configuration?
Which features need your own provider accounts, credentials, or setup to function? A feature that exists but is inert without your setup is different from one that works out of the box.
What is the human review boundary?
Where does the platform require or allow human approval before consequential actions — sending campaigns, processing payments, producing professional outputs? Is the boundary visible and auditable?
Who controls your data?
Do you bring your own provider accounts and credentials, or does the platform host and manage them? What is the tenant isolation model? Where does your data live?
What provider states are distinguished?
Does the platform treat queued, accepted, delivered, read, failed, unconfigured, and unavailable as distinct states — or does it collapse them into a single delivered/undelivered binary?
What is the status labelling model?
Are products and features labelled with honest status — Available, Preview, Coming soon, Pending — or is everything presented as live regardless of actual state?
Is the pricing real?
Can you actually purchase the plan shown, or is the pricing page a placeholder with no checkout? Are the tiers backed by a billing system, or are they marketing decoration?
Is the social proof verifiable?
Are the testimonials, case studies, and metrics based on consented, measured, and verifiable engagements — or are they fabricated, estimated, or attributed to unnamed personas?
How Automix answers
Our honest answers to the same criteria.
We apply these criteria to ourselves. Here is where Automix stands today — based on what the source code and workspace actually show, not on marketing aspiration.
- What is actually implemented? Source paths exist for Wavy messaging, inbox, contacts, campaigns, rules, Copilot, payments, and provider receipts. Their deployment and provider-dependent behavior remain subject to the release gate. Other specialists remain previews or repository pending.
- What requires configuration? Meta Cloud API, the optional QR bridge, AI, UPI/Razorpay/PhonePe/Stripe, and Airtable contact sync rely on server-side provider settings. A complete self-service per-workspace credential flow is not implemented.
- What is the human review boundary? The campaign API restricts launch by role, template status, and draft state; Copilot replies are returned as drafts. Payment confirmation exists in the UI, but complete backend approval and audit enforcement are not claimed.
- Who controls your data? Workspace-scoped records and authorization checks exist across many paths, but the current audit found remaining tenant-isolation and observability work. Complete or independently audited isolation is not claimed.
- What provider states are distinguished? Source-observed: the Wavy codebase distinguishes queued, accepted, delivered, read, failed, and unconfigured as distinct states. This is visible in the inbox and campaign reporting.
- What is the status labelling model? Every specialist in the active registry carries an explicit status. Wavy is Available, Socie is repository pending, and the others are Coming soon. A preview page is not treated as a working backend.
- Is the pricing real? Final public plans and purchase are not open. Earlier tier values are placeholder source data, not approved commercial terms. Provider checkout paths exist but have not passed the full public-purchase release gate.
- Is the social proof verifiable? No case studies, testimonials, or metrics are published. The case studies page states that none meet the evidence standard for publication.
Questions
About this comparison approach.
Why don't you list specific competitors?
Because a vendor-produced comparison table with named competitors is inherently biased. The vendor chooses the dimensions, assigns the checkmarks, and controls the framing. Instead, we provide neutral criteria that you can apply to any platform — including ours — and determine the answers yourself through testing and documentation.
Are you saying competitors are worse?
No. We are not making any claim about what competitors can or cannot do. We are saying that the right way to compare platforms is to test them against neutral criteria, not to rely on a marketing scorecard produced by one of the vendors.
Can I use these criteria to compare Automix to a specific alternative?
Yes. That is the intent. Take these eight questions, apply them to Automix by exploring Wavy and reviewing the API reference, and apply them to any alternative by testing that product and reading its documentation. Your own evidence is more reliable than our table or theirs.
Will you add a feature comparison table in the future?
Only if it can be produced with verifiable, up-to-date information from each competitor's own public documentation, with clear labelling of configuration-dependent features, and with an honest representation of where Automix does and does not measure up. A rigged table will not appear here.
Compare by testing, not by trusting a scorecard.
Explore Wavy's public experience and apply these criteria to Automix and any alternative. When deployed, the backend exposes a generated OpenAPI reference for technical inspection.