Hacker News Reader

> Their pricing is either free or insane with little middle ground. I pleaded with a sales rep - I'm happy to stay on the free features but give you some money for "support" but they wouldn't take my money. Utter madness of a business model to turn down money.

It makes sense to turn down money if the administrative overhead of taking it will cost more. If I have to spend a couple of months negotiating a license/service agreement with your legal department and then chase your AP people for a couple months more to get my invoice paid, the the couple of $K you are willing to pay are not really worth it. And unfortunately that how things really work.

> And unfortunately that how things really work.

Yes, definitely. The cost to build out and maintain any middle ground solution must be unprofitable for the majority of business models.

Ultimately this creates opportunities for down-market service providers. Mid-large companies outsource support to contractors who will provide support for terraform in addition to 20 other things.

A standard problem with dev tools is that they're obsolete before they're ever mature.

What is mean is that by the time NewTool that fills a gap doing X really well catches up with the YZ that older tools have long experience handling, EvenNewerTool handles E better than NewTool does.

I don't have any knowledge of the specifics here, but at first guess I doubt something security-focused would be an exception to that rule.

Hashicorp tools have been industry standard for many many years.

They just used to be free and open source.

Yeah, see almost every "configuration management" tool aside from Ansible that promptly got made irrelevant for the majority of users once containerization hit the scene.

But their money maker isn't really Terraform, it's Vault.

Companies have moved off PagerDuty? To where?

As of very recently, incident.io looks like a very attractive alternative.

I suspect the reason Incident.io is now offering a pager service is selling an incident product is hard.

It is a process efficiency tool (a great one) but is ultimately a luxury. All companies already have some sort of process in place even if it's terrible. But as companies don't have an existing incident vendor they're already spending on, they're also having to educate customers about the business value of the product category at the same time.

However, if you tell me I can replace Pagerduty (which I'm already looking to replace as why am I paying $252/user/year for a PAGER APP!) for an incident tool + pager (even at a higher total) that's a much easier sell. The business value is in the incident response not the tool that sends me a push notification.

I suspect they'll have a lot of success with this.

Same thinking here. We evaluated their incident product and found it sleek but ultimately an unnecessary luxury. With their pager product we will be giving them another try. Personally I won't miss PagerDuty.

Thank you: let us know what you think!

Hello: incident.io CEO here. Thank you for the kind words, it's much appreciated. I countersign your last point around business value being in incident response.

There's truth to this: as with all new product categories, there's some education that needs to go along with the sale, and budget that needs to be found, that doesn't currently exist. On the whole, we haven't found this to be a large challenge so far. Most people look at our product, see a very fair exchange of value, and are happy to pay.

However, that isn't why we built On-call. We built it - along with many other reasons - because it's part of the trifecta that we think you need to do incident response well:

1. A way to alert people that something is wrong 2. A way for them to respond, resolve and learn from the incident 3. A way for them to communicate to their customers about it

We have built all of these respectively in On-call, Response and Status Pages. Consolidating all of these into one cohesive product makes obvious sense, to us at least. We'll see what the market says!

Your product looks super cool! I'd been looking at improving incident management in my org, but SSO being locked behind enterprise service levels makes it a non-starter for me.

Just letting you know that many orgs use SSO that aren't at enterprise scale, the platforms are pretty affordable to obtain (depending on choice). Such a relatively simple to implement and valuable feature commanding the highest price tag and a bevy of features you really don't need acts as a gatekeeper for many of us.

Hey there - co-founder here, thanks for the kind words, glad you like the look of it :)

Could you elaborate on what you're trying to do with SSO? To clarify, you can SSO via Slack on any of our pricing plans (which in turn often SSO's with other providers). Essentially, whatever you SSO with on Slack, will work with incident.io.

If you'd like to use SAML, you can do that too, on our Pro plan and above. The only thing offered exclusively behind our Enterprise plan is SCIM.

Oh, is that so? That's great to hear! You have some outdated documentation, then.

https://help.incident.io/en/articles/6991102-sign-in-with-sa...

> Organisation's on our enterprise plan can enable SSO using SAML to manage access to the incident.io dashboard via an Identity Provider (IdP) like Okta.

firehydrant also recently came out with their pd replacement

At Rootly we also recently released an on-call paging solution and many of our customers have been making the move off of PagerDuty. We’ve made it super easy to migrate and our solution is about 50% less expensive than PD. But really the biggest benefit is probably the consolidation of all incident mgmt into one tool. We’re always happy to demo the tool (no obligations). If you happen to be at KubeCon or SRECon this week, we’ll be there giving live demos as well!

Based on my limited experience building enterprise product in security space. It is deliberately designed this way. You dont want to have variation in ticket size. Investors want to see large ticket size like 100k, but in your case, the margins would not be that great if the price was 30k per year or something, it would be the same effort as a 100k contract in the end of the day with implementation, onboarding, account management and operation support. P0 issue is P0, you want to maintain the same level of service across all customers. When you are an early stage you will have variance in pricing but it has to converge in order to build predictability.

In this particular case, devops or iac or gitops was huge driver for hashicorp. It was synonymous But as market turned as cloud providers mature it is falling out of trend.

As someone who is about to launch my SAAS, what are some of the things you look for, as someone with purchase authority?

What are the positives or negatives you see when dealing with vendors (i.e. what makes you lean towards or against dealing with a vendor)? I'm trying to figure out how I can make the process as easy as possible for exactly people in your position.

Take people out of the sign up flow. Have a form where you can enter the company credit card number and start receiving service.

I'm not the person you've asked, but I'm somebody who has been purchasing SaaS/software for businesses large and small for years. My take:

1. If SSO and other basic modern security features are locked into "Enterprise" pricing tiers then the service is at the bottom of the list (see: https://sso.tax). I'd love to say instant disqualification but too many SaaS companies have it in their head that only wealthy enterprises use SSO, despite SSO platforms being widely available and some quite cheap to acquire and start using.

2. If I need to request a quote to start any kind of service to see what the product is about then I'm not likely to pursue it. Don't make me jump through hoops when I'm just trying to see if a product can fit my needs.

3. If license terms are too complex or easy to violate that's a hard pass. Infrastructure monitoring tools are a great example. The licensing is often per "device" or per monitored metric, and some vendors are very loose with their definition of "device". (Don't use LogicMonitor with k8s unless you like throwing money in the garbage can). Hard lessons learned.

4. If the only details I can find regarding how you secure your product are claims of SOC2 and ISO27001 certification then that's a very likely pass. Those controls are great to have, necessary even, but anyone who has had to work to meet those compliance objectives knows that they're much more about organization controls than they are product security. Give me an idea about how you protect data and whatnot on a security page somewhere, not an attestation that dev and prod are separate and you have logs.

On the side of the positives, outside of not hitting the negative marks, I value ease to work with, responsive and competent support, strong pre and post-sales solutions architecture and support/training (if the product is complex enough to warrant that), and supports SSO. I bring up SSO again because it's a hard requirement for SaaS purchases everywhere I go -- no SSO, no go. Social login is not a substitute and is highly undesired.

Hope this helps.

Thanks for the list!

For SSO, does SAML support clear your bar?

SCIM too.

SAML is fine, no need for OIDC. Someone else mentioned SCIM, which is a highly desired addition, but not a hard requirement for me so long as a public API exists that I can use to automate the user lifecycle.