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

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 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 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 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 Make Integration Architect

An automation specialist, operations engineer, or technical ops manager who builds complex workflows in Make because Zapier wasn't enough. They connect 10–30 tools with branching logic, iterators, aggregators, error handlers, and data transformations. They build automations that look like flowcharts, not if-then rules. They've learned Make's visual interface deeply — routers, filters, webhooks, custom HTTP modules. They are the person who automates what everyone else does manually, and they take quiet pride in systems that run for months without intervention.

“A teammate asked how they managed build multi-step automations with branching logic that handles different cases (approval/rejection, success/failure).”