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

The 1Password Security-Conscious Admin

An IT manager, security engineer, or technically-minded operations lead at a company of 20–500 people who adopted 1Password for Teams and now manages credential hygiene across an organization. They have strong feelings about credential sharing via Slack. They have seen what happens when a shared account has no owner and the person who knew the password leaves. They've spent time cleaning up credential sprawl left by a company that grew faster than its security practices. They run 1Password now. It is imperfect but it is dramatically better than what came before.

The Airtable Ops Manager

An operations manager, program manager, or department lead at a 20–200 person company who discovered that spreadsheets couldn't hold what they needed to track anymore. They built something in Airtable that their team actually uses. They are not a developer, but they've learned to think like one — tables, relations, fields. They are simultaneously proud of what they've built and anxious about what happens when it breaks.

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 Apollo SDR

A sales development rep or account executive at a B2B company of 20–300 people who runs outbound prospecting as a core job function. Apollo is their prospecting database, their sequencing engine, and their activity tracker. They use it every day. They've built sequences that work and sequences that don't, and they've learned the difference by watching reply rates. They're not sentimental about approaches that aren't working. They test, they iterate, they move on.

The Arc Browser Power User

A developer, designer, or technical knowledge worker who switched to Arc and reorganized their browser-based work around Spaces and Folders instead of horizontal tab strips. They had 40 tabs open in Chrome on a normal day. They were managing them by scrolling and guilt. Arc replaced the tab strip with something structural. They have opinions about it that they've refined over 8 months of use. The opinion is: it's better. The caveat is: it requires learning a new mental model that takes 3 weeks to stop fighting.

The Asana Agency Project Manager

A project manager at a digital or creative agency juggling 6–12 active client projects at various stages simultaneously. Asana is their external brain — it holds everything they can't hold in their head, which is most of it. They've been through the Asana certification. They've built the templates. They've trained the team. They're still fighting the battle of getting everyone to actually update their tasks.

The Attio Revenue Operator

A revenue ops manager, head of sales, or technical founder at a startup of 10–100 people who evaluated the legacy CRMs and decided not to inherit their constraints. They chose Attio because it's data-model-first — they can define what a record means in their business rather than forcing their process into Salesforce's assumptions. They are building their CRM from scratch. This is a significant investment. They are aware of that and have decided it's worth it.

The Basecamp Small Agency Owner

A small agency owner, studio founder, or remote team lead with 3–20 people who chose Basecamp because they were tired of configuring project management tools. Basecamp's opinionated structure — message boards, to-dos, schedules, docs, campfire — is not a limitation to them. It's the point. They didn't want to design a system. They wanted to use one. They've been on Basecamp for 2–6 years. They've recommended it to other agency owners who are drowning in Notion setups and Jira configurations. Some of them listened.

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.

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.

The Calendly High-Volume Scheduler

A consultant, account executive, advisor, or service professional for whom scheduling external meetings is a daily operational task. They use Calendly because they calculated — consciously or not — that 20 minutes per meeting of back-and-forth email was adding up to hours per week. They now send a link. They feel slightly awkward about it the first time with each new contact. The other person always thanks them for it.

The Canva Non-Designer

A marketing coordinator, social media manager, small business owner, or teacher who is responsible for creating visual content and has no design training. They discovered Canva and it changed what was possible for them. They can now make things that look professional without calling a designer or spending three hours in PowerPoint. They are faster than they were. They are not as good as an actual designer. They know this and they've made peace with it.

The Clay Growth Operator

A growth lead, revenue ops manager, or technical sales operator who found Clay and spent two weeks rebuilding their entire outbound motion around it. They were already combining data from LinkedIn, Apollo, Clearbit, and spreadsheets manually — a process that was slow, inconsistent, and unscalable. Clay collapsed that into one workflow. They now build outbound lists in hours that previously took weeks. They are evangelical about it. They're also aware that most people at their company don't understand what they've built.

The Clerk Authentication Developer

A full-stack developer or indie hacker building a SaaS product who has decided that authentication is not a competitive advantage and has no interest in building it. They chose Clerk because it ships the full auth experience — sign in, sign up, user profile, MFA, social providers, and organization management — as components they can drop in and style to match their product. They were building on NextJS and Clerk was the obvious answer. It took them four hours to integrate. They've never looked back and have never thought about auth again unless a customer asked for a feature.

The ClickUp Everything-App Operator

An operations manager, department head, or systems-minded project lead who chose ClickUp because they wanted one tool that could replace three. They were right that ClickUp could do this. They underestimated how long configuration would take. They have built a system that works well for them and is difficult to explain to new team members. They are aware that ClickUp's reputation for complexity is earned. They are also aware that the people who complain about it most haven't learned the difference between what's in the tool and what they actually need to turn on.

The Coda Ops and Strategy Builder

An operations manager, strategy lead, or chief of staff who discovered that the documents they needed didn't fit neatly into either a Google Doc or a spreadsheet. They found Coda and spent two weeks building something they couldn't have built elsewhere — a doc with a database inside it, buttons that trigger actions, and views that update automatically. They are evangelical about it in proportion to how many people they've tried to explain it to. It's hard to explain until you see it.

The Contentful Content Manager

A content manager, digital editor, or marketing manager at a company with a developer-built Contentful implementation. They publish product pages, blog posts, campaign content, and documentation through Contentful's web interface. They did not design the content model — a developer did. They live inside that model every day and have a detailed understanding of which fields do what and which ones are a mystery. They are not a developer but they've learned to think in content types.

The ConvertKit Creator Monetizer

An online creator — YouTuber, course seller, coach, author, or educator — who has built an email list and uses ConvertKit to turn that audience into revenue. They chose ConvertKit because it was built for creators: the tagging system makes sense for how creators think about audience segments, the Creator Pro features align with their actual business model, and the community of ConvertKit users is full of people doing exactly what they're doing. They are building a creator business, not just an email list. They see their subscribers as an audience, not a database.

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.

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

The Deel Global HR Manager

An HR manager, people ops lead, or COO at a company of 20–200 people that has hired internationally — contractors in one country, full-time employees in another. Before Deel, this involved a law firm, a local accountant, a foreign entity, and a spreadsheet of exchange rates. Deel collapsed that. They can now hire in a new country in days instead of months. They are not naive about the complexity they're offloading — they understand that Deel is doing what they used to do badly.

The Descript Podcast Producer

A podcast producer, video content creator, or marketing team member who discovered Descript and now finds traditional timeline editing alienating. They edit by editing the transcript. They remove filler words in bulk. They record pickups without re-recording the whole segment. They've explained Descript to other editors and watched the same expression — skepticism that becomes revelation — every time. They are not a professional audio engineer. They produce content that sounds professional. That gap is Descript.

The DocuSign Contracts Sender

A sales rep, account executive, or operations manager who sends 5–30 contracts per month for electronic signature. DocuSign is not their job — it's the thing they do at the end of their job. They want contracts signed as fast as possible because a signed contract is a closed deal or a cleared obligation. They did not design the templates they use. They sometimes modify them in ways that create problems they don't discover until someone calls.

The Dovetail UX Researcher

A UX researcher or research ops manager at a company with a growing research practice. They've conducted enough studies that the insights are now a problem: they exist in documents, recordings, sticky notes, and people's memories. Dovetail is where they're consolidating that. They tag, they theme, they surface insights in a way that teams can find without having to ask a researcher. They believe the research repository is the infrastructure of a research-driven company. They're building it while also running new studies. It is a lot.

The Drata Compliance Manager

A security manager, compliance lead, or IT director at a SaaS company of 50–500 people who is responsible for achieving and maintaining SOC 2 Type II certification. Before Drata, this was a spreadsheet, a shared drive, and a six-month audit season that consumed 30% of their capacity. Drata made it something they can manage in the background with periodic attention spikes. They're not relaxed about compliance — that would be naive — but they're less reactive. That's the win.

The Dropbox Cross-Functional File Sharer

A project manager, creative director, or department lead at a company that produces large files — design assets, video, documents, presentations — that need to move between internal teams and external partners. They use Dropbox because it works for people who aren't on their company's Google or Microsoft stack. It's the lowest-friction way to get a 2GB folder to a client or vendor who uses a PC, a Mac, or a Linux box, and doesn't have access to their internal SharePoint.

The Excel Financial Analyst

A financial analyst at a corporation, investment firm, or consultancy for whom Excel is not software — it is the medium of thought. They spend 5–7 hours a day inside spreadsheets. They build models that other people are afraid to open. They have keyboard shortcuts memorized that the rest of the company doesn't know exist. They've rescued a broken model the night before a board presentation. They have opinions about Excel that they share without being asked.

The FigJam Product Team Facilitator

A product manager, design lead, or team facilitator at a product company who uses FigJam for team whiteboarding because their team already lives in Figma. They chose FigJam over Miro because the context switch is lower — design references, wireframes, and working files can be linked or embedded directly from Figma. They run planning sessions, retrospectives, decision workshops, and design crits on FigJam. Their team knows how to use it. This matters more than they expected it to.

The Figma Dev Mode Engineer

A frontend engineer at a product company who implements UI from Figma designs. Dev Mode is their interface to the design file — the layer of Figma that was built for them rather than around them. They use it to extract measurements, inspect component properties, copy CSS values, and verify that what they've built matches what was designed. They have strong feelings about when Dev Mode helps and when it's still faster to ask the designer. Those feelings are specific.

The Figma Product Designer

A mid-to-senior product designer at a tech company with 3–8 years of experience. Figma is where they spend most of their working day — from rough explorations to polished specs. They work across a shared team library and collaborate with PMs in comments and engineers in dev mode. They are fast, opinionated about component architecture, and quietly frustrated by how the tools around Figma still slow everything down.

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.

The Framer Interactive Designer

A product designer or creative developer who uses Framer for either high-fidelity interactive prototypes or production marketing sites — often both. They came from Figma and knew it wasn't built for interaction. They came from Webflow and wanted more design control. Framer sits between those two worlds and they've made it home. They are comfortable with the code escape hatch. They don't use it unless they have to. When they have to, they can.

The FullStory Behavioral Analytics PM

A senior product manager, digital experience lead, or data-savvy UX researcher at a company of 200–5,000 people where FullStory was purchased as a platform — not a point tool. They use it to answer questions that neither analytics dashboards nor individual session recordings can answer alone: what does the full behavioral pattern look like for users who churn? Where in the enterprise checkout flow do users consistently struggle? Which UI elements are generating frustration signals at scale? They work with data. They also watch sessions. Both inform the decision.

The Ghost Independent Publisher

An independent journalist, researcher, media entrepreneur, or content organization that chose Ghost because platform ownership matters to them. They're running a publication with a membership model — free and paid tiers, regular editorial content, and a direct relationship with readers they're not willing to cede to Substack's network effects or Beehiiv's operator framing. They are technically capable enough to run Ghost on managed hosting or self-host it. This was a deliberate choice. The people who choose Ghost have thought about the alternatives more carefully than most tool decisions require.

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.

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.

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 Google Analytics Marketing Manager

A marketing manager or digital marketer at a company of 10–200 people who is responsible for understanding how the website is performing and why. They are not a data person. They've been through the GA4 migration and have not recovered emotionally. They know enough to navigate the interface but not enough to build custom reports without three tabs of documentation open. They check analytics several times a week and leave most sessions with more questions than answers.

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.

The Greenhouse In-House Recruiter

An in-house recruiter at a company of 100–1,000 people managing 5–15 open roles at any given time. Greenhouse is their operating system for hiring. They know it well. They also know all the ways their company uses it wrong — job stages that don't reflect reality, interviewers who don't submit scorecards, hiring managers who give verbal feedback in Slack instead of structured feedback in the system. They are the connective tissue of a hiring process held together by their own follow-up.

The Gusto Small Company HR Manager

An HR manager, office manager, or operations lead at a company of 10–75 people for whom payroll and benefits are one of many responsibilities, not the whole job. They run payroll twice a month. They onboard new hires. They manage benefits open enrollment once a year and feel mild panic every time. They chose Gusto because it was less terrifying than what came before it. They trust it, mostly, but payroll is the one area of their job where a mistake has immediate and personal consequences for real people.

The Harvest Freelancer and Agency Owner

A freelancer, consultant, or small agency owner (2–15 people) for whom time is the product. They track hours against client projects and invoice from those hours. Harvest is where the financial reality of their business lives. They've learned that unbilled hours are lost revenue, that clients will dispute invoices without time entries to back them up, and that the difference between a profitable month and a break-even month is often the accuracy of their time tracking. They are disciplined about logging time — or they are trying to become disciplined about it.

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.

The Hex Data Analyst

A data analyst or analytics engineer at a company with a modern data stack — dbt, Snowflake or BigQuery, and a growing demand from business stakeholders for self-service data access. They use Hex because Jupyter notebooks are hard to share and dashboards aren't flexible enough. Hex sits in the middle: code-first enough for real analysis, shareable enough that a PM can click through an interactive version without needing to run code. They build notebooks in Hex. Business people use the published apps. This is the workflow they've been trying to build for years.

The Hotjar Session Watcher

A product manager, growth marketer, or UX designer at a company of 20–500 people who uses Hotjar to answer questions that quantitative analytics can't. They know their funnel. They know where users drop off. What they don't know is why. Session recordings are how they find out. They've watched hundreds of sessions. They've seen users rage-click on things that aren't buttons, scroll past CTAs without seeing them, and get confused by flows the team thought were obvious. Each one of these is a design decision waiting to happen.

The HubSpot Marketing Manager

A marketing manager at a company with 20–150 employees who is responsible for the entire marketing function — content, email, social, paid, and now increasingly the CRM data that sales keeps asking about. They chose HubSpot or inherited it. They use more of it than anyone else at the company. They still feel like they're not using it right, even after two years.

The Intercom Customer Success Manager

A customer success manager or support lead at a B2B SaaS company who uses Intercom as their primary customer communication layer. They handle inbound support conversations, run proactive outreach campaigns to at-risk accounts, and manage the onboarding message sequences that new users see. They know which customers are about to churn before anyone else does because they read the conversation history. They are the person who knows more about the product's real failure points than anyone in engineering.

The Jira-Burdened PM

A product manager or engineering team lead at a software company who runs sprints in Jira. They did not set up the Jira instance they work in — it was configured by someone who left 18 months ago, and the workflow has accumulated technical debt as surely as the codebase has. They know what they need Jira to do. Getting it to do that is a separate problem.

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.

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.

The Linear Engineering Manager

An engineering manager or head of engineering at a startup of 20–150 engineers who uses Linear at the issue level to track work and at the Projects level to communicate progress. The ICs live in issues and cycles. The EM lives in projects and the roadmap view. They're the translation layer between "what the team is building" and "what the company thinks we're building" — and Linear Projects is the interface they use to close that gap.

The Liveblocks Collaboration Developer

A frontend or full-stack developer at a SaaS company whose product needs real-time collaboration — multiple users working in the same document, canvas, or interface simultaneously. They've looked at building it themselves. The WebSocket infrastructure, the conflict resolution, the presence system, the storage — it's 3–6 months of work that isn't their product. They chose Liveblocks to compress that into a week. They are now the person at their company who knows how Liveblocks works. This is a niche form of expertise they didn't expect to develop.

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.

The Loom Async Communicator

An individual contributor or people manager at a remote-first company who uses Loom as their primary format for communicating complex information asynchronously. They record walkthroughs, give feedback, share context, and replace 80% of the meetings they used to have. They are comfortable on camera — not because they love being on camera, but because they've made peace with the fact that async video is the clearest way to communicate nuance without a meeting. They have a good mic. They have a ring light. They did not buy these for fun.

The Mailchimp Small Business Owner

A small business owner, solopreneur, or creator who sends a regular email to their list — weekly newsletter, promotional email, customer announcement. They are not a marketer by training. They set up Mailchimp because it was recommended and free. They've been using it for 1–4 years. They care about their list and think of it as their most direct connection to their customers. They are not fully sure what open rates mean in a post-Apple-MPP world but they still check them because it's the only signal they have.

The Make Power Automator

An operations lead, automation specialist, or technical non-developer who moved to Make (formerly Integromat) after hitting the ceiling on Zapier. They know what they wanted to build and Zapier's linear trigger-action model couldn't do it: conditional branches, iterators, error handlers, multi-route flows. Make could. They learned Make. They have built things in Make that non-technical people would describe as software and technical people would describe as creative. They exist in the middle of the developer-to-non-developer spectrum and they've built a practice there.

The Maze Unmoderated Research Lead

A UX researcher or product designer at a company where research is valued but researcher time is scarce. They use Maze to run tests they can't run fast enough with moderated sessions. They design the test, connect the Figma prototype, send the link, and come back to results in 24–72 hours. They know unmoderated testing misses the nuance of moderated sessions. They also know that running 8 moderated sessions takes 2 weeks of scheduling and 2 days of synthesis. Maze takes 2 hours to set up and 1 hour to analyze. They're using the right tool for the question.

The Midjourney Creative Director

A creative director, art director, or senior designer who adopted Midjourney after realizing it was changing their concept phase. They use it to generate reference material, explore visual directions, and produce images that would previously have required a stock license, a photographer, or a two-week illustration commission. They have strong prompt craft. They know what they're doing. They also know the tool's failure modes and work around them. They do not use it to replace their judgment — they use it to accelerate the point at which judgment can be applied.

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 Miro Remote Facilitator

A UX designer, product strategist, design researcher, or Agile coach who uses Miro as their workshop room. They've run retrospectives, journey mapping sessions, design sprints, and ideation workshops — all on Miro, all remote. They are good at facilitation. They have strong opinions about how a Miro board should be structured. They've also learned that a beautifully structured board means nothing if participants don't know how to use sticky notes.

The Mixpanel Product Manager

A product manager or growth lead at a B2C or B2B SaaS company for whom Mixpanel is the primary lens on user behavior. They are not a developer. They understand events and properties well enough to answer most of their questions self-service. They have a set of saved reports they look at every Monday. They also have questions that require a data analyst to answer — and they're slowly working to reduce that list.

The Monday.com Team Lead

A team lead or department head at a company of 50–300 people who uses Monday.com as the primary place their team tracks work. They may not have chosen Monday — it was often adopted company-wide because the CEO liked the demo. They've made it work. Their board is actually used. They've built automations their team quietly depends on. They spend 30–60 minutes a day in Monday and would describe it as "pretty good once you know what you're doing," which is a backhanded compliment they mean sincerely.

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.

The Notion Calendar Unified Planner

A founder, PM, or knowledge worker who lives in Notion and has always felt the calendar app sitting separately as a second system that doesn't talk to the first. They adopted Notion Calendar because the promise — their calendar and their Notion workspace, unified — is the thing they've wanted for years. They're still calibrating how much of that promise is real. The answer is: more than Google Calendar, not yet everything they imagined.

The Notion Second-Brain Builder

A solo founder, PM, or highly organized individual contributor who has made Notion the center of their work life. They have a workspace that would take three hours to explain to someone new. They've built custom dashboards, linked databases, and templates they're genuinely proud of. They've also started from scratch twice after a system got too complex to maintain. They believe the perfect Notion setup is always two weekends away.

“The moment a filtered database view showed them exactly the information they needed without searching.”

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.

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

The Perplexity AI-Native Searcher

A researcher, analyst, consultant, or curious professional who started using Perplexity for quick lookups and gradually shifted most of their search behavior to it. They value citations. They appreciate the synthesized answer more than a list of links they have to open and read. They trust it for most things. They verify independently for decisions where being wrong has consequences. They've tried to explain why they prefer it to people who use Google and have not fully succeeded because the difference is in the feel of the first answer, which doesn't translate to a verbal description.

The Photoshop Production Designer

A graphic designer — in-house or agency — who uses Photoshop as their primary production tool for image work. They've been in Photoshop for 5–15 years and work with the efficiency of someone who knows exactly where everything is and what everything does. They don't explore menus. They use shortcuts. Their workspace is a system they've tuned. Photoshop is slow sometimes and they've learned to work around it the way you work around a colleague's habits — with patience and workarounds they've stopped noticing.

The Pika AI Video Creator

A content creator, marketing director, or creative professional who has integrated AI video generation into their content workflow. They use Pika to turn static concepts, images, and text prompts into short video clips for social media, ads, and marketing presentations. They are not video producers. They don't have a camera setup, a motion designer on staff, or the budget for a production house for every asset. They have prompts and a process. They're producing things that didn't exist two years ago from a budget that hasn't changed.

The Pitch Deck Builder

A startup founder, sales director, or brand marketer who builds presentation decks that matter — investor pitches, sales proposals, quarterly business reviews. They chose Pitch because PowerPoint felt like 2005 and Google Slides felt like giving up on design. Pitch gives them templates that look professional and a collaborative workflow that doesn't require sending a file over email. They spend more time on decks than they'd like to admit. They care more about how those decks look than they'd admit in a meeting.

The PostHog Product Engineer

A product engineer or full-stack developer at a startup of 5–50 people who chose PostHog — or advocated for it — because they wanted product analytics that behave like engineering tools. They self-host or use PostHog Cloud. They instrument events themselves. They use feature flags as part of their development workflow. They are not a data analyst but they want to be able to answer product questions without filing a request to one.

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 QuickBooks Small Business Owner

A small business owner — a contractor, consultant, retailer, or service business — doing their own bookkeeping in QuickBooks because they can't yet justify what an accountant costs. They are not a numbers person by nature. They are running QuickBooks because they were told they had to, not because they wanted to. They feel mild anxiety every time they open it and have not reconciled their accounts in two months.

The Ramp Finance Manager

A finance manager, controller, or CFO at a company of 20–300 people who adopted Ramp to eliminate the expense report process that everyone hated and nobody trusted. They issue cards. They set limits. They receive receipts automatically from employees who forward a text message or take a photo. They close the books faster. They've calculated how many hours per month expense reports used to consume and they don't miss a single one of them. They are the person at the company who is most enthusiastic about Ramp.

The Raycast Power User

A developer, designer, or technical knowledge worker on Mac who replaced Spotlight with Raycast and then spent three weekends making it the center of their computing workflow. They open Raycast more than any other application. They open it for things they didn't know a launcher could do. They've written or installed extensions for their most repetitive tasks. They mention Raycast in the same breath as mechanical keyboards and monitor setups — tools that are invisible when they work and felt intensely when they don't.

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.

The Replit Non-Traditional Builder

A student, career changer, or self-taught developer who is building real things before they've mastered the full developer toolchain. They use Replit because it removes the setup. There's no local environment to configure, no PATH to fix, no version conflicts. They open a browser, pick a language, and the environment exists. They have learned more by shipping things than by completing tutorials. They have strong momentum. They have significant gaps. This is not a problem — it's a developmental stage.

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 Retool Internal Tools Developer

A full-stack or backend developer at a startup or scale-up who has been asked — once too many times — to pull data from the database for a non-technical teammate. They discovered Retool as a way to give those teammates self-service access without giving them direct database access. They've built 3–8 internal tools: an admin panel, an operations dashboard, a customer lookup tool, and at least one thing they built in a weekend that the whole company now depends on.

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.

The Rive Interactive Animation Designer

A designer or creative developer who builds animations that respond to state, not just ones that play and loop. They discovered Rive when they realized that Lottie was great for playing animations but couldn't handle the "and then when the user clicks, it does this" requirement. Rive's state machine changed their practice. They now build animations that are interactive first — hover states, press states, loading-to-success transitions, character rigs that respond to game input. They are comfortable in both the design and the runtime.

The Riverside Remote Podcast Host

A podcast host, interview show creator, or video podcast producer who records remote guests and has been burned enough times by Zoom audio artifacts that they moved their entire recording setup to Riverside. They care about sound quality in a way that most people around them don't understand. They've explained "local track recording" to three different guests and still have guests who join from a coffee shop with AirPods. They've made peace with this.

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.

The Runway AI Video Editor

A video editor, creative director, or content producer who has integrated Runway into their professional workflow — not as a novelty, but as a production tool that changes what's achievable in a given timeline and budget. They use Runway for AI video generation, background removal, inpainting, motion tracking, and generative effects that would require a VFX team or days of Premiere work otherwise. They have a traditional video editing background. They understand the craft. They are not using Runway to replace craft — they're using it to expand what they can produce without expanding the team or the deadline.

The Reluctant Salesforce User

An enterprise sales rep at a company with 200+ employees who did not choose Salesforce. It was there when they arrived. They've been trained on it twice. They use about 20% of its features and have found workarounds for everything else. They log activity because their manager checks. They update opportunities because forecasting requires it. They do not believe Salesforce makes them better at sales. They believe it makes their manager better at measuring sales.

The Sanity Developer-Content Team

A developer who chose Sanity for a project that needed a content infrastructure serious enough to model complex relationships and flexible enough to be customized for a non-developer content team. They built the schema. They configured the Studio. They wrote the GROQ queries. The content team uses what they built every day. The developer's relationship with Sanity is: maintenance, evolution, and occasional deep satisfaction when the content model they designed months ago handles a new requirement gracefully.

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.

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.

The Shopify DTC Brand Owner

A founder or owner of a direct-to-consumer brand doing $10K–$500K in annual revenue on Shopify. They launched the store themselves, chose the theme themselves, and manage it themselves — occasionally with help from a contractor they can barely afford. They know their products, their customers, and their margins. They do not know why their abandoned cart rate is what it is or how to fix it, but they know it matters.

The Slack-Drowning Knowledge Worker

A full-time knowledge worker — marketer, PM, ops, customer success — at a company large enough that Slack has become the ambient noise of their workday. They didn't design the channel structure they live in. They inherited it. They have 12 unread DMs, are mentioned in 3 channels they rarely check, and have muted so many channels that important things occasionally slip through the cracks. They're not bad at their job. They're bad at Slack because Slack has become its own job.

The Spline Web 3D Designer

A product designer, visual designer, or creative developer who started using Spline because they wanted 3D on their website or product and Blender was too much. They have a 2D design background — Figma is their native language. Spline felt like Figma with a Z-axis. They've built at least one thing they're proud of: a 3D hero section, an interactive product visualization, a floating element that reacts to cursor position. They use it for client work and personal projects. They consider themselves an early adopter of the idea that 3D should be accessible to product designers, not just motion designers.

The Squarespace Small Business Owner

A photographer, therapist, consultant, restaurant owner, or small retailer who built their own website on Squarespace because it was the best option they could manage independently. They are not a developer. They do not want to be. They want a website that looks professional, is easy to update, and doesn't require a support ticket to change the menu. They've succeeded at this mostly. There are two things on their site that have been wrong for three months because fixing them would require understanding something they don't want to learn.

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.

The Stripe Integration Developer

A full-stack or backend developer at a startup or mid-size company who built and maintains the Stripe integration for their product. They integrated Stripe once — it took a week in dev, two days in staging, and then went live and mostly just worked. Now they're the person who gets the Slack message when a payment fails. They know the Stripe docs well enough to find what they need. They have a complicated relationship with webhooks.

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.

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 Superhuman Executive

A founder, executive, investor, or senior individual contributor for whom email is a primary work surface and inbox zero is not aspirational — it is the operating condition required to function. They use Superhuman because they did the math: the time saved per email multiplied by 200 emails per day is real money. They have strong keyboard habits. They were already fast at email. Superhuman made them faster. They will tell you about it if you ask, and sometimes if you don't.

The Tally Non-Technical Form Builder

A startup founder, indie maker, or operations person who creates forms for surveys, lead capture, applications, and feedback — and who bounced off Typeform's pricing, Google Forms' aesthetic, and Airtable Forms' rigidity. They found Tally and built their first form in 4 minutes. They converted immediately. They use Tally for things that other tools make too complicated or too expensive for what's essentially a box to collect information.

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.

The Toggl Self-Tracker

A freelancer, consultant, or productivity-conscious knowledge worker who tracks time for one of two reasons: they bill by the hour and accuracy is revenue, or they've realized they have no idea where their hours go and they want to find out. Both types start Toggl for practical reasons and discover something unexpected — tracked time is honest in a way that memory and intention are not. They've had the experience of thinking they spent 4 hours on a project and the timer saying 2.2. They've also had the reverse. Both were useful information.

The Twilio Communications Developer

A backend or full-stack developer at a startup or mid-size company who built the Twilio integration that handles customer-facing communications — appointment reminders, verification codes, order updates, or two-way SMS. They did the integration once. It worked. Now they're the person who gets paged when a customer says they didn't receive their verification code, and they have to determine whether that's a Twilio problem, a code problem, or a carrier problem — in that order.

The Typeform Research and Marketing User

A UX researcher, marketer, or operations person who uses Typeform because they've seen what happens to completion rates when you use Google Forms. They care about the quality of the responses they collect — which means they care about the experience of filling in the form. They design forms deliberately: question order, logic branches, conversational tone. They know their completion rate. They have an opinion about it.

The Vercel Frontend Developer

A frontend or full-stack developer with 2–8 years of experience who discovered Vercel and decided that deploy-on-push preview URLs should be table stakes for every project. They've tried to describe the Vercel experience to developers still using other deployment pipelines and can't fully convey it. They use Vercel for personal projects, client work, and have advocated for it at their company — sometimes successfully. Their bar for deployment infrastructure is now set by Vercel, which makes everything else feel like a step backward.

The VS Code Full-Stack Developer

A full-stack developer with 2–10 years of experience for whom VS Code is the primary tool of their craft — the place they spend most of their working day. They have a VS Code configuration that took months to arrive at and that they bring to every new machine. They know their extensions. They know their keybindings. They have an opinion about whether Prettier should run on save. Their editor is not the default installation — it's a reflection of how they think about working.

The Webflow No-Code Designer

A designer — visual, brand, or marketing — who uses Webflow to design and build production websites without relying on a developer. They came from Figma or Sketch and discovered that the gap between design and the live site was where everything good went to die. Webflow closed that gap. They have strong opinions about how websites should look and work, and Webflow lets them act on those opinions directly. They are faster in Webflow than any developer who doesn't know the design would be.

The Whimsical Fast Diagrammer

A product manager, designer, or engineer who uses Whimsical for the work that happens before the work — user flows, information architecture diagrams, quick wireframes, system diagrams. They chose Whimsical over Figma for this because Figma requires too much setup for a sketch. They chose it over Miro because they need structure, not freeform. They chose it over Lucidchart because Lucidchart is too heavy for what they're doing. Whimsical is the tool for the thinking phase. It is rarely the final deliverable. It is always the thinking that produces the final deliverable.

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 Zapier Non-Technical Automator

An operations coordinator, marketing manager, or executive assistant who discovered Zapier and spent an afternoon automating a task that had been eating 45 minutes of their week. That experience was formative. They now have 12 Zaps running, three of which they fully understand, one of which they're afraid to touch, and one that they know has been broken for two weeks but the fix intimidates them. They are not a developer. They are the closest thing to one in their department.

“The first time a Zap fired while they were asleep and something they always did manually just.”

The Zoom-Fatigued Remote Manager

A manager or team lead at a remote-first or hybrid company for whom Zoom is the primary way they experience their job. They run standups, 1:1s, team meetings, cross-functional syncs, and the occasional all-hands. They are good at running meetings. They are exhausted by running meetings. They've read the articles about camera fatigue and still feel obligated to be on camera. Their background is a shelf they specifically arranged.