[steve_barham]

I want to test this product, and I'm in a position where I could spend real money on a purchase or subscription to this service in the event that it does what we need.

Unfortunately, as soon as I see that data is sent off-site, I immediately discard this as a product which my organisation can use.

Reasons

1. I am an engineer, working in a highly regulated environment. Regulated environments excel at buying things, or subscribing to things - we have whole teams of people that are delighted to spend money on our behalf. They also tend to have immense amounts of process overhead, whenever you interact with third parties on subjects relating to intellectual property or the confidentiality of client data.

Your assurances on encryption, confidentiality, etc. are irrelevant to me; you could have invented a perfect cryptosystem, but regulations would still prohibit me from exporting data outside of our organisation.

2. I don't want to build reliance on something which is outside of my control. This might be the greatest tool ever built, but if I'm building monitoring systems for production systems, I need to have confidence that they are available, irrespective of your schedule for upgrading / supporting / maintaining your product.

Why should a tool fail, just because the people that built the tool are no longer around?

Short takeaway - my suggestion is that you consider those of us who are not fortunate enough to work in unregulated industries, and produce a self-hosted version of your application (as GitHub do) which can be run on our own infrastructure. There's revenue there which is being ignored. You might feel that centralising your service means that crackers can't steal your tool and use it for free. I would argue that the people that actually care about running this locally are the sort of people that will be paying you, handsomely, for it.

[nivstein]

Hi Steve. These are some valid points you're making. We are currently considering an on-premises solution for precisely this situation you are describing.

[shunter]

This is something we'd run as a small pilot as well, and we do work with SaaS, but any SaaS option we use has to be verified through our internal security department.

This makes quick trials basically impossible for SaaS based services.

An internally hosted solution would let me do a pilot and demonstrate benefits internally. If this becomes an option, I'd give this a try.

[efsavage]

My gut tells me that SaaS is the wrong play here. Offering a hosted option is nice, but half of my projects will flat-out not use any third-party service as part of the dev environment, it all has to be self-hosted, and many of the other half are reluctant to do so. I think you might find more opportunities by offering it as a self-hosted app/appliance.