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

The GitHub Software Engineer

A software engineer with 3–10 years of experience who uses GitHub as the center of their development workflow. They push code, open PRs, review others' PRs, and track issues daily. They've developed strong opinions about what a good PR looks like and suffer quietly through colleagues who don't share them. They know GitHub deeply in some areas — git blame, actions, advanced search — and use the UI for everything else because the CLI is faster until it isn't.

“A teammate asked how they managed ship code with confidence that it's been reviewed and won't break things.”

The GitHub Open Source Maintainer

A developer who maintains one or more open source projects with 500–50,000 stars. They started the project to solve their own problem and now thousands of people depend on it. They review PRs from strangers, answer issues that are really support questions, and write release notes at midnight. They are simultaneously proud of what they've built and exhausted by the weight of other people's expectations. They do this in their spare time, or they're one of the lucky few who gets paid for it.

“A teammate asked how they managed triage issues efficiently — separate bugs from feature requests from support questions.”

The GitLab DevOps Engineer

A DevOps engineer or platform engineer who chose GitLab because the promise of "one tool for the entire DevOps lifecycle" was too compelling to ignore. They manage the CI/CD pipelines, configure the runners, set up the security scanning, and maintain the deployment workflows. They appreciate that everything lives in one place — no integrating GitHub with CircleCI with Snyk with ArgoCD. But they've also learned that "one tool that does everything" sometimes means "one tool that does everything at 80%."

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about cI pipeline configuration in YAML becomes deeply nested and hard to maintain as complexity grows in two weeks.”

The Raycast Workflow Automator

A developer or technical power user on macOS who has made Raycast the nerve center of their computing workflow. They don't just launch apps — they manage clipboard history, control Spotify, search GitHub issues, translate text, convert currencies, and run custom scripts — all from a single keyboard shortcut. They've installed 15–30 extensions and written a few of their own. They are the person whose colleagues watch them work and ask "what is that tool and how do I get it." They measure productivity in keystrokes saved.

“It happened mid-workflow — the developer starts their day.”

The GitLab DevOps Engineer

A DevOps engineer, platform engineer, or senior developer at a company that chose GitLab — often for self-hosting, compliance, or all-in-one platform reasons. They maintain the GitLab instance or the pipeline configurations that all other engineers depend on. They think in pipelines, stages, and artifacts. They've written `.gitlab-ci.yml` files that are 300 lines long and know every YAML key by memory. They've debugged a pipeline failure on a Friday evening. They have strong opinions about GitHub Actions versus GitLab CI that they will share if asked.

“The shift was quiet.”

The Linear Startup Engineer

A software engineer at a startup of 10–100 people who has used Jira and has Opinions. They switched to Linear — or advocated for switching — because it's fast, opinionated, and built for people who care about the work rather than the process around it. They use Linear every day to track their own work, manage issues, and follow the work of their small team. The keyboard shortcuts aren't optional to them — they're the point.

“They're back from a two-day sprint on a difficult bug.”

The Obsidian Plugin Developer

A developer who uses Obsidian for their own notes and started building plugins to scratch their own itch. They now maintain 1–5 plugins with thousands of downloads and a Discord channel full of feature requests. They know the Obsidian API intimately but wish it was better documented. They build in TypeScript, ship through the community plugin store, and handle support in their spare time. They love the Obsidian community but sometimes feel buried by the expectations that come with a popular free plugin.

“Obsidian ships a new version and the developer's most popular plugin breaks.”

The Rippling HR/IT Admin

An HR manager or IT admin — sometimes the same person — at a company large enough that onboarding a new employee involves both an HR workflow and an IT workflow, and small enough that the same person owns both. They chose Rippling because it promised to unify those two workflows into one. When it works — when a new hire's laptop ships, their apps provision, and their payroll is set up in a single flow — it delivers on that promise in a way nothing else does. When it doesn't work, it's complicated in proportion to how much it was supposed to simplify.

“An employee is leaving in two weeks.”

The Clerk Authentication Developer

A full-stack developer at a startup who chose Clerk because building authentication from scratch — login, signup, email verification, OAuth, MFA, session management — is 2 months of work that adds zero product differentiation. They integrate Clerk's pre-built components, customize the flows, and manage users through the dashboard. They appreciate that auth "just works" but they've also hit moments where Clerk's opinionated approach conflicts with their product's specific needs. They are a developer who decided that auth is infrastructure, not a feature worth building themselves.

“The developer is building a new SaaS product.”