Søren Bramer Schmidt - founder & CEO of Prisma
Prisma co-founder Søren Bramer Schmidt explains how educator partnerships and community work compound over years, why scale changes product prioritization, and how Prisma Postgres was designed for the economics of AI-generated applications.
Søren Bramer Schmidt is the co-founder and CEO of Prisma, whose ORM became an early part of the modern JavaScript stack for a large community of developers.
We talk about Prisma's deliberate early growth strategy, the tension between innovation and stability at scale, the evolution from Graphcool to Prisma ORM, why the company launched a database, and how infrastructure design made simpler request-based pricing possible.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did educators help Prisma grow?
Working directly with educators was our primary early growth strategy. We supported people creating courses and partnered with emerging frameworks such as RedwoodJS so Prisma could become a default. The return is hard to quantify in the moment, but years later a large population understands the product and has real affinity for the brand.
Why did you aim for Hacker News every month?
We needed to bootstrap awareness when monthly user counts were still in the hundreds. By repeatedly building useful projects around the fast-growing GraphQL community, we could reach developers who might not convert immediately but would recognize Prisma on the second or third encounter. At today's scale, organic adoption matters far more than any single campaign.
How does a huge community constrain product development?
A small project can break things and move quickly; an ORM used by large organizations must protect applications that have run for years. We want to follow shifts in the market without making upgrades costly or eroding trust. That slows change, but the community's reliance on Prisma is also our greatest advantage.
How do you prioritize thousands of open issues?
Individual requests can be perfectly sensible while collectively representing far more work than the team can perform. We published an ORM manifesto explaining two inputs: strategic company priorities and direct evidence from the community. Making the policy explicit helps users understand why a longstanding request may still wait.
Why did Prisma move from Graphcool to an ORM?
The early product sat between GraphQL applications and databases, but the company learned where developers needed a durable abstraction. Prisma ORM became a more modular layer designed to work at the scale and reliability level that engineering decision-makers at larger organizations could accept.
Why launch Prisma Postgres now?
AI tools let somebody create a useful application in hours, but that application still needs a database and infrastructure. Spending days configuring networks and servers no longer matches the cost of creating the app. Prisma Postgres was built so developers can create many databases cheaply and pay only when those applications actually make requests.
Why price by requests instead of compute hours?
Reserved instances are predictable but inflexible, while usage pricing based on compute hours and memory is difficult for a developer to forecast. Requests remain variable, yet developers can reason from visits and application behavior to an approximate bill. The pricing unit follows a quantity the customer already understands.
How do you stop a simple pricing model being abused?
First, lower the underlying cost by owning servers rather than paying AWS prices. Second, define reasonable limits for a normal application query; a request cannot consume compute for an hour. Simple customer-facing pricing is possible because the architecture and guardrails absorb variation underneath it.
What does operating your own hardware involve?
It requires upfront servers, networking and operational work, but that fixed cost is shared across a venture-scale customer base. The data centers sit beside major AWS regions with direct connectivity, keeping latency low. For an individual developer this effort would make no sense; at Prisma's scale it changes the service economics substantially.