Accent colours the marks — active tab, underline, the main button. The frame, grid lines and body text stay graphite.
Blog
Notes · Building
What “enterprise-ready” means — and when you don't need it
Michael Grinich built WorkOS to sell big companies the one thing that stalls great products: the boring security plumbing. A note on his conversation — what enterprise-readiness actually is, when it's a trap, and the new chasm opening under AI agents.
21 June 2026 · 9 min read · CodeRabbit · The Merge
Written with AI tools, reviewed by me on its substance — how these are made →
Michael Grinich dropped out of MIT to intern at an early Dropbox, then built a beautiful email startup called Nylas that couldn't sell into big companies. That failure became WorkOS — a platform whose whole pitch is “your app, enterprise-ready,” now used by OpenAI, Anthropic, and Cursor. I watched his hour-and-a-half on CodeRabbit's podcast to answer two questions I had about my own apps: what does “enterprise-ready” even mean, and do I need it?
"It's not enough just to build a product that's beautiful, that's nice. You have to build all the security stuff into it if you want to sell it to enterprise companies."
What “enterprise-ready” actually is
Grinich is refreshingly literal about it. His first roadmap was just the bullet points from the “Enterprise” column of a SaaSSoftware as a Service — software you rent in the cloud instead of installing. pricing page — the features a 500-person company's security team demands before they'll trust you with their data and their budget.
"It was like SSOSingle Sign-On — one corporate login instead of yet another password., SCIMAuto-provisioning — the identity provider creates and removes user accounts automatically., provisioning, audit logs, role-based access control, yada yada compliance, encryption, EKMExternal Key Management — the customer holds their own encryption keys. — all this stuff. That was our roadmap for the first five years."
In plain language, that list is:
- SSOSingle Sign-On — one corporate login instead of yet another password. — log in with the company's identity provider (Okta, Entra), not yet another password.
- SCIMAuto-provisioning — the identity provider creates and removes user accounts automatically. — that provider auto-creates and auto-removes users; fire someone and their access is gone in minutes.
- RBACRole-Based Access Control — permissions follow roles, not individuals. — roles carry permissions, and permissions gate what each person can do.
- Audit logs — a record of who did what, when, and where.
- Multi-tenancy — everything is scoped to an organization, not to a lone user.
The enterprise chasm
His core idea is the “enterprise chasm”: the gap between a product people love and a product a corporation can actually buy. Plenty of founders hit that wall — great UX, real fans, and then growth stalls because the security checklist isn't there. WorkOS exists to hand you that checklist as Lego bricks so you cross the gap fast.
The flip side is what he refuses to do: on-prem and self-hosting. Let a customer run your software on their own servers and you win the deal now, but you're chained forever to maintaining a zoo of versions — you even end up begging them to accept your security patches.
"Once you do it, it's kind of like selling your soul to the devil. It's great initially, but it drags you down later, because you have to keep maintaining these things."
When you don't need it
Here's the part the title of his company won't tell you: most products shouldn't build any of this yet. If you're not selling to enterprises, enterprise plumbing is a distraction from finding product-market fit — which is the actual subject of the interview. And when you do need it, there's an order: roles first (everything depends on them), then audit logs, then SSOSingle Sign-On — one corporate login instead of yet another password., and SCIMAuto-provisioning — the identity provider creates and removes user accounts automatically. dead last, only when a customer explicitly asks.
The next chasm is opening under agents
The half that grabbed me wasn't enterprise at all — it was agents. Grinich's frame is that an AI agent is a new kind of coworker, and the infrastructure we built for human employees has to be reinvented for digital ones.
"Agents are sort of like a form of digital people doing things. We'll collaborate with agents."
Permissions are the hard problem. For ordinary code you can read the source and grant the minimum access it needs. An agent is non-deterministic — you can't predict what it'll do, so you can't pre-grant the right scopes.
"Agents throw all that out the window. If you're running an agent, it's not deterministic. You can't predict the behavior."
Anyone who's used Claude Code knows the result: it keeps asking “can I run this? can I access the web?” until you give up and hit YOLO mode — and now a long-running agent quietly hoards permissions it never gives back. His proposed fix is a separate, reasoning permissions layer that grants access for the moment and pulls it back after. His mental image of the agent itself is Mr. Meeseeks from Rick and Morty: it pops in, solves the one task, and vanishes — security isn't its job, it's the layer's.
"My favorite mental representation of an agent is Mr. Meeseeks from Rick and Morty. His only job is to do whatever you're trying to get solved. Doesn't think about anything else."
Make your tools easy for agents to find
The most practical takeaway: build for agents as users. WorkOS already ships an installer an agent can run end-to-end — it can even sign up on its own.
"The agent can sign up for WorkOS without you being involved at all. And you, as a human, can claim that environment later."
Two ideas worth stealing. First, distinguish read from call: a plain text file like /llms.txt or AGENTS.md lets an agent understand what you do; an MCPModel Context Protocol — a standard for plugging AI models into tools and data. server lets it actually call your tool. Most sites only need the first. Second — his favorite — ship your docs where the agent already looks, inside the package itself, not only on a docs site nobody (and no agent) reads.
The five-minute version
- Enterprise-ready = the security checklist big orgs require before they can buy: SSOSingle Sign-On — one corporate login instead of yet another password., SCIMAuto-provisioning — the identity provider creates and removes user accounts automatically., RBACRole-Based Access Control — permissions follow roles, not individuals., audit logs, multi-tenancy, compliance.
- The “enterprise chasm” is why loved products stall — enterprises literally can't buy them.
- Most products don't need this yet; building it before you're selling upmarket is a distraction from PMF.
- When you do: RBACRole-Based Access Control — permissions follow roles, not individuals. → audit logs → SSOSingle Sign-On — one corporate login instead of yet another password. → SCIMAuto-provisioning — the identity provider creates and removes user accounts automatically. (SCIMAuto-provisioning — the identity provider creates and removes user accounts automatically. only on request). Avoid on-prem — it chains you to maintaining every version forever.
- The next chasm is agents: static permissions don't work; you need a reasoning layer that grants and revokes access on the fly.
- Make your work agent-findable: /llms.txt + AGENTS.md to be understood, an MCPModel Context Protocol — a standard for plugging AI models into tools and data. server to be called, and docs inside the package.
Watch & read the originals
- Full episode — CodeRabbit · The Merge (YouTube)
- Interactive version — argument, mental models, predictions
- WorkOS — “Your app, Enterprise-Ready”
A personal summary and commentary. The video is embedded from YouTube and short excerpts are quoted for review; all rights to the original conversation belong to CodeRabbit and Michael Grinich. Quotes are lightly cleaned from the auto-generated transcript — follow the timestamps for the exact wording.