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

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

“A teammate asked how they managed understand what happened when a payment fails before the customer reaches support.”

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.

“It happened mid-workflow — three customers have filed support tickets saying they didn't receive their OTP.”

The Shopify App Developer

A developer or small agency building Shopify apps — either custom apps for specific merchants or public apps for the Shopify App Store. They know Liquid well enough to customize themes and the Admin API well enough to build features merchants ask for. They spend equal time writing code and reading Shopify's changelog to see what broke or changed. They've been through at least one major API version migration and still have scars.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about aPI versioning deadlines that force migration work on their timeline, not the developer's in two weeks.”

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

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

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about build times that climb as the project grows — especially Next.”

The Cal.com Developer Scheduler

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

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

The 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 shift was quiet.”

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.

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

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

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about retool queries that are fast in development and slow in production on real data volumes in two weeks.”

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.

“A teammate asked how they managed stay in flow state — the editor should get out of the way and let them write.”

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.

“It happened mid-workflow — they're building a loading animation for a fintech app.”

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.

“It's 9am.”

The Sentry Error Monitor

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

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

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

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about schema changes that require migration scripts for existing content — the cost in two weeks.”

The Liveblocks Real-Time Developer

A frontend developer who needs to add real-time collaboration to an existing app — live cursors, presence indicators, shared document editing, or collaborative whiteboards. They chose Liveblocks because building WebSocket infrastructure from scratch is a project in itself, and they need to ship the feature, not the infrastructure. They understand React, they understand state management, and Liveblocks extends those mental models to multiplayer. They are building the "Google Docs" experience for their product.

“It happened mid-workflow — the developer is adding collaborative editing to a project management tool.”

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 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 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 Contentful Headless CMS Developer

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

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

The Apollo Sales Development Rep

A sales development representative or outbound sales rep at a B2B company who uses Apollo as their prospecting command center. They build prospect lists from Apollo's database, enroll them in email sequences, track opens and replies, and try to book meetings. They send 50–200 outreach emails per day and know that personalization is the difference between a reply and the spam folder. They are a relationship builder working at volume, and they've developed an intuition for which prospects will respond and which won't.

“The shift was quiet.”

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.

“A teammate asked how they managed publish and update content quickly without waiting on a developer for every change.”

The Stripe Platform Builder

A technical founder or senior developer building a platform where money flows between multiple parties — a marketplace, a SaaS with payouts, or a platform that onboards sellers. They chose Stripe because the API is good, but they've discovered that Stripe Connect is a different animal entirely. They understand payment intents but still get confused by the relationship between accounts, charges, and transfers. They are building financial infrastructure and it keeps them up at night.

“The first time a seller on their platform got paid automatically — money flowed from buyer to platform to seller with the correct fee split, no manual step, no CSV export.”

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 Rive Interactive Animation Designer

A motion designer or creative developer who uses Rive to create animations that aren't just decorative — they're interactive. They build loading indicators that respond to progress, toggle switches that morph between states, onboarding illustrations that react to user input, and game-like UI elements. They think in state machines: idle, hover, active, success, error. They chose Rive because After Effects exports video, Lottie exports playback, but Rive exports interactive, state-driven animations that respond to runtime input.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about the state machine editor has a learning curve, especially for designers coming from timeline-based tools in two weeks.”

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 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 Vercel Agency Deployer

A developer at a web agency or a freelancer who deploys and manages 20–100 client projects on Vercel. They chose Vercel because the developer experience is excellent and Next.js deploys are zero-config. But managing 50 projects across 15 clients has turned deployment into project management. They spend as much time in the Vercel dashboard organizing teams and domains as they do writing code. They know every deployment preview URL is a demo link, and they've sent the wrong preview to the wrong client exactly once.

“A client emails asking why their site is showing an old version.”

The Harvest Freelance Time Tracker

A freelance designer, developer, consultant, or small agency owner who bills by the hour and uses Harvest to track every minute. They know that untracked time is unpaid time, and unpaid time is a silent business killer. They start timers when they begin work, stop them when they break, and review their timesheets weekly to make sure nothing slipped. They've built a system that balances accurate tracking with not letting the tool interrupt their flow. They are both the worker and the business.

“A freelance developer juggles three active clients.”

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

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

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

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

“A teammate asked how they managed maintain operational data that's accurate enough to make real decisions from.”

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.

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

The Loom Async Communicator

A product manager, engineering lead, or designer working on a remote or distributed team who realized that most meetings could be a Loom. They record 5–15 looms per week — product updates, code walkthroughs, design feedback, project kickoffs. They've developed a recording style: concise, screen-shared, with their face in the corner. They are an async communication evangelist who believes the 30-minute meeting is a relic of co-located work.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about video organization becomes a mess — finding a specific loom from three months ago requires remembering the exact title in two weeks.”

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.

“It happened mid-workflow — they've shipped a new onboarding flow behind a feature flag to 10% of users.”

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 shift was quiet.”

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.

“A teammate asked how they managed understand where users drop out of key flows and why.”

The Maze UX Research Automator

A UX researcher or product designer who uses Maze to test prototypes before they go to development. They run unmoderated usability tests where participants interact with Figma prototypes while Maze captures click paths, task success rates, and misclick patterns. They chose Maze because moderated testing doesn't scale — they can't schedule 50 individual sessions for every design decision. They need data, not opinions, and they need it in days, not weeks.

“A teammate asked how they managed test prototypes with 20–100 participants without scheduling individual sessions.”

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

“It happened mid-workflow — they're building a personal finance tracker.”

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.

“A client needs a system: when a new deal is created in HubSpot above a certain value, create a proje.”

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

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about error messages that tell them a Zap failed but not what to do about it in two weeks.”

The Jira Engineering Manager

An engineering manager leading a team of 5–15 developers. They use Jira because the company chose it years ago and migration would be worse than staying. They plan sprints, groom backlogs, and build the reports their VP needs for quarterly reviews. They know Jira's power but resent its complexity. They've customized their board exactly once and now they're afraid to touch it. They protect their team from Jira overhead by doing most of the admin work themselves.

“The shift was quiet.”

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

The Webflow Design-to-Production Designer

A web designer or design agency owner who ships production websites directly from Webflow — no developer handoff, no code translation step. They think in layout, typography, and spacing, but they've also learned Webflow's class system, CMS collections, and interaction triggers. They are a designer who became a builder. They're proud that they can ship a client site in a week, but they're aware that their Webflow projects are sometimes held together with class naming conventions only they understand.

“A teammate asked how they managed build responsive, pixel-perfect websites that match the design vision exactly.”

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

“It's launch week for a new product campaign.”

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 shift was quiet.”

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 shift was quiet.”

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 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 Midjourney Visual Creator

A creative professional — designer, art director, marketer, or content creator — who has integrated Midjourney into their production workflow. They don't generate random images for fun; they craft prompts with precision to produce specific visual outcomes: hero images for landing pages, mood boards for brand development, concept art for product pitches, and social media visuals. They've developed a prompt vocabulary that gets consistent results. They understand that AI art isn't "pushing a button" — it's iterating, refining, and curating from dozens of generations.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about consistent brand characters and specific product representations are still unreliable in two weeks.”

The Spline 3D Web Designer

A web designer or creative developer who uses Spline to add 3D to their web projects without the learning curve of Blender or Cinema 4D. They create 3D hero sections, interactive product visualizations, animated icons, and immersive landing pages. They are a designer who crossed into the third dimension. They appreciate that Spline runs in the browser, exports to the web natively, and feels like a design tool rather than a 3D modeling application. They are the person making websites feel like they have depth.

“A SaaS company wants a landing page that stands out.”

The Wix Small Business Builder

A small business owner — a personal trainer, a photographer, a bakery, an accountant — who built their website on Wix because they could drag and drop their way to something that looked professional enough. They aren't designers. They aren't developers. They are business owners who need an online presence. They picked a template, moved things around until it looked right, added their text and photos, and hit publish. They update it when they remember to. It's not perfect, but it exists, and it brings in customers.

“A potential client searches "photographer near me" and finds the business owner's Wix site on the second page of Google.”

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

“They're redesigning a SaaS product's marketing homepage.”

The Squarespace Small Business Owner

A small business owner — a bakery, a yoga studio, a photography business, a consulting firm — who built their website on Squarespace because they needed something that looked professional without hiring a designer or developer. They chose a template, swapped in their photos, wrote their copy, and launched. They're not technical, but they figured out the editor. They update the site monthly — new photos, seasonal hours, blog posts when they have time. The website is their digital storefront, and they treat it with the same pride they treat their physical one.

“A potential customer finds the small business owner's Squarespace site through Google.”

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.

“It's November 8th.”

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 checkout conversion rate dropped 2.”

The Segment Data Architect

A data engineer or analytics engineer who manages Segment as the central event routing layer. Every product event — page views, clicks, purchases, signups — flows through their Segment workspace before reaching the data warehouse, analytics tools, and marketing platforms. They are the plumber of the data stack. Nobody thanks them when data flows correctly, but everyone notices when it doesn't. They think in events, properties, and destinations. They've learned that the hardest part of data infrastructure isn't moving data — it's keeping it clean.

“The shift was quiet.”

The Deel Global Team Manager

An operations lead, HR manager, or founder at a remote-first company who has team members across 5–20 countries. They use Deel because hiring internationally is legally complex and paying people across borders is operationally painful. They manage contracts, process payments, and handle compliance for contractors and full-time employees in countries they've never visited. They've learned that "hiring remotely" really means "learning employment law for every country you hire in." Deel handles the parts they can't.

“The shift was quiet.”