Who actually uses these products,
and what made them stay.

The Datadog SRE

A site reliability engineer or platform engineer at a company with a production system that people depend on. Datadog is their window into that system. They've built dashboards that tell the story of what's happening in production. They've written monitors that page them when something goes wrong. They've been paged at 2am by monitors they wrote themselves and have opinions about that experience. They are better at Datadog than most people at their company and still feel like they're using 30% of what it can do.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about alert fatigue from monitors that fire on normal variance — the cry-wolf problem in two weeks.”

The Datadog SRE

A site reliability engineer or DevOps engineer responsible for the uptime and performance of production systems. They chose Datadog because it combines metrics, traces, logs, and alerts in one place — but now they're paying for all of it and the bill is terrifying. They've built dashboards that are beautiful, alerts that are precise, and runbooks that nobody reads. They are the person who gets paged at 3 AM and needs to determine in 90 seconds whether this is a real incident or a flapping alert.

“The shift was quiet.”

The PagerDuty On-Call Engineer

A software engineer or site reliability engineer who is on a rotating on-call schedule and whose relationship with PagerDuty is defined by the moments it wakes them up. They've been paged at 3am. They've resolved incidents from their phone in bed. They've also been paged for something that wasn't an incident — a flaky alert, a threshold set too low, a monitoring rule that was never updated after the system changed. Every false positive erodes their trust in the alert and their willingness to respond with full urgency next time. They manage this tension carefully.

“The shift was quiet.”

The Cal.com Developer Scheduler

A developer, indie maker, or privacy-conscious professional who uses Cal.com because they either self-host it or value that they can. They were on Calendly and either hit a pricing ceiling, wanted customization Calendly doesn't allow, or made a deliberate decision about data ownership. Cal.com is open source. They can read the code. They can modify it if they need to. The fact that this is possible — even if they never do it — matters to them in a way that influences their tooling choices.

“It happened mid-workflow — they're building a product that includes embedded scheduling — customers can book time with their su.”

The Logseq Local-First Knowledge Builder

A researcher, developer, writer, or privacy-conscious knowledge worker who chose Logseq because their notes are plain `.md` files in a folder they control — not in a proprietary database, not in someone else's cloud. They care about data ownership in a specific way: not paranoia, but principle. They've watched tools sunset, pricing change, and export options degrade. Their Logseq graph syncs to iCloud or a private git repository. It will exist regardless of Logseq's future. They've also genuinely internalized the outliner-first paradigm. They think in bullets that can be linked and referenced anywhere else in the graph.

“They're synthesizing research for a paper.”