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

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 Hex Collaborative Data Analyst

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

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

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

“An investor meeting is in 48 hours.”

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.

“A teammate asked how they managed move from concept to spec without losing fidelity at each stage.”

The Pitch Startup Storyteller

A startup founder, head of product, or strategy lead who creates presentations that need to look beautiful and tell a compelling story — investor decks, product roadmaps, board updates, customer pitches. They chose Pitch because it produces better-looking slides with less effort than PowerPoint or Google Slides. They value design defaults that make everything look good automatically. They collaborate in real time with co-founders and design team members. They are visual communicators who believe that how a story is presented is as important as the story itself.

“It happened mid-workflow — the founder is preparing for a Series A fundraising round.”

The Dropbox Creative Team Manager

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

“The shift was quiet.”

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

“A client has requested all source files from a project completed eight months ago.”

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

“A teammate asked how they managed build analyses that colleagues can interact with without running code themselves.”

The Miro Workshop Facilitator

A product designer, agile coach, or team lead who facilitates remote workshops in Miro. They don't just draw on a whiteboard — they design participatory experiences: timed exercises, voting rounds, structured templates, and breakout activities. They've learned that the tool is 30% of a good workshop; the other 70% is facilitation design. They are the person who spends 2 hours preparing a Miro board so that a 1-hour workshop runs smoothly for 20 people.

“The facilitator is running a design sprint kickoff with 15 people.”

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.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about new participants who spend the first 10 minutes learning Miro instead of the topic in two weeks.”

The Monday.com Team Lead

A team lead or department manager at a 30–200 person company who chose Monday.com because it looked simple enough that their team would actually use it. They set up the boards, configured the automations, and built the views. Now they spend 20 minutes every morning making sure the board reflects reality. They are the bridge between the team's actual work and the executive's need for status updates. They don't love project management tools, but they love knowing where things stand.

“It happened mid-workflow — the team lead sets up a sprint board with automations: when a task moves to "In Review," it notifies the reviewer and updates the deadline.”

The Fly.io Edge Deployer

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

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

The Sanity Content Architect

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

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