The Price Engineering of Signals

If you add 250 users to PagerDuty but only send 100 alerts a month, why should you pay over $100,000? Answer: You shouldn’t.

Signals is FireHydrant’s modern on-call product that is a replacement for legacy tools such as PagerDuty or Opsgenie. When we began planning Signals, we not only wanted to build a kickass on-call alternative, but also to reset the standard on how much on-call should cost. We’re going to pull the curtain back on our price engineering exercise for Signals and why it’s possible for us to out-price the Old Guard™ in the market for on-call, without self-inflicting harm on our business, or compromising on quality.

SaaS Margins

FireHydrant is a SaaS business. Businesses like ours are expected to have north of 80% gross margins. For the uninitiated, gross margin is the percentage of revenue that remains after accounting for the cost of goods sold (COGS). It's calculated as (revenue - COGS) ÷ revenue. SaaS businesses are expected to have an 80%+ gross margin because of their relatively low costs to deliver the product once developed.

When building an on-call product, there are several vendors that need to be involved to deploy a functioning product — especially at scale.

Price Engineering

Before a single line of code (and even product spec) for Signals was written, we engineered a price that was designed to solve three core tenants:

1. Significantly less than competing products

2. Reliable without sacrificing quality

3. Build an easy-to-use, forward thinking product

We price engineered in a spreadsheet before committing ourselves to building the product because we believe businesses need far more than “it sends alerts” before committing to a major switch. Price, especially in the era of consolidation, is a major hurdle we need to overcome.

Said another way: The switching cost to FireHydrant needed to be at “no-brainer” level for businesses, paired with a great experience.

Options

Pricing is a game of figuring out which shoe fits the best for your goals. We looked at multiple pricing models before deciding. One pricing strategy we almost went with was “active user” pricing where we would bill a set amount if a user received an alert from us. For months, where a user never received an alert (hooray!), we’d never charge for that amount.

However, AU pricing had low and high end margins we weren’t happy with. We were making too much money on the high-end without providing enough value, which opens us up to revenue churn risk later. On the flip side, we don’t want to give away the farm. It didn’t strike the right balance.

But it also has the same problem incumbents have sliced a different way: User based pricing is too expensive for a product a user may barely touch. Active pricing doesn’t work as well for alerting, because if you can predict who is getting an alert in a month, odds are you don’t need our tool that much. No one has the crystal ball, and pricing needs to be predictable for a customer and vendor. We scrapped it.

Pay for What You Use

After experimenting with multiple pricing models, we landed on a true usage based pricing model for Signals. We asked our customers to send us their current volumes of alerts from their current provider (which we provided a script to run), plugged in the numbers, and we saw the margins we wanted while offering a no-brainer “yeah let’s switch” level of cost-saving.

Once we had proven to ourselves that we could offer insanely good prices without damaging our gross margins as a business, it also meant we had created the constraints for our vendor selection and architecture of Signals.

Architecture and Price

All too often I think startups build software and ask questions later when it comes to the cost of goods sold. On-call products are a high-volume, no-fail system — and throwing money at the problem isn’t an option for a startup. We had to be smart.

Here’s the list of the vendors we selected to build Signals with our pricing constraints defined:

• Google Cloud: CloudSQL (Postgres) and GCS (for Configuration storage)

• Temporal Cloud

• Twilio (w/ Sendgrid & Whatsapp) (primary)

• Expo (mobile applications w/ React Native)

We explained how we built Signals (as we were doing it, in-fact) and our price engineering paired with the architecture decisions had panned out exactly how we thought it would over a year later.

Because Signals runs on usage-based technology, it makes it easy for us to offer modern on-call at a price that we feel is only fair. If you add 250 users to PagerDuty but only send 100 alerts a month, why should you pay over $100,000? Answer: You shouldn’t.

APNS/FCM Doesn’t Count

A significant portion of the alerts we send never count towards a customer’s quota, either. Apple and Google don’t charge us a cent to send a push notification, so why should we bill you for it? Every customer still has notification redundancy with SMS and Voice so our COGS is still over 80% despite the Temporal/Google costs we incur to send a push notification. It’s so insignificant we’d rather offer the savings back to the customer.

Replacing Legacy On-Call: More Than Just a Cheaper Bill

It turns out when you build a better on-call product and charge a sane price for it, people notice.

Teams switching from PagerDuty to FireHydrant aren’t just saving 50% (on average) — they’re also getting a much better deal in terms of experience. Signals doesn’t live in a silo — it’s part of a platform where alerting flows directly into incident response. No more bouncing between tools or duct-taping workflows together. Everything lives in one place, which means your teams respond faster, with more context, and a lot less chaos.

It also means on-call isn’t limited to a handful of burned-out engineers anymore. With FireHydrant, teams can bring their whole org on-call — spreading alerts more evenly across engineering and giving the rest of the business (Legal, Marketing, Success, C-Suite, you name it) the visibility they need when things go sideways.

Reality Check: Alerting Is a Commodity

We believe that the true value of incident management software is felt during the incident and that an expensive smoke detector is no longer acceptable. Before we built the product, we fully understood that the value of Signals wouldn’t be the alert we sent, but what the alert led to: our seriously-powerful incident management platform.

The early price engineering we did for Signals led to an amazing product that thousands of engineers have switched to for their alerting (and incident management) needs. And maybe you’ll be the next one!

Ready to make the switch? Show us your PagerDuty contract, and we'll give you (at least) 50% off what you're currently paying when you switch to Signals. Learn more here.