Getting Your first Enterprise Customers - Michael Grinich from WorkOS
Michael Grinich's talk on "crossing the enterprise chasm" was written the night before he gave it, three months after WorkOS launched. Five years later, he says it's eerily close to what the company still does — because it was built around a problem, not a solution.
Michael Grinich is the founder and CEO of WorkOS, a developer platform that helps startups add the enterprise features — SSO, SAML, directory sync, audit logs — that big customers ask for before they'll sign a contract.
We get into what actually counts as an 'enterprise customer,' why the founder has to do the first sales themselves and can't outsource finding product-market fit, how great salespeople spend 90% of a call asking questions instead of pitching, and why the size of a contract determines whether a sales team is even viable.
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.
What does WorkOS actually do?
WorkOS is a developer platform focused on helping people building apps add enterprise features. If you build the next great SaaS tool and want to sell it to a big company, they're going to ask for things like SAML login, single sign-on, sophisticated user management and provisioning, and security features — everything around authentication, identity, and user management. We build all of that as a service, which is why some people have called us the Stripe for enterprise features. We're about five years old, with hundreds of customers including Vercel, Netlify, PlanetScale, Webflow, Carta, and Brex, alongside a lot of smaller startups that are just starting to close their first enterprise deals.
What actually counts as an 'enterprise customer'? That feels like it means different things to different people.
Imagine two people starting to build an app, maybe in a coffee shop or a dorm room, like Drew and Arash starting Dropbox. You demo it on Hacker News, get some users, and start finding product-market fit — people bring it to work, small teams start paying. At some point a larger organization wants to use it, and the login and permissions features you built for individuals aren't sufficient anymore. They'll say things like: we can't have a custom password, tie into our identity system instead, or we need groups and permissions synced from our own system. That list of missing features piles up, and it slows you down right when you have product-market fit and are trying to close deals. We call that gap the enterprise chasm — the worst outcome is losing those customers to a bigger competitor, like Microsoft cloning your feature and taking your users, because you couldn't cross it in time.
Is WorkOS the only thing a startup needs once they start going up market?
No. SOC 2 compliance, for example, isn't a feature in your app — it's about how your company operates: how you release code, how you handle security issues, whether you do background checks. Vanta helps with that, but it's not something WorkOS does. You'll also need to rethink pricing as you go up market, deciding what goes in an enterprise tier versus a pro or business tier — that's a distinction you have to work out yourself. And bigger organizations often won't just put in a credit card; they want to talk to somebody before committing $100,000 a year, which means you'll eventually need salespeople too.
How much revenue do you actually need before hiring a dedicated salesperson makes sense?
It really depends on the business — we have customers paying us well over $100,000 a year purely self-serve on a credit card, and other customers at a much smaller scale who insist on a signed annual contract. As a rule of thumb, salespeople are typically paid around 18-22% of the first year's contract value, so it's hard to support a dedicated salesperson with contracts under about $20-30k a year — below that, deals have to close fast with very little time invested, or it just doesn't pencil out. Things really start working, and you can attract genuinely great salespeople, once contracts are in the $50-60k-plus range, where there's room for real strategic selling.
You've described great sales as almost magical. What does that actually look like?
Most people think of sales as value extraction — someone trying to squeeze as many dollars out of you as possible, and those salespeople definitely exist. But the really good ones spend maybe 90% of a call asking questions: tell me about your business, what are you trying to achieve this year, what have you tried and not tried. Only once they understand your actual problem do they talk about the product, and sometimes they'll even ask how valuable solving that specific problem would be to you before pitching anything. That reframes the whole interaction from value extraction into problem solving — genuinely good salespeople are extraordinarily curious and empathetic, and the really good ones will tell you outright, at the end of a call, if their product isn't actually the right fit for you. When it's done well, it feels almost supernatural to watch.
Once a founder has their first customer and wants to go after enterprise clients, what's your advice?
First, we don't help you get product-market fit — that's genuinely hard, more like catching lightning in a jar, and there's no repeatable process for it. Once you have it, even an early version of it, we have a free auth system that gets you the login box and basic infrastructure up to a million users, so you can use it from day one. People typically start paying for the commercial side of WorkOS once their first few enterprise customers start knocking — which for some companies happens in the first month, and for others takes a couple of years, depending entirely on how they launch and acquire customers.
Can a founder just hire a good salesperson to figure out enterprise sales for them?
No — and I think a lot of founders get this wrong. Any founder who says they can't do sales is wrong; you've been doing sales since day one, whether it's hiring people to join the team, raising money, or convincing a customer to get on a call. Discovering how to actually sell the product is part of finding product-market fit, and that responsibility can't be handed to somebody else — I've never seen a company successfully hire sales talent to figure out the initial sale. The right time to hire is once you've figured it out yourself and simply don't have enough hours in the day to keep having the same successful conversation over and over — that's when you scale it out, and later you might bring in a sales leader to professionalize the motion further.
What was that early period actually like for WorkOS, finding product-market fit and doing all the sales yourself?
Developer tools are unusual in that it often takes a long time for customers to mature into needing you — someone might say this sounds great but they don't need it yet, and you just have to wait for them to grow into it. Our revenue was quite minimal for the first two or three years; it grew steadily but started slow, which is really common for developer and SaaS products generally, even though it's tempting to compare yourself to something like ChatGPT's growth curve. That probably means you should raise more money than you'd expect, just to buy yourself a longer, more patient time horizon, since early selling is really about learning what customers value, not maximizing revenue immediately. I spent a lot of that time just talking to founders, going to events where other SaaS founders hung out, going to conferences — my friends were probably sick of hearing me talk about WorkOS.
You gave a talk called 'Crossing the Enterprise Chasm' when the company was only a few months old. How does it hold up now?
I gave that talk at GitHub's office at a startup event, put together literally the night before, when the company was maybe three or four months old and had just raised a little money. Watching it back now, it's remarkably consistent with what we're actually doing five years later — almost eerily similar. I think that's because we centered the company around a problem, not a specific solution. There's an idea I heard a long time ago that stuck with me: fall in love with the problem space, not your specific solution, because your solution might be wrong. If you fall in love with the exact feature or app you've built, you won't want to adapt when you need to, and your aspirations will die. I see a lot of entrepreneurs do the opposite — build some technology first, then go searching for problems it might solve. I think staying laser-focused on a single problem while staying flexible on the solution is far more durable.
Do you find the underlying problem — enterprise identity and access — gets simpler the deeper you go, or more complex?
More complex — it's like a fractal, the closer you zoom in, the more detail you find. That's actually why it's interesting. People sometimes ask why I'd want to work on something as dry-sounding as enterprise APIs and SaaS auth, but if you build it as a platform rather than a one-off, thinking about the whole category rather than a single company's need, it becomes genuinely fun, because you can go deeper and more rigorously than anyone else has before. We have a narrow enough problem that we can go all the way to bedrock on it, sustainably, and keep making money while we do.
You've spent time both in sales and in engineering. What do you think makes developers such a rewarding audience to build for?
When you build infrastructure and tools for other developers and engineers, they're the most discerning customer — they care about tiny details — but if you get it right, they become ruthlessly loyal and will defend what you've built. I fell into building for developers somewhat by accident at my first company, an email API, and found it's sort of the pinnacle of engineering to build for other makers. I think the deeper point is you should be really deliberate about who you build for, because as a founder you'll spend a tremendous amount of time talking to your customers, every day, for years — if you don't love the people you're building for, that's going to wear on you badly. If you love hanging out with doctors, build for doctors; if you grew up on a farm and love agriculture, build tech for farmers. I've gotten to spend my career talking to other engineers and other founders, and that's one of the best parts of the job.
What advice would you give an early-stage dev tool founder beyond falling in love with the problem and the people?
Startups are genuinely, brutally hard, and you don't really feel that until you're in it — everyone hears that going in, but it doesn't land until it happens to you. I think the thing that helps is cultivating a mindset where you embrace the struggle rather than treating it as something to avoid or feeling like a victim when things get tough — thinking, this is what I signed up for, this is where the value is being created. Most people underestimate how hard it's supposed to be and assume something's wrong when it's this difficult. It's not supposed to be easy; that's exactly why not everyone does it. Every success I've seen has come through that struggle — it's part of the job, not a sign you're doing it wrong, and if you lean into it, and get a bit lucky, you might get the chance to build something really great.
Links & references
This episode is brought to you by WorkOS.