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

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 PostHog Growth Engineer

A growth engineer, product engineer, or technical PM who uses PostHog as their all-in-one growth stack — analytics, feature flags, A/B tests, session replay. They chose PostHog because they didn't want to stitch together Amplitude, LaunchDarkly, and Hotjar. They think in funnels, retention curves, and statistical significance. They are technical enough to self-serve but product-minded enough to care about the "so what" behind the data.

“It happened mid-workflow — the growth engineer is running an A/B test on the onboarding flow.”

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 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 Slack Workspace Architect

An IT admin, department head, or operations lead responsible for how their company uses Slack. They set up the workspace when it was 20 people and now it's 200. They created the channel naming conventions that nobody follows. They are the person people DM when they can't find something, when a channel needs to be archived, or when someone needs to be added to a private channel they shouldn't have access to.

“Not a single dramatic moment — more like a Tuesday at 3pm when they realized they hadn't thought about channel sprawl — 400 channels, half are dead, nobody wants to archive them in two weeks.”

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 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 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 Pika Video Creator

A social media manager, content creator, or marketer who uses Pika to generate short video clips for social media, ads, and content marketing. They're not a video editor — they're a marketer who needs video content faster than traditional production allows. They type descriptions and get video clips. They use image-to-video for product animations. They create motion graphics from static designs. They've learned that "good enough for social" is a valid quality bar, and Pika hits it in minutes instead of hours.

“It happened mid-workflow — the social media manager needs 5 short clips for the week's content calendar.”

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 Typeform Survey Designer

A UX researcher, product manager, or marketer who chooses Typeform over Google Forms because the survey experience matters. They've learned that completion rate is the most important metric for a survey, and completion rate is a design problem. They craft surveys that feel like conversations: one question at a time, conditional logic, thoughtful copy. They spend as much time on the question experience as they do on the question content. They are the person who says "we can't just send a Google Form — that sends a message about how much we value their feedback."

“The shift was quiet.”

The Clay GTM Engineer

A GTM engineer, growth operations lead, or RevOps professional who uses Clay as their data enrichment and workflow engine. They build spreadsheet-like tables that pull from 50+ data providers — enriching companies with technographic data, finding decision-makers' emails, scoring leads based on signals, and triggering personalized outreach. They think in data transformations and API calls. They've replaced hours of manual prospect research with Clay workflows that run in minutes. They are the engineer of the sales pipeline's data layer.

“The shift was quiet.”