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

The Substack Independent Writer

A journalist, essayist, researcher, or domain expert who chose to publish directly to an audience rather than through a publication that owns the relationship. They've been on Substack for 1–4 years. They have a free list and a paid tier. They take the writing seriously. They also think about the business of the writing — open rates, growth, conversion from free to paid — more than they expected to when they started. They are doing something that didn't exist at scale five years ago and they feel the weight and freedom of that simultaneously.

“It happened mid-workflow — they've been on Substack for 18 months.”

The Grammarly Professional Writer

A content writer, communications manager, or marketing professional who writes 3,000–10,000 words per week — blog posts, emails, reports, social copy. They don't need Grammarly to tell them "their vs. there." They use it for the subtle stuff: passive voice creep, sentences that technically make sense but are hard to read, tone shifts that happen when they're tired, and the comma they always second-guess. They've learned to accept some Grammarly suggestions automatically and reject others consistently. They have a relationship with the tool.

“It happened mid-workflow — the writer is finishing a 2,500-word blog post.”

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 Craft Docs Intentional Writer

A product manager, writer, consultant, or knowledge worker who uses Craft as their primary document and note environment because it is the only tool that takes both writing and structure seriously at the same time. They're on Apple devices — Mac and iPhone, usually iPad. They've tried Notion (too database-y), Bear (too simple), Obsidian (too much tinkering), and Apple Notes (not embarrassed about this, just limited). Craft is what they settled on. The fact that it looks good is not superficial to them — environment affects their thinking.

“It happened mid-workflow — they're preparing a strategy document for a quarterly review.”

The Roam Research Networked Thinker

A writer, researcher, or knowledge worker who uses Roam Research as an extension of their thinking. They don't organize notes into folders — they write, link, and let the graph reveal connections. They use daily notes as their entry point, double-bracket references to build a web of ideas, and block references to connect thoughts across pages. They've read about Zettelkasten, spaced repetition, and evergreen notes. They've adopted some of these ideas and adapted others. They are building a thinking system, not a filing system.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about performance degrades with large graphs — search and page loads slow down over time in two weeks.”

The Substack Independent Publisher

A writer, journalist, or subject-matter expert who has turned their expertise into a Substack newsletter with paying subscribers. They are not a blogger — they are running a media business. They write 2–4 times per week, manage a growing list of free and paid subscribers, and check their subscriber metrics more often than they'd admit. They chose Substack because it was the simplest path from "I should write" to "people are paying me to write." They appreciate the simplicity but worry about what happens if the platform changes its terms.

“The shift was quiet.”

The Mintlify Developer Relations Lead

A developer relations lead, technical writer, or engineering manager responsible for their API's documentation. They chose Mintlify because the docs should look as good as the product. They write guides, maintain API references, and obsess over the developer experience from first visit to first API call. They measure success not by page views but by time-to-first-successful-API-call. They've learned that bad documentation is the most expensive support channel a company has.

“The company ships a new API endpoint.”

The GitBook Developer Documentation Lead

A developer advocate, technical writer, or senior engineer at a developer-facing company who owns the documentation. They chose or inherited GitBook because it lowers the friction for engineers to contribute alongside the technical writers. They care about documentation quality in a way most of their colleagues don't — because they're the one who gets the support tickets when the docs are wrong. They know the gap between documentation that exists and documentation that works. They're trying to close it.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about documentation that drifts from reality because nobody owns the update process in two weeks.”

The Readwise Highlight Librarian

A voracious reader — typically a knowledge worker, researcher, writer, or lifelong learner — who realized that reading without retention is expensive entertainment. They started using Readwise because they kept forgetting what they'd read. They now have 8,000–30,000 highlights across Kindle books, web articles, PDFs, and podcasts. They do the daily review. Not every day — most days. The review takes 5 minutes and resurfaces things they've completely forgotten. Occasionally a highlight resurfaces at exactly the right moment for what they're working on. This is not magic. This is why they pay for Readwise.

“It happened mid-workflow — tuesday morning.”

The Todoist GTD Practitioner

A knowledge worker — often a project manager, consultant, writer, or developer — who has read productivity books and tried multiple task managers before settling on Todoist. They've built a system. It works when they use it. The failure mode is not the tool — it's consistency. They believe in GTD or a GTD-adjacent framework. They have projects, labels, and filters set up in a way that feels logical to them and would confuse anyone else. They've rebuilt the system twice.

“It's Sunday evening.”

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 Obsidian PKM Builder

A researcher, writer, software developer, or knowledge worker who has built their second brain in Obsidian and means it. They write in Markdown. They link notes intentionally. They have a vault structure they've iterated on at least twice. They use the graph view occasionally, for the pleasure of seeing their thinking made visible, not because it's the most useful view. They've installed 8–20 plugins. They have strong opinions about the right way to take notes, opinions that evolved over two years of using the wrong way.

“A teammate asked how they managed capture ideas in a format that connects them to related ideas automatically.”

The Dropbox Creative Team Manager

A creative director, design lead, or production manager who manages files for a creative team — designers, photographers, video editors, copywriters. They chose Dropbox because it handles large files (PSD, AI, video) better than Google Drive and because the desktop sync means creatives can work in their native apps without learning a new tool. They are the person who designs the folder structure, enforces naming conventions, and answers the question "where is the latest version of the logo?" at least three times a week.

“The shift was quiet.”

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.”

The Roam Research Networked Thinker

A researcher, academic, writer, or knowledge-intensive professional who uses Roam because it is the only tool that treats the connection between ideas as a first-class object. They write in Daily Notes. They [[bracket]] everything. They have a graph with 3,000–15,000 nodes that they've been building for 2–4 years. They know their graph is their most valuable intellectual asset. They also know that Roam's development has slowed, that the tool has rough edges, and that they've considered migrating to Obsidian or Logseq at least twice. They haven't migrated. The switching cost is partly the data — mostly the habit.

“They're writing an essay about institutional memory.”

The Notion AI Knowledge Worker

A product manager, writer, or operations lead who already uses Notion as their primary workspace and added Notion AI to make their existing workflows faster. They were already in Notion 4–6 hours a day. Notion AI is not a new tool to them — it's a capability inside the tool they already trust. They use it to summarize meeting notes, draft first versions of documents, and ask questions of their existing workspace. The context is already there. The AI can work with it. This is the part that makes Notion AI different from a separate AI tool to them.

“It happened mid-workflow — they've just finished a 90-minute discovery call.”

The Cursor AI-Native Developer

A software developer with 2–10 years of experience who switched to Cursor after a trial period and didn't go back. They've restructured how they code around the assumption that AI is in the loop. They write less boilerplate. They spend more time reviewing and directing than typing. They're faster on unfamiliar codebases than they've ever been. They're also developing opinions about when AI help hurts — about the kinds of errors that look right until they don't.

“The shift was quiet.”

The Salesforce Admin

A business analyst, operations manager, or former power user who became the Salesforce admin because they were the person who understood the data best. They don't write code — they build Flows, create reports, manage permissions, and configure the org to match how the business actually works. They have 3–5 Trailhead certifications and a bookmark folder of Salesforce Help articles they reference weekly. They are simultaneously the most important and most under-appreciated person in the revenue organization.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about flow Builder that's powerful but crashes on complex flows and has limited debugging in two weeks.”

The Supabase Indie Hacker

A solo developer or indie hacker building a SaaS product where Supabase is the entire backend. They chose Supabase because it gives them Postgres, auth, storage, and real-time out of the box — and they can ship their MVP in a weekend instead of a month. They write SQL directly, use Row Level Security because they have to, and treat the Supabase dashboard as their admin panel. They are building a business alone and Supabase is the co-founder that handles the backend.

“The shift was quiet.”

The Prisma ORM Developer

A TypeScript or Node.js backend developer who uses Prisma as their ORM. They chose it because the type safety and auto-generated client make database interactions feel like writing TypeScript, not SQL. They've come to depend on the schema-first workflow — define the schema, generate the client, write queries with full autocomplete. But they've also hit the wall where the ORM can't express what they need, and they have to drop down to raw SQL with a guilty feeling, like they're breaking the abstraction.

“The developer is building a leaderboard feature that requires ranking users by score within time windows, with pagination.”

The Storybook Design System Maintainer

A frontend developer or design technologist who maintains the company's Storybook instance. They write stories for every component, document props with controls, set up visual regression testing, and serve as the bridge between designers and developers. They are the keeper of the design system's technical truth. When a designer asks "does this component exist?" the answer lives in their Storybook. When a developer asks "how do I use this prop?" the answer lives in their Storybook. They are the librarian of the component library.

“The shift was quiet.”

The Hex Collaborative Data Analyst

A data analyst or analytics engineer who uses Hex because it combines everything they used to do across 3–4 separate tools into one collaborative environment. They write SQL to pull data, Python to transform it, and build visualizations and dashboards — all in the same notebook. They share their work as interactive apps that stakeholders can explore without learning SQL. They've replaced Jupyter notebooks, Mode, and Google Sheets with Hex. They are the data person who makes data accessible to people who aren't data people.

“The marketing team asks: "Which campaigns drove the most pipeline last quarter?" The data analyst opens Hex, writes a SQL query to pull campaign data, joins it with pipeline data, and adds a Python cell to calculate attribution.”

The Retool Internal Tools Developer

A full-stack developer or engineering lead tasked with building internal tools — admin dashboards, customer support panels, operations consoles. They chose Retool because writing React apps for internal use felt wasteful, but they still need to write SQL, connect APIs, and handle auth. They are a developer using a low-code tool, which means they appreciate the speed but feel the constraints more acutely than a no-code user would.

“The support team needs a tool to look up customer accounts, view their subscription history, and issue refunds.”

The Amplitude Growth Analyst

A data analyst, growth analyst, or analytics engineer at a Series B–D company who owns Amplitude as the source of truth for product behavior. They are technical enough to write SQL but prefer not to for exploratory analysis. They've mastered the Amplitude chart types. They build dashboards that PMs and executives use but don't fully understand. They're the person in the room who says "let's look at the data" and then actually pulls it up.

“The head of product wants to know which activation milestone most predicts 30-day retention.”

The Resend Transactional Email Developer

A full-stack or backend developer who needs to send transactional emails — password resets, welcome emails, order confirmations, notifications — from their application. They chose Resend because the developer experience felt like it was designed for someone who writes code, not someone who uses a drag-and-drop email builder. They write their email templates in React. The API is simple enough that they memorized it. They are not thinking about email infrastructure. They are thinking about their product.

“The shift was quiet.”

The Notion AI Content Strategist

A content strategist, knowledge manager, or team lead who uses Notion AI as part of their daily workflow inside Notion. They don't use it to write blog posts from scratch — they use it to summarize 45-minute meeting transcripts into action items, turn rough notes into structured documents, answer questions about information buried in the team's wiki, and draft from templates. They've found the sweet spot: AI handles the structure, they handle the thinking.

“The shift was quiet.”

The Cursor AI-Native Developer

A developer who has made Cursor their primary IDE and restructured their workflow around AI-assisted coding. They don't use AI as autocomplete — they use it as a pair programmer, architect, and refactoring partner. They've learned which prompts work, which context windows matter, and when to trust the AI vs. when to verify manually. They are faster than they were in VS Code, but they've also developed new anxieties about code they didn't fully write.

“The shift was quiet.”

The Beehiiv Newsletter Operator

A newsletter founder, media operator, or content entrepreneur who runs a publication with 5,000–100,000 subscribers and treats it as a business with its own P&L, not a side project. They chose Beehiiv because it was built for operators — it has ad network access, referral programs, segmentation, and analytics that treat the newsletter as a product. They think in CAC, LTV, open rate, and click-to-open rate. They have a growth number they're working toward. They may or may not write the newsletter themselves.

“They're in the monthly business review.”

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 Twilio Communications Builder

A backend developer or full-stack engineer who integrates Twilio for transactional SMS, voice calls, or WhatsApp messaging. They're not building a call center — they're adding "send a verification code" or "notify the driver" to an existing product. They understand the API well enough to send messages, but the telecom layer underneath — carrier filtering, number provisioning, regulatory compliance — feels like a different industry entirely. They write code that talks to phones, and they've learned that phones are unreliable in ways servers are not.

“The developer ships a phone verification flow.”

The Supabase Full-Stack Developer

A full-stack developer or indie hacker who uses Supabase as their backend and thinks of it as their database, their auth layer, their file storage, and their API layer at once. They came from Firebase and wanted Postgres. Or they came from setting up their own Postgres and wanted the tooling. Either way they arrived at Supabase and found a backend they could move on from thinking about. They write SQL fluently. They use Row Level Security. They are deeply comfortable in the Supabase dashboard. They have strong feelings about their Supabase tables.

“The shift was quiet.”

The Mintlify Developer Advocate

A developer advocate, DX engineer, or technical founder at a developer-facing company who chose Mintlify because they believed documentation was a product, not a document. They write docs in MDX. Their docs live in a git repository alongside their code. They ship documentation the same way they ship features: PR, review, merge, deploy. They care about the visual quality of their docs because they know developers judge a product by how it feels to learn it — and bad docs signal a bad API. They've recommended Mintlify to three other devrel teams. All three use it now.

“The shift was quiet.”

The Fly.io Container Developer

A backend or full-stack developer who needs to run server-side applications — not just static sites and serverless functions — and wants them deployed globally without managing Kubernetes or paying for managed Kubernetes overhead. They found Fly.io and found a platform that takes a Dockerfile and runs it near users. They `fly deploy`. It works. They have opinions about Fly.io that include real affection and specific frustrations, which is the relationship one has with a platform they actually depend on.

“It happened mid-workflow — they're deploying a Phoenix application — Elixir, with WebSockets and a persistent database connecti.”

The Prisma TypeScript Developer

A backend or full-stack developer working primarily in TypeScript who uses Prisma as their database interface and considers the Prisma schema file to be the authoritative source of truth for their data model. They came from raw SQL, or from another ORM, and found that Prisma's type generation changed how they think about database access — not as a string-query problem but as a typed function call where the compiler tells them when something is wrong before it runs. They have strong feelings about the Prisma schema. Those feelings are mostly fond.

“The shift was quiet.”

The Linear Product Manager

A product manager at a 20–200 person startup who moved to Linear because Jira was too heavy and Notion boards weren't structured enough. They work at the initiative and project level while their engineers work at the issue level. They need to see the forest while the team sees the trees. They love Linear's speed and keyboard shortcuts but struggle to get the strategic views they need without building custom views for every stakeholder meeting.

“It happened mid-workflow — the CEO asks "are we on track for the Q2 launch?" The PM opens Linear, checks 4 projects across 2 teams, counts completed vs.”

The Storybook Frontend Developer

A frontend developer or design systems engineer at a company with a shared component library. Storybook is where they develop components in isolation, document their props and variants, and give designers a place to review and interact with components without pulling a branch. They've set up Storybook, they've configured it, they've written stories for 40–150 components. They're the person who knows where Storybook falls short and stays anyway because the alternative is worse.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about storybook configuration that fights the build tooling when the team's setup is non-standard in two weeks.”

The Figma-to-Code Developer

A frontend or full-stack developer who didn't choose Figma but lives in it three hours a week. They open Figma to inspect designs, grab spacing values, export assets, and try to understand what the designer intended for edge cases that weren't mocked up. They've learned enough about auto-layout to know when a design will be painful to implement. They have opinions about design tokens that the design team doesn't want to hear yet.

“A teammate asked how they managed extract exact spacing, color, and typography values without guessing.”

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 Segment Data Engineer

A data engineer or analytics engineer at a tech company for whom Segment is the central nervous system of the data stack. Every tool the company uses for analytics, marketing, and customer success gets its data through Segment. They did not design the original tracking plan. They inherited it. They've been cleaning it up for eight months. It will take eight more. They are the person who gets paged when an event stops flowing.

“A teammate asked how they managed maintain a clean, consistent event schema that all downstream tools can rely on.”

The Asana Project Coordinator

A project coordinator, program manager, or PMO lead who uses Asana to keep cross-functional projects on track. They don't do the work — they make sure the work gets done. They manage timelines, dependencies, and status updates across teams that each have their own Asana projects, their own workflows, and their own definitions of "on track." They are the person in every meeting who asks "what's the status?" and "who owns this?" — and they need Asana to give them those answers without asking.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about portfolios that show project status but not the why — "at risk" doesn't explain the blocker in two weeks.”

The Kajabi Course Creator

A course creator, coach, consultant, or subject matter expert who chose Kajabi because they wanted one platform instead of five. They have a course, probably a coaching program, possibly a membership community, and they wanted all of it to live together with one checkout, one email system, one analytics dashboard. They pay more for this than they would if they stitched together cheaper tools. They've decided that simplicity and integration are worth the difference. The Kajabi community is genuinely part of their decision — knowing that tens of thousands of other creators are building on the same infrastructure.

“A teammate asked how they managed run a profitable online education business without managing multiple platforms.”

The Fly.io Edge Deployer

A backend developer or DevOps engineer who deploys applications on Fly.io because they need their app running close to users globally — not just served from a CDN, but actually computing at the edge. They've outgrown Heroku's simplicity, don't want AWS's complexity, and find Vercel too opinionated for non-Next.js workloads. Fly.io hits the sweet spot: Docker containers deployed globally with a CLI that feels developer-first. They're comfortable with infrastructure but don't want it to be their full-time job.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about stateful workloads at the edge (databases, volumes) have limitations that aren't always clear until production in two weeks.”

The Sanity Content Architect

A developer or content architect who uses Sanity because they think about content as structured data, not pages. They design content models that serve web, mobile, email, and API consumers from a single source. They've built custom studios, created real-time collaborative editing environments, and used GROQ to query content in ways traditional CMS query languages can't express. They are the architect of the content layer, and they treat content modeling with the same rigor as database schema design.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about customizing the Studio deeply requires significant React knowledge, raising the bar for non-senior developers in two weeks.”