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

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 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 Sentry Error Wrangler

A developer — usually mid-level to senior — who has become the de facto owner of error tracking on their team. They set up Sentry, configured the alerts, and now they're the person who triages the error feed every morning. They know the difference between a real bug and a noisy exception. They've learned to read stack traces the way a doctor reads X-rays — quickly, looking for the thing that's actually wrong. They carry the mental burden of knowing exactly how many errors are happening in production at any given moment.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about grouping algorithms that split one bug into multiple issues or merge different bugs into one in two weeks.”

The Sentry Error Monitor

A backend, frontend, or full-stack developer at a product company for whom Sentry is the first place they look when something goes wrong in production. They didn't set Sentry up — it was already there when they joined — but they've learned to read its output. They've been paged because of a Sentry alert. They've traced a production incident back to a specific line using Sentry's stack traces. They've also spent 40 minutes investigating a Sentry error that turned out to be a bot making malformed requests. They've learned to filter.

“It happened mid-workflow — it's Wednesday afternoon.”

The Cal.com Scheduling Power User

A consultant, agency owner, or team lead who uses Cal.com because Calendly was too simple for their scheduling needs. They manage round-robin scheduling for a team, paid consultation bookings, multi-timezone availability, and custom booking forms that collect information before the meeting. They chose Cal.com because it's open-source, self-hostable, and extensible in ways Calendly's paid tiers can't match. They are the scheduling architect for their team.

“It happened mid-workflow — a consulting agency needs different scheduling for three scenarios: free 15-minute discovery calls (routed to available consultant), paid 60-minute strategy sessions (It happened mid-workflow — a consulting agency needs different scheduling for three scenarios: free 15-minute discovery calls (routed to available consultant), paid 60-minute strategy sessions (The aha moment happened the first time they used Cal.”

The Grammarly Professional Writer

A professional writer, business analyst, marketer, or non-native English speaker for whom written communication is central to their professional credibility. They use Grammarly not because they can't write — they can — but because they write quickly and under pressure, and the gap between their intent and their output sometimes closes imperfectly. Grammarly is the layer that catches what their brain skips. For non-native speakers especially, it's the difference between writing with confidence and writing with anxiety.

“It happened mid-workflow — they're writing a proposal to a new enterprise client.”

The Height Engineering Team Lead

An engineering team lead or technical PM at a company of 20–150 people who evaluated Linear and wanted more — more project hierarchy, more cross-functional visibility, more flexibility for non-engineering teams to work alongside engineering in the same tool. They chose Height. They're building their system in it. They like that it feels like a tool built by people who understand engineering workflows, not a project management tool that engineering is expected to tolerate. They're still learning the edges of it.

“It happened mid-workflow — sprint planning is Monday.”

The Craft Personal Document Creator

A professional in the Apple ecosystem — Mac, iPad, iPhone — who uses Craft for everything from meeting notes to project proposals to personal journals. They chose Craft because it feels native to macOS and iOS in a way that Notion and Google Docs don't. They value beautiful typography, smooth block-based editing, and the ability to work offline on an airplane and sync when they land. They are a writer who cares about the writing environment, not just the output.

“The shift was quiet.”

The Wix First-Time Website Owner

A small business owner, freelancer, event organizer, or individual who needed a website and chose Wix because they wanted to design it themselves. They are not technical. They have no interest in becoming technical. They evaluated Squarespace and liked Wix's drag-and-drop freedom more — the ability to place anything anywhere without template constraints. They've built a website they're proud of. It has some inconsistencies that they can't see but a designer would notice immediately. This is fine. The website does what they need it to do.

“The shift was quiet.”

The Pendo Product Manager

A product manager at a B2B SaaS company who owns feature adoption and in-app user education. They have engineering bandwidth for product, not for tooltips. Pendo lets them publish in-app guides without a ticket. They've also realized that Pendo's analytics tell them something different from their product analytics tool — not better, different. Pendo tells them where users are, not just what they do.

“A major new feature shipped three weeks ago.”

The Contentful Headless CMS Developer

A frontend or full-stack developer who integrates Contentful as the content backend for a website, app, or digital experience. They set up the content models, build the delivery layer, and create the bridge between what content editors want to publish and what the frontend can render. They appreciate the API-first approach but have learned that "headless" means they're responsible for everything the CMS traditionally handled — routing, preview, caching, image optimization. They build the head.

“A marketing team wants to launch a new campaign page type.”