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

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

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