Who builds this, and where we are.

Support is answered by the person who built it.

Not a tier-one queue, not a chatbot, and not a partner. If you open a ticket at 3am during an incident, the reply comes from someone who can read the relevant source file.

That is a genuine advantage over a tiered support organization, and it is also a genuine limitation: we are small. Both of those are true at once and we would rather you knew.

Book 30 minutes

Or mail hello@sondar.dev. No form, no qualification questions, no BDR.

Why trust a closed binary from a company you've never heard of?

Sondar is built in Mountain View, California. The founder, engineering and support are all in the Bay Area.

That's the easy half. The harder half is that we don't publish the engine's source, we have no customers to point you at yet, and you are being asked to run our software against your production telemetry. A security reviewer is right to want more than a location, and "trust us" is not an answer.

So the answer has three parts, and all three are things you can check:

1. Architecture. Sondar runs entirely inside your network. We never receive your telemetry, and there is no activation server for the software to reach — licenses verify offline.
2. What you can check in the artifact. An SBOM per release and a signed release manifest the server checks at boot. We do not offer a source code audit or a penetration test as a standing commitment, and we say so rather than date one.
3. Contract. A written cap on renewal pricing, and capacity checked by your written confirmation, not a meter.

What we are not going to do is pretend that settles it. Those three are mitigations, not proof, and if your procurement process rules out closed-source software from vendors under a certain age, we are not going to talk you out of it — we would rather you spent your afternoon elsewhere than discovered it in week six.