Ep. #50, Giving Value to Developers with Matias Woloski of Auth0

Grant Miller: All right, Matias. Thank you so much for joining.

Matias Woloski: Thanks, Grant. Thanks for having me.

Grant: All right, let's dive on in. Tell us about your background and how you got into enterprise software and the foundations for Auth0.

Matias: Yeah, absolutely. Yeah, so Auth0 started in 2013. Before that I founded a consulting company out of university, kind of middle way, and so Auth0 was really my first pro company as a founder. Consulting is a completely different thing, as we all know. You are building for others and small projects and you're not really going all the way.

But it was a great learning and of course it was the reason why I started Auth0 as well. Because we started in 2004, I think it was, this company and we would work for Microsoft and that's how I met my co founder, Eugenio, he was working at a group called Parlance and Practices. Back then Microsoft was trying to get into the enterprise, especially Java was the dominant player, Microsoft released .NET as a way to counter Java becoming... and SQL Server, it was that time.

I learned a lot throughout that time from Microsoft, seeing a big company operate at the level that Microsoft does, and the idea that the product is not just a product. The core, it's much, much bigger than that. In fact I was helping a team that was part of this more than that, it was a team that was evangelizing the platform, that was helping customers to be more successful with the platform.

Which, initially, when we started the company, we don't do that. But seeing that at scale at Microsoft was a big learning. But coming back to how Auth0 started, one of the things that happened throughout that time, from 2004 to 2012 which is when I was working at this company, after that-

Grant: What's the name of that company, by the way?

Matias: The name of the company is South Works. It's a company from Argentina, it still exists. I was in essentially offshore development. It was boutique, our main customer was Microsoft. But anyway, the thing was that after the whole .NET stuff in 2006-7, the whole Azure thing, the Azure wave came in and similarly there was a shift in the way that companies would develop applications now in the cloud and how they could move to the cloud.

It was like a blank canvas, right? One of the things that was more complex about moving to the cloud was identity, how you deal with authentication. Remember, back in the days companies would have their own data center, their own telephone directory deployed, their own web server, and it was this walled garden of Microsoft products or SAP or Oracle. Because of that, the whole authentication was built into the platform and was part of it, so people wouldn't really think about authentication in a company.

Grant: Because you would authenticate through the VPN, right? To get access to the tools, and then it was like that hardened shell, gooey center we talk about from a security perspective where once you're in, the apps didn't need authentication. You already had access to the system, you had access to everything.

Matias: Yeah. The firewall had a big job there, it was a thing that really separated the intranet users from the extranet users. And even without VPN, people go to the office, connect to the LAN, right? Anyway, that was back in the 2000s.

The thing is that with the cloud and with smartphones, that thing changed, employees and people outside the company would try to use the system from the company, and we've all gone through this at some point and it was a mess to deal with that.

Do you put the users in active directory? Do you put it in databases? And now suddenly you start creating silos of users across the organization with different databases, with users and passwords, and similarly with the cloud. Suddenly you own the data center from the cloud so you cannot control what happens there, so that's yet another silo of users. So you see, in a way you need an answer for that problem and with Eugenio, back in the day again working this thing called Parlance and Practices, we said, "Well, let's dive into this whole idea of moving to the cloud and what we need to teach people about."

And so we started first with a book that was called Moving Applications to the Cloud which would explain a lot of these things, but quickly we realized that identity was the biggest subject. So we wrote a book about that specifically. It was called something like An Introduction to Claims Based Identity, something like that. It was really an architectural-

Grant: It sounds like a page turner.

Matias: Yeah, exactly. For me it was kind of a new term, a thing, but really it was an architectural shift on how you would think about authentication and identity. The idea that the authentication process would be embedded in the application, would be to change it to be something that would be outside the application and would be something that you can use from different applications.

The fact that you create this architecture, this authentication service now would live in a different domain, in a central domain where you create a cookie. Then, because of that, every application would trust this centralized application service and you would log in once there and you applications would get the benefit of being logged in already in this central service. That's what essentially means single sign on.

It was this idea of this architectural change that we put in black and white and we explained how you could create that type of service from both sides, the company and from the service consumer and the service provider. Both sides. I think the first company that you would see doing something like this is Salesforce. It was the first company going through this kind of enterprise readiness process.

Grant: Yeah. I think they helped either parts of the Samal spec and Skim and some of these other pieces around user provisioning and deprovisioning. So they were definitely early to that.

Matias: Exactly. Yeah, so we went through that transformation and seeing all that friction and what software was out there to use, active directory, Federation Services, Tivoli IBM and SideMinder. It was really, really complex to set all these up, so that was the scene for starting Auth0, the product, in 2013.

Grant: Okay. So let me just make sure I've got this correct, so you were at this consulting company that you were running. It grew pretty big, right? There's over 100 people there I think today.

Matias: Today it's even more, yeah. But back in the day it was 100 people.

Grant: Yeah, that's a pretty good sized company. I'm sure you learned some lessons there around hiring and managing and keeping people moving forward, so some very applicable lessons as a founder. Another thing too is obviously even just starting your first company is this very scary proposition, kind of like staring into the abyss. So you had done it once from that perspective, and now you were ready to do it from the product perspective, right?

Matias: Exactly.

Grant: And then, I love this because actually you met your co founder because he was a customer and so there's this understanding, one, of the problem. You'd been exploring it together inside as like a Microsoft employee, running partnerships and trying to get more developers to adopt the Microsoft toolset. Then also as the consultant who's helping to build some of those tools?

Matias: Exactly.

Grant: So there's this great alignment, and I'm sure you recognized that each other were good working partners. Where was he based when y'all were getting started?

Matias: He was at the core headquarters in Redmond. That was actually a great test bed for us because we would work remotely back then, I was in Argentina, he was in Redmond.

Grant: Yeah. You were early to the whole remote world, that makes sense. Cool. So then you saw the opportunity around, "Hey, as applications move to the cloud, authentication needs to change." And I always think it's important to point out these platform shifts, right? So clearly the cloud changes architectures, changes how people need to implement the tried and tested ways of doing things before and so now you're saying, "Okay, here's the opportunity. This is a complex problem that people can't solve." What was next? How did you decide that, "We need to build this product around it, start a company around it"? How did you think through that?

Matias: Yeah, of course it wasn't that black and white, as every other startup. In fact we started with the idea of building something like Octa or like One Login if you know those products.

Grant: Sure, yeah.

Matias: Our background was working with enterprises as part of the work we did for Microsoft, as part of my work with this consulting company. We would implement this architecture, this kind of federated identity architecture in companies, big pharma companies and the likes so we would see every different problem that would appear in that context. We ended up creating this first version which was like this dashboard to log into the different apps that you have as a company, and implement this architecture for the company, with a little bit more like a developer kind of feeling to it.

Not just simply plug in Salesforce and this and that, and Samal recipes. So this was the beginning of it, and we had realized quickly as we were talking to customers and potential customers and developers that our big advantage was understanding developers and the idea that we would be solving this integration problem, right? This was not just simply like the idea of giving you the Samal integration. It was beyond that.

Back then the idea was that you would log in with Facebook and Google and this and that, so every one of those integrations... Suddenly developers would have to code. Then you would say, "But also we could help them as well with using their own passwords and the whole email forgot flow." And it was growing from there, we started to realize that there is a lot of value that we could give to developers who are building applications, no matter if those applications are SaaS, internal applications, customer identity portals.

So it was like, "Well, this is actually interesting. Instead of building this single sign on portal, why don't we go a step below that and we think about a building block for developers to do your own?"You could build your single sign on portal, you could build your SaaS application, everything would use these kind of identity platform building blocks and we would make it easy for developers to embed this functionality within your applications.

So that was the real station, the first year of 2013, and of course we had... There was two things that resonated with us and helps us bring forth a product-market fit, it was pretty quick for us to get product-market fit, I have to say. The timing was great, we started when this problem was not obvious but also started to become something needed.

So timing was very important, and then developers, they started to use these services like Stripe and Twilio, so they started to make up their mind in terms of, "I can actually delegate some of these things that are maybe not that core to my business to other companies. Why would I do payment gateways? Or why would I implement SMS gateways?" That idea, so we rode that wave. So yeah, timing. Then there was a third thing as well that was important, in 2010, I think, '11 it was the first password breach, global password breach from PlayStation. Maybe you remember it?

Grant: Yeah, it was a massive one.

Matias: It was a massive one, 700 million accounts were hacked and those passwords were available because they were SH1 hashes and so on. Suddenly that put a perspective on what it means to host and store email passwords and PII from users, so we came in in this 2010, in the middle of those three different factors that were happening. That helped us also bring forth where we have a good thing. But during 2013 we ended up implement and pivoting to this idea of selling to developers and, going back to these two things, one was Twitter.

Twitter developers would be saying, "This is great. Twitter helped me into it with these different structure providers and it's super easy to integrate SDKs and blah, blah, blah." Also some would say about their Samal integration. So we had some bias there, and that we are solving something that definitely is interesting for some people. Then the second one was our first enterprise customer. It was probably like every other company, getting that first enterprise customer is a whole journey and that was also during the first year.

Grant: And so talk about your earliest customers? Who were they? How did you find them? Even before that enterprise customer, were you working with some early vendors. It feels like maybe early on it wasn't just SaaS companies, but more like consumer SaaS as well, folks that were creating apps that you would sign in with Twitter and Facebook and stuff, right?

Matias: Yeah, exactly. It was wholly developers, really. You had the typical hobby developer building something, maybe they're a new startup, maybe a side project. Yeah, they would use us because it would save them time to set up the whole authentication piece. Instead of that, they would just spend the time on the stuff that they were going to do. So that was an initial audience, and in a way, some word of mouth and stuff like that, typical developer go to market motion where those same people who are doing those things as a side project, they typically also have their main job, right?

Grant: A real job, yeah. Which is very unique to developers, if you think about no one in sales or customer success is like, "Oh yeah. The side job where I do my side project. My side hustle is customer success." Like what? That doesn't make any sense, right? So only developers actually practice their craft as a hobby and then do the same thing professionally, so it's this very unique thing about that audience.

Matias: Yeah, totally. It's great. Yeah, it's great that we have this type of thing being, yeah, it helps them experiment, helps us experiment with things. Then like, "Ah, okay. This is cool. Let's take it." And so it's a great feedback loop and virtuous cycle.

Grant: Real quick, those early customers, early developers, you could exclude them if you don't price correctly or if you don't do documentation correctly. So were these things that you really focused on? What were your core... Did you have a hypothesis at that point around, "Hey, here's how we can make sure we attract that audience and retain them"? Was there any like, "Hey, we need to price it low or make it free"? I don't know what you did in the beginning.

Matias: Yeah, it was tricky. Again, we had this first idea where we would sell to employees and so it was like a per employee. That didn't work. But when we started to go to developers, we would look at the... Stripe, their pricing model is awesome because you're charging completely value based. We couldn't do that because we were not a part of the transaction itself. We would be part of the earlier piece of the transaction, so we couldn't do that.

We started looking at pricing by amount of users, there was some other companies doing that, amount of users that you would store in Auth0, it would create... they would sign up. The first configurations of that were very, very manual and we would put something on the website which is like three tiers I think, that typical like, "Free, Standard Version, Pro Version." I think we put in the first version called the enterprise thing as well, "Call Us," type of thing. Nobody called us initially, but as usual--

Grant: But just in case, just in case.

Matias: If someone would like to talk to us, here we are. No, we would do, as you can imagine, support ourselves and we would talk to every customer. We had Intercom back in those days. They actually started to work with us, I remember very well they had this $50 all you can eat plan which was a godsend. Suddenly you could talk to customers, developers through this interface and we learnt a lot, and so our first research on the customer, developer, we memo shared. I remember memo sharing to 24 of us in one, that's what we could pay. We would create a custom plan for him in Stripe and like, "Hey, go here and sign up here."

Grant: Amazing.

Matias: Anyway, so we were doing the math of if we had to make a living out of this, it would take us a lot of developers to have revenue and to live from this. In fact, Eugenio had these contracts signed with his wife on, if in six months he didn't have the similar revenue to what he was making at Microsoft, then he would go back to Microsoft, type of thing.

Grant: Funny.

Matias: Yeah. We were kind of pressured to get revenue, otherwise... We had literally six months, and so let's say we start in 2013, our first self service customers were in March, April, 2013, four month in. Then we got this lucky strike with this enterprise customer, I think every company, startup has to have these lucky strikes. Rene changed his LinkedIn, when now? He started in February, 2013, from Microsoft to CEO, from CEO on, someone from this big company who was part of his network saw that and reached out to him saying, "Hey, congrats on the new job, whatever. Our authentication system is down for two weeks, we don't know what to do, how to fix it. Can you help us with it? Are you doing something like that that can help us?"

And of course we were like, "Yeah, sure. We can help you. We are not going to fix your system but we can give you a product we are working on that would do exactly this."They were using Active Directory, Federation Services. It was a big enterprise insurance company, "We would give it to you and it would do the same thing, it would solve the same problems. We will go out and make it happen for you." Of course that wasn't that easy, but that's how we started that journey of selling to this enterprise customer.

The person that reached out was an enterprise architect in the company, so he was one of those people who has influence but not decision or purchase power, so it was a huge process of selling to that company. It took us from, I think, March to October to make that enterprise deal, and we were lucky because... Well, first of all, this guy saw this LinkedIn change and one of those few people who read those emails of Congratulations.

Grant: And just at the right time for like, "Hey, this is top of mind." He sees this, all the things, yeah.

Matias: Exactly. Yeah, the whole thing was broken, nobody knew how to fix it, Microsoft didn't know how to fix it.

Grant: Funny.

Matias: And Microsoft also did this typical big company thing of consulting services, and they were going to charge you, I don't know, $400,000 and they're going to do this full architecture and it was consulting kind of thing, and plus new licenses and so on.

Grant: It's going to take three years, and you're like, "No, it's down right now. I need something now."

Matias: Exactly. That was the argument, really. Like, "We're going to give it to you for half of that price." I mean, it was a great anchor, by the way. We didn't have a clue of how to price it, going from $24 a month to, whatever, like $200,000 license, we couldn't price that way ourselves so we had this anchor which is what this other company was charging them to rearchitect their system. But it took us a long time to sell to this first company, we had to go through security and all the typical stuff that you go through. We were like five people startup. This is when the on prem version started, actually. Our version back then was running Heroku.

Grant: Interesting.

Matias: And it was the Node.JS and MongoDB, and luckily it was Node.JS and MongoDB because if it would have been something like, I don't know, .Net and SQLServer which was our background, we couldn't have done that easily, I would say. With our architecture, we were able to move this Heroku app to Puppet, it was used back then, Puppet and BeInWork and OBF. Yeah, and we ended up rewriting the thing in three weeks, rearchitecting to make it work on prem.

Grant: Oh wow.

Matias: One of those things that you only do when you're desperate for revenue, right?

Grant: Or when it's part of your overall strategy, who knows?

Matias: So far. Well, yeah. That was the learning of course, it was a learning.

Grant: No, no. I totally get it. At that time you had the idea of like, "Hey, we're a SaaS company and we're going to be a SaaS company and you have a customer that needs a version on prem." Being able to deliver something like that in three weeks is-

Matias: Yeah, and remember that we were on Heroku and we didn't have a lot of people, so it was a decision, right? Like, "Hey, let's do this." And now suddenly it became part of the strategy of like, "Okay, we have this universal platform that can be put anywhere."

Grant: Yeah. I mean it was definitely a very different time from that perspective. Okay, so now you have this big enterprise customer and you had some developers, some were only paying you $24 a month. When did you really start to feel like you had the pull from the market? I remember at some point being on Hacker News or something and people just assuming that Auth0 was like a tool that you would just use, just one of the things you would use to build an app, kind of like Stripe or something else. When did that transition happen?

Matias: Yeah, so this customer we got, we signed them in October, 2013. Then we had a couple of acquisition offers, so it was all at the same time. It seemed that we were solving something that a lot of different people are interested in, like developers, enterprises and investors. We actually didn't raise money until then, we didn't even have experience raising money because our previous stuff was not a startup, and we would serve at the company. So that was what I was telling you for, we had to have revenue because we didn't know how to do this thing in a different way. We didn't have any network of people that we could tap into and ask money. 2013 also was a different time, especially we were from LatAm and the warmness of raising capital wasn't there.

Anyway, the thing is that we got all these signals and acquisition offers and this and that, and there was the initial feeling of that pull from the market, and we declined these offers which was a whole separate chapter. We ended up saying, "Let's go all in and build a company." And we suddenly realized that we need to raise money and we need to go big, because it seems that we were at the right time and doing the right thing, and otherwise someone else is going to do it.

And so we raised money and when you raise money and you do the PR thing, it's kind of like this cycle of Hacker News, and especially back then, there wasn't much. Now there's much more stuff out there, and so harder maybe to get signal, but 2013 still hard but you can start to see, especially for developers, word of mouth and when a company started to get traction and so on you start to feel that. 2014 we started to get more of these inbound requests from enterprises, it was pretty much all inbound. Yeah, that's when we were like, "Okay, then we need to hire a salesperson." Eventually 2015 we raised Series A, high ability of sales and it continued from there.

Grant: Reflecting back, being developer focused on a technical topic that both enterprises and startups are interested in. You talked about pricing for some of these. Was there a free tier that you could use in the beginning or at some point?

Matias: Yeah. We had a free tier, yeah. Absolutely. It was critical for the developer motion.

Grant: Yeah, okay. Because you're not open source either, right? A lot of the other developer motion, often times GitLab or someone else, would focus on open source, so this is a proprietary service with a free tier. How did you differentiate between the free tier plan and the paid plans? Was it about the number of users, about the team size? What were the identifiers there?

Matias: Yeah. We were pretty generous with the free tier, and we've always been and it's still the case. We have 7,000 monthly active users for free, which is a lot. You don't realize how much that is until you start, then you try to do a business that has monthly active users consistently. So 7,000 is a lot, so we always want developers to just try the thing. We didn't have high cost attached to these things. Usually what happened is like probably developers start something, maybe 5% of those things actually pick up, so it's not really very heavy on the load side when you think about the free tier for us.

So we have a generous free tier. The features that were available for the next tier were things like, for example, the whole Samal integration stuff. You would typically want a Samal integration when you actually sell insurance or enterprise customers, so that means that you're really making money. And of course if you have more MIUs then serving self then it also means that you're doing something well. There are some tricky scenarios where B2C, massive amount of users where that starts to become harder.

But more or less that was the thing, and there were features that were turning into the next tier like Samal integration. We have a feature called Custom Database Connections, which is a whole other chapter, but our whole sensibility model also was baked into the system early on. There were learnings from these first enterprise customers when we were trying to deploy the solution to them, they had this issue where they were like, "Well, I like your stuff, but I have all these users in my databases that I cannot just migrate easily because of downtime and blah, blah, blah."

So we came up with a way for instead of doing just web hooks, because this was part of the whole login transaction and there was this synchronous thing, web hooks wouldn't work in this case. So we would allow the customer to write code in the dashboard, in our dashboard, Node.JS code that we would execute on behalf of them to do whatever they want. And so they would connect to their own database, which I think was a SQLServer, whatever, and that was a key thing for us to get into that deal, and where I saw that problem.

Grant: Interesting. So it's kind of almost like a Function as a Service inside of the platform, yeah?

Matias: We didn't call it that way, back then, but it was serverless, it was serverless essentially. We created a Function as a Service engine that would solve that problem, use Docker and stuff back then that was available and that would solve the problem of cold startup and stuff like that. We started using that pattern more and more throughout the code, throughout the pipeline. For example, another requirement that this company had was that they had to connect when the user logged in, they would have to retrieve certain authorization data from another web service that they have.

They had a Soap web service, Soap, I'm talking about early days of the internet and web services. We didn't want to have an integration for web services that was hard coded in the product, and so we did the same thing. We opened up a hole in the code where after the login happened, you could run a piece of code that would enrich the token with more information that would come from wherever you want, it would do whatever you want. It could call some API of yours and return access denied if something happened.

This was a very compelling part of our system, and even today it's one of the big differentiators that we have. I would tell you a big percentage, something like 80, 90% of our customers extend the platform this way. It's been a great tool also for the search engineers. Imagine, suddenly you don't have to ask your pro team to implement this whole web service integration, they could do it on their own, writing the code, which is like writing a script so it was pretty convenient.

Grant: I love that, so that's your great feature that makes your product more extensible, makes it easier for you to integrate into these custom things that folks need, but also just shows how developer focused you were, right?

Matias: Exactly.

Grant: Like, "Hey, this is part of the product that's core." Was documentation something that you focused on early on too? How much of that did you write?

Matias: Yeah. I mean we and Eugenio would write most of it initially. We had a great background by working for Microsoft, this was the big learning at Microsoft, they really paid a lot of attention to that. MSDN was the gold standard back in the days of documentation for Microsoft. But we would write books and have some labs and samples, so we really learned what it meant to be a product for a developer working for Microsoft.

It was a big learning there, and so the documentation aspect, we spent a big amount of time on that. There were two things that we pioneered back then. One was having this quick style selector thingy, you could pick your platform, whatever it is, we have a lot of them. The second thing is that we would tailor the documentation to the API keys that the developer already had created for their account so you would just literally copy paste the code.

You wouldn't have to go and fetch and see what the API key is and this and that. Nobody was doing that back then, so it was a big... That was a thing that developers would say on Twitter, like, "This developer experience is right." Because they would just get it working quickly because they could copy paste stuff. I think Stripe was doing something similar back in the day as well, but we were going all in to that, replacing everything and making really copy pastable.

Grant: I love that, yeah. Throughout that time you're continuing to add new customers and I think what's interesting, I looked at your pricing page now, and you have these different... You price by use case, which is interesting and kind of unusual, right? You price for B2C, you price for B2B, and you have this what I'm going to call internal enterprise pricing as well. So you probably have thought about your product as those different customer use cases and segments throughout that team.

Clearly the developer is still at the foundation of each of those and their experience is quite similar within the use case and the value that you're bringing, because this is a challenge for a lot of companies. It's like, "How do I price for high volume, low ASP consumery folks? And how do I price for lower volume, high ASP type users?" And understand, because any one of those B2B companies, every user is worth a lot more than a B2C company and so the value is different there.

Matias: Exactly. I told you, we started as thinking about this is a platform for developers that could help you solve any use case on the authentication side. But clearly we started selling the product more and more, we would see this segmentation of B2C type of customers, like media or retail, all these companies who would sell to consumers versus the companies who were more like SaaS or companies who would build these partner portals. Then of course the internal single sign on. Initially we didn't want to complicate the pricing model and so we did this single pricing model for whatever scenario you are in.

Over time, like you see now, we separated it and made it more tailored to the use case because of the reasons you say. It's not the same, a B2C user, and a B2B user, from a value point of view, and the same for internal users. But in the early days I think simplicity was the most important piece. The trick here is you can do it essentially by just putting a pricing page, a very simple pricing page and then have the enterprise thing. So when you would call the enterprise and you would have a conversation then, you're in a completely different context and you can have a conversation about your amount of users and if you're in a B2C scenario then you have bigger discounts and so on. So I think we did the right thing in the early days, now we know we evolved it.

Grant: Yeah, that makes sense. Yeah, so you were letting folks raise their hand if the initial pricing model didn't work, right? You'd be like, "Tell us if you need to fix this"?

Matias: Yeah. It's risky because you also can self select out people, but yeah, at the end of the day the market is so big and this is an area every application customer globally has and so it's found.

Grant: Yeah. And so one thing I've heard, listeners, I want to focus here on the story of Auth0 and towards the end I want to make sure we get into a lot more about single sign on and role based ISS control because those are core features of Enterprise Ready, and so I think having your perspective on how to build those would be really interesting. But before we do, I want to focus move from Auth0 to a little bit more on your role there, right? You were co founder, you've been the CTO the whole time, I'm guessing you were managing all of the product and engineering stuff early on. How did your role evolve as the company grew and how do you see your role today?

Matias: Yeah. So I made a few presentations at different conferences about this evolution of the CTO role. You can search that on Google because I actually talk about this journey that I've gone through. CTO Craft is the conference, and also SaaStr I did a presentation about that. The role changes, of course. I'm a creator, I'm a mentor, and that's where my energy comes in. So as any other person that is driven by that, at some point managing a lot of people and having these big organizations, it ends up being something that you don't enjoy as much as being close to creating product.

So from 2013 to, I would say, 2018, so five years I built an organization, design engineering product, security, and I was managing all of that. In 2017 we hired a CSO so that was the first thing that I put off my responsibility. In 2018 we hired a VPO of engineering and so I handed off the whole engineering side of things, and in 2019 we hired our Chief Product Officer so I handed off the whole product. So you say, "Well, what do you do now?" In that process it was also like, "Okay, how do I change my role now and what do I want to do?"And finding my geeky guy again as part of a bigger company. And so I started this office of the CTO which is one way that you could go.

Essentially in every company office of CTO means something else, if you go to VMware you would probably have like, I don't know, 40, 50 people being this field of CTOs that would go to big accounts and help them with their architecture and so on. I didn't want to do that. I love being within the customer core, but that's not what I enjoy doing more. I like building. So the model that we ended up building is these two horizons. Horizon one is 18 months and that's what VP of product, VP of engineering are responsible for. They report to the Chief Product Officer, and I also ended up reporting to a Chief Product Officer instead of reporting to a CEO because that also was eliminating a lot of frictions.

So I focus on the second horizon which is 18+ month roadmap, meaning that I mostly incubate things but they don't see the light for at least a year and a half. There is a whole transition thing happening, and it's quite tricky to make that work in the right way so I have a lot of learnings doing that. But eventually we made it work and we released our first incubated product last year, it's finding authorization, which is Google's Ansible inspired service and that was incubated in this year. It was something that took us a year long to build, talking to customers, engage the community through Discord and it's going back to those early days of building. But in a much better context now because we have customers we can talk to, we have a brand we can use to engage with people, we have dev rails. It's actually a very joyful process to build this way too.

Grant: Okay, I love that. It's an interesting evolution, right? Going from you were running the whole shebang on that side, it's not really what you loved, you were doing it because you had to, right? And then now getting to go in and go build things again, but have the support of the rest of the organization and know that you can experiment. One thing my co founder and I always talk about, and I'm interested on your perspective on this, is the early phases of building something, the zero to one stage, is a lot of zero to .3 and then back to zero, and then to .4 and then throw it all away and back to zero and then build something again.

Then eventually when you get to 1.0, then it's actually as incremental as people would think. It's 1.1, 1.2, on and on and on, but the early days we'll build something and throw it away multiple times and I don't think everybody loves that. I think some folks don't want to see their work, they're like, "I want to plan this out and have this work." So does that resonate for you in terms of how you think about building?

Matias: Yeah, totally. When I started to think about this thing, because in the early days it's like everyone's building everything and you're not even thinking about what you're doing. But once you've gone through the whole cycle of scale and you are in that process, but you are trying to now step back, I started to read about these things and you would find the frameworks from Ken Beck, from a typical S corp of how the software evolves. What you were saying with the incremental piece, and other interesting articles from this guy Wordly, the Wordly apps guy, he wrote an article about pioneers, settlers and town planners which is an interesting analogy for the different type of people that enjoy different things and get energy from different things. The pioneers are okay with this zero to 0.3 and go back to zero, the frustrations of doing that and-

Grant: The whiplash, yeah.

Matias: Not having a lot of customers to talk to because they don't understand actually what you're solving and trying to find that... So those are the pioneers, the ones who land into the island, trying to conquer something that is nothing there. But once something, you build those little houses in there and you start trying to understand where to get food from and so on, the settlers come in and these are the people who know how to scale the system, they know how to build maybe bigger houses and with better materials and so on, and they are okay with other things as well. Like they are okay with incremental value. Then of course you have the town planners who are like the ones who once the whole thing is built and now you need some sort of process and governance for this place and for this product, and that's where...

But the key thing of this article that I think spoke to me is that it says, "There are brilliant pioneers, there are brilliant settlers and there are brilliant town planners." Because sometimes we associate the pioneers and these people are the great people, like the inventors and the brilliants, but the reality is that you need the three of them and you need brilliant people in each of these categories in order to make a company.

But it's important to realize these kinds of different people exist.

Grant: Yeah. Then also acknowledge, sure, clearly you did a great job as a settler as well, right? And even taking it to town planning, but those are not the areas where you really find energy. It was probably more draining for you and more... Yeah, so you can now return to your, not just what are you capable of, but where you're in your inflow, where you find zen.

Matias: Yeah, and unfortunately this is super common. I talk to a lot of CTOs, co founders, because I'm sure you know a lot of people that has gone through it or is going through this, and there is not a lot of material out there. There is not a lot of experience from people on going through this transition and documenting it. It's either you get lost in the organization, eventually you leave, or you stay in this ambiguous role where you're doing something but you actually don't enjoy it much and you keep going, but there is no value in doing that. So I think it's a pretty common thing, and I learned myself throughout the process, for example, I think I should have hired a VP of engineering earlier than I did. But that's what it is.

Grant: Yeah. There's always those key hires you look back on and you're like, "Oh, I wish I would've had this person like three years before I had them. My life would've been better."

Matias: The pain is when you hire that person and it wasn't the right one, and so it's even worse.

Grant: Yeah, sometimes you make a few mistakes and oftentimes it's the organization wasn't ready for that person to come in, and there's different challenges so it's not always that person's fault specifically. But it's that person-organization fit.

Matias: Totally, totally.

Grant: Yeah, it's a thing across the board. To your point around not much content, not much out there about this topic, I think as a CEO I find so much content and so many advisors, so many of our investors can give me advice, and so the one thing that I'm constantly looking for are like, "Hey, my co founder Mark needs this mentorship and advisors and other folks that can give him feedback." And we have a handful of folks that have been really great about that, but we had to actively search it out. Whereas if you're a CEO, everybody has advice for you, it's like all the VCs.

Matias: There are CEO groups. I agree with you. That happened to me. I could never really find a good support group, even though I had the VC, Bessemer would have this meeting every X amount of time where you could meet the CTO. But it wasn't really... I needed someone that had really gone through the whole thing, as a CTO, co founder, that I could relate experiences with. I never had that, so I think there is more people now aware and it's society, right?

Grant: Yeah, and you out there giving talks about it sounds like a great one. I'll make sure my CTO and I both watch it together so we have that context. We were talking a little bit before we started recording and I always joke about the features, the Enterprise Ready features, there's like 11 or 12 of the core features, and two of them, single sign on and role based access control, are very control. Oftentimes single sign on is the first thing that folks will do in order to make their B2B SaaS application or enterprise application more enterprisey.

One of the comments is when people do that they often look at these things like, "Oh, a Samal integration." Or, "Oh, a Google Auth integration." Or, "Some type of integration that allows me to piggyback on some federated login. I can build that in a week or two." But the reality is a lot of these more complex features that you can basically get a working demo done in a week or two, but you don't get any of the nuance and the security and you don't have the experience of knowing what are the gotchas that you might hit and what are going to be the challenges.

And so tools and products that actually solve those problems as a service or for you, I think can be super, super valuable. So when you think about the overall how to build great single sign on, hit on a couple of those gotchas. One thing I do occasionally when I look at it, if you want to find a plethora of gotchas, I often search for some kind of feature plus Hacker One and you can basically read all the authentication and login mistakes that people have made or done, like, "Forgot password Hacker One."

And you see all the security vulnerabilities that people have revealed and you're like, "Don't do that, don't do that." Right? So you basically create a laundry list of things that you shouldn't do by learning what other people have paid bounties on. But I'm curious if you have some of those ideas of things that come to mind around why should folks who are building single sign on and then the advantages of leveraging something like Auth0?

Matias: Yeah. You can probably create lists of 20 things that will happen that you have to take into account when you write these things, and 20, I'm being generous maybe. The key aspect of this is the following, once you grow... because everything is finite and, again, when you're starting your company, you just do whatever, it doesn't matter. You don't want to spend any time on anything. The thing is that when you grow and that's something you learn only when you grow, right? When you became a certain size and so on.

Suddenly every piece of your product will have to have someone who is the watchman for that piece and, sure, you could have a platform team that takes care of the whole thing. But eventually there's going to be a need for changing the authentication piece, there's going to be a need for adding functionality to that thing, there's going to be a need for fixing a security vulnerability to that and countless other things. You will have forgotten who wrote that piece, and if it was you as a CTO, even worse because it means no one attached it.

So at the end of the day, it has to do with that. You want to be prepared for that future and if you assume that you're going to grow and you're going to become bigger, then here you think about the headcount that you will need in five years for the team that would own this piece of functionality. Or you make a smart decision and you just say, "Well, instead of hiring people in the future, I'll just use a service." And of course it's fine to do that later, you can start with your own and then move.

But the reality is that today, with often there's startup plans and there is a lot of ways to start something with a low price, get done with it and make sure that also it's secure, that it's protected from different attacks. It implements all the Samal functionality that you will find down the road of these quirky customers who are using CA Site Minder 3.5 and has this canonicalization algorithm that you never thought about and now, suddenly you have to change the library which you are using for Samal, which is a mess.

Or finding this PR from someone who sent the fix for that problem and now you have to use a fork that is not the main one. Anyway, you get that point, right? That's the main thing to remember, you don't want to be in that position when you grow and so it's better just to generate. In fact, this was the thing early on, when we had our first big, big, big customer, it was Atlassian in 2016. They came to us because there was this mandate across the company for, "Everything that can be outsourced, we should outsource."

That was coming from the cofounders of the company, because they had realized that, yeah, developers are a scarce resource and you don't want to spend those resources in things that there is no differentiation on. In a world where you have enough money and resources to spend on things, then you should just spend it on the right things. Anyway, that was a big learning for me when I was watching that happening. This big company with tons of developers is deciding to outsource such a core piece of their product. Well, that was the realization of when you become big, those are the parameters that you are not having. You need to really focus and use the right people on the right things.

Grant: Yeah. We think about the idea of build versus buy in the same sense, right? Where the idea that you could write it, a crappy version of this in two weeks that's going to have a bunch of gaps, and even if you're okay with those gaps, to your point, if then in a year you need to do something different or someone discovers a security bug and submits it to your Hacker One then is that person still there, number one? Right? Did they leave? Or if they are still there, great, now they have to reload all the context of what they wrote and get back into this.

Whereas if you have a team behind it, well, hopefully they've been updating the platform all along and the company that you are using as a vendor is helping you avoid that problem. But even if a problem does arise, somebody has context, right? And even if it's like, "Hey. Great, I need to update this version or update something," there's a customer success manager who can walk you through that and a support team, and they have all the context already.

So it's funny, I often say particularly within a big company, what you're going to see is they have tons of different applications that they're developing and if, without you, they're using all different forms of authentication and every team's going to do it differently. So by centralizing and standardizing there's a consistent way to do things and then that makes it even more repeatable, and easier for one person to move from one person to another because they don't have to get super familiar with some new tooling.

Matias: Yeah. There is nuance of course, right? We're going through the same thing now with authorization now, right? Like I told you, we're releasing this final authorization service. The nuance here is that sometimes there are open source versions of these things, and that is okay, that is fine and that is great. But yeah, ultimately what happens is that that open source version, still you have to house it, manage it, that's why open source is a successful model because, at the end of the day, you don't want to even spend the time of the dev ops people running this stuff. Unless that is really core to our value proposition, but 95%, 99% of the companies, that's not the case. Yeah.

Grant: Yeah. I know, it's interesting. There's so many of these comment services that, to your point, are non differentiating, that when you look at it you're like, "Do we need this to be something that we own or do we want to try to create value through actual features? Right? Is this the thing that really changes, differentiates us from the rest of the market?"Which often it doesn't, and so that makes sense from the authentication side. Talk more about the new thing that you've built around Rback as well. What's that functionality? When you mention Zanzibar, talk a little bit about what Zanzibar is and give us some context on that new offering.

Matias: Yeah. So in the same way that authentication, in a way we managed to find a way to centralize it through these protocols and standards and OpenAI Connect and now Oauth and JSON with tokens and so on, which it's been great. There is nothing like that in the authorization side of things, right? And everybody who has implemented authorization, it's part of the application. If you did Rback then you have data with a table, with rows in it, with maybe some permissions charted, the ones who implemented it, who realize that they have to decouple role from permissions, then you have users refer to those roles. That is the very, very basic roles story.

You're an admin, you're an editor, you're a whatever, right? And that works, and that's fine. But usually when you start going upmarket and you find more complex domains, like healthcare, actually in every other domain there are complexities and usually the permissions are also attached to other things than simply just roles, the things that you can do in a certain application. You can have permissions based on a certain altitude of a user, which is something that we support. But then you also have concept of hierarchies of things.

For example, in GitHub you have organizations and then that organization has repos, and that organization has groups or teams of users. They may want to give access to one user to a certain repo, to a team, to a certain set of repos, and so you start to visualize this hierarchy of things. Google Docs would be another example where you have folders, the documents and you want to assign permissions to groups or individual users, or groups of groups. So suddenly you have this graph of entities, of principles and resources that you actually want to do Rback in that context, not just simply an editor in this thing.

So there is no standard way of solving that problem, so everyone is solving it again and again, and the guys from Google implement... They implemented this genetic global consistent authorization system across all their products, which is called Google Zanzibar. They realized this is an issue that they would be solving over and over, and so they would factor out the core functionality of each of these different implementations that they have across YouTube, Gmail, Calendar, you name it. Every one of their products has authorization needs, right?

They wrote a paper once, it's an internal system, you cannot use it, you cannot buy it from Google. But they wrote a paper with the ideas and the semantics of this system. Not the technical architecture, but the conceptual architecture of this thing, what is the language for where you can express these hierarchies that I was talking about, the different entities that exist, and the relationship between the different entities? So they wrote that and so we started Auth0 in 2017, so let's say between eight, nine years. To us it felt like, "Okay, we did this with authentication.

I think it's time now for authorization to have it's moment. At least give it a try, we need to give it a try and see if there is a way to optimize and to commoditize this piece of infrastructure and make it available for more people." For developers who usually start with this simple model and then when they go upmarket they had to rewrite their whole authorization system because it was not enough, so we came out with this implementation of Google Zanzibar. It was part of this team that I lead with the office of the CTO, we call it our Cedar Lab. What we did is we started in, let's say, January last year. We started talking to customers, of course we had a lot of customers to talk to because authorization is pretty adjacent to authorization.

Grant: Pretty well aligned.

Matias: We have an offering already for Rback, but it's simple Rback. But we want to learn more, and so we talked to different types of customers and this type of situation, it's very common. They usually have complex authorization systems, but the thing that we wanted to evaluation first and foremost was is this Zanzibar implementation... I mean it works for Google, clearly, the implementation. Could it work for others? And so that was the validation that we were going through, and so we created this playground first where you could go for free, it's a free tool.

You could go and try to model your authorization system, without tons of customers going through that. Initially we had them, we would do a session with them where we would ask them questions and we would map out and so we learned what would be the best way to express the authorization model. We came out with a better kind of semantics for the language than what Google provided. And so we started learning, okay, what are the things that we need to solve in the domain?

And we created these different kind of artifacts for this service, and we did a release and we opened it up more now to developers. There's a developer community preview that we put out there, and so now anyone can go and try it out and build our authorization system with it. Yeah, eventually we'll go GA sometime hopefully this year for enterprise customers, and that's the process, going back to the previous question, the model for the CTO who wants to continue to build. This is an example of that.

Grant: Yeah. That's really interesting, hearing that research phase, development phase, early access and then a beta, and then GA process. Yeah, one, it's super important for companies to be able to do that as they scale and grow. But two, in terms of this, you mentioned some differences between this offering and Rback offering you have, when you think about what... You mentioned maybe Rback in your mind is a little bit more narrow, it's more about users and permissions and less about the hierarchy of actual objects. Is that right?

Matias: Yeah, exactly. So you can model more complex domains, essentially. So going back to GitHub as an example, you have repos, you have organizations that have teams, and inside those repos you might even have more fine grain entities that you want to manage. But I think repos is the lowest denominator there. So the way that GitHub solves it today is likely storing everything in a data as attached to the repo ID, and so the roles and everything ends up being in a data table. The moment that you start having more systems that depend on that information, now you depend on that table where you store all this.

So the idea of this system, of this authorization service that is global and accessible for all applications is that you think about your model in a central way, in a single place, right? Then every application can consume that. It's kind of like singular for authorization micro services, beyond just what role is Grant in? It's like, "What permissions does Grant have for this resource?" It's one more. You could belong to some hierarchy that gives you access because you belong to that hierarchy, and similar too in the resources side of things.

Maybe there is a collection of repositories that they altogether has management permissions associated to that. There is a lot of examples like this in the real world, for example, a company that sells publications, research publications, the paper, and they sell typically in collections of papers of a certain topic and so they want to give access to different collections to different people and different teams inside the organizations, instead of single persons. Anyway, essentially it's a system that allows you to model those type of things.

Grant: Yeah, that makes sense. I think the key difference there for me is identifying that it's not just about users and what are their access permissions broadly, but it's being able to take that and pairing it with a grouping hierarchy of resources and saying... that way there's some inheritance that you can have across both sides, but really the matching making it really important. That's cool.

Matias: Yeah. And of course it's like everything else, it's like, "Well, this is an API that solves this problem for you." But then if you think about all these logs for example, this also can give you that, all the level, out of the box for every ACL check that happen or every change in the permissions system. Or when you want to change your permission system because now it's something else. That's a very big engineering project usually, when you want to change your authorization system. And so this thing has constant versioning built in.

Yeah, the thing that it also solves for you is the fact that now you have a central authorization service that is used across all your applications, systems, services, whatever, is that you get all the things out of the box, you get versioning which is also a big problem usually when you want to change your authorization domain model. That is not an easy change, you want to do it in a way that you do shadow type of start issues, where you start trying and see if your model replies the same thing now or it changed the answer. And so we thought about all those stuff as well, the things that you typically end up doing when you're solving authorization at scale.

Grant: That makes sense. You mentioned a DSL, some kind of way to set all of this up right. Is it a custom DSL or did you model it after anything? Can you pour it in a manifest? Is that what you use to version this across, if you want to version control how you set this all up?

Matias: Yeah, that's right. Yeah, you have. Initially we surveyed the dreaded YAML, of course. I think Google actually also does Yamal in that paper. But yeah, once we started talking to customers, it was very hard to broke and to understand what's going on when you are reading this, and we ended up with our own little language that would allow you to express a lot of these things but in much simpler, natural language way. You can look at it in the Playrun we have, I think it's http://play.fga.dev. Yeah, you would see there different examples of authorization models, we have GitHub, we have Grail, we have an IoT example, Slack, Slack with channels and all sorts of things, entitlements and so on.

Grant: It's funny you call it the DSL, the Domain Specific Language. I like it. So as a developer, I would version control this either as JSON or as a DSL and then I would move that along into different environments.

Matias: Yeah, exactly.

Grant: It's cool. So this is pretty new? When did you launch it?

Matias: Yeah. We launched it in I think December, and as part of the building the thing throughout the 2021, we also engaged with the community. That was interesting, going back to building product in 2021, right? When I was doing it there was no concept of Discord, for example, or community. Where you would find the community of developers? Maybe Twitter, maybe Hacker News, maybe. But now you have these chats that people can join and it was great because we were ready to have a channel with a community where we would discuss things, and in a similar way that the open source happens. We would talk about things and discuss and tell people when we would release something new, and it was great to go back to that kind of motion.

Grant: Interesting, yeah. I just saw the community. I guess it's another interesting insight for folks who are building developer based companies, the idea of using Discord to really build community and let folks connect. You found that to be pretty successful?

Matias: Yeah. It's yet another way to learn. When you are building a product, you want to optimize for learning and learning comes in different ways from... Again, in our case we were going to talk to developers who had gone through this problem, who has implemented something like this, so we would have different sources of those developers. Of course our customers are one of those sources.

You don't want to disrupt them and ask them all the time for help, but you typically find these core customers that they are really desperate for a type of solution like this and they would give you time. But you also want to find developers who are developers who maybe have more time in their hands and they're interested in these things as well, and so by engaging these people as well you also have different type of input. But yeah, most importantly is how do you learn faster and more?

Grant: Yeah, and from a wide variety of target users, right? You don't want just one profile. I mean, think about your use cases, you have those three different profiles pretty clear so that's great. Well, yes. Anything that we missed here? Anything else you want to chime in with?

Matias: Yeah, I guess the only thing that we didn't touch on is Auth0 become merged with Octa in March last year, and so it's been a little bit of a change. But yeah, that's been a ride now. It's been a year almost.

Grant: Yeah, huge acquisition. I remember at the time it was pretty well received in the markets, so was it a $6.5 billion acquisition? Is that right?

Matias: Yeah, that's right.

Grant: That's huge. Yeah, congrats on that. I'm sure, one, it seems like a great fit for an acquirer. To your point, more of a merger because it's like two different ends of the spectrum in terms of solving different parts of the problem, and being able to bring those together I think can be better for both the end user or the service provider and the service consumer. I'm sure it's been a great combo.

Matias: Yeah. When we were thinking about it, and by the way, this acquisition, I think there is a whole chapter around acquisitions for founders, how you think about the acquisition. We got a lot of offers throughout the different years. In fact Octa tried to acquire us since 2017, the first year. Every year we would talk to Todd and exchange notes.

Grant: It reminds me of PayPal and eBay. eBay tried to acquire PayPal six times and the price just kept getting higher and higher and eventually they were like, "We just got to buy it. We don't care the price. Give it to us."

Matias: Yeah, it's a little bit like that. Of course it makes a lot of sense for Octa. In fact, they would say we wouldn't have sold the company really. We would've gone in IPO, but the only company that we said, "This will be it, because it will be very strategic for them and for us, it would be great also for customers and the potential impact that we can have."

Because at the end of the day, if you think about this idea of the two ends of the same pipe, they sell their product mostly to IT organizations who are connecting to SaaS applications, they want to do things that sign on between those applications, and we sign to the ones writing those applications.

So those developers who have the power to change the fabric between the one or the other, and if you think now of the final authorization service I was talking about, or authentication, by having this system in place and this domain specified in a certain way, we could make, if you use Octa on one side and Auth0 on the other, now we could have all sorts of efficiencies in the channel because we know that you are using a certain thing.

And so make the life easier now for the IT people but also for the developers and also for the end user, at the end of the day. That's where the mission thing is exciting because we want to enable that type of thing, use anything eventually by any person in the most efficient way. That is only possible when you have this type of thing in hand, and that's what made us say, "Okay, this could actually be good for users and customers if you do it in a way also that would promote standards and not just..." It would only work between Octa and Auth0, right? And that's the spirit of the company.

Grant: I love that. Yeah, it's one of those companies I've always had a lot of respect for, I think a lot of folks do. So again, very, very excited for that and I'm sure you've got some stories as part of those acquisitions, right? The interesting overtures and probably too because they've always been a key partner, right? You've always probably worked with them, integrated with their things, and so there's always this proximity and I'm guessing the markets being pretty generous over the last... throughout the pandemic were a nice way for them to feel like, "Okay, we have to take advantage of where we are today and the multiples that we have and really try to build this business out." So I'm sure it was a good move.

Matias: Yeah, it's been a great journey. Of course integrations are complex and there is people involved and it's not all roses when you do these type of things, but there are some key learnings and aspects of situations like this that make things better. But the main and most important thing is to be aligned on the mission, and also become part of a company who really wants that thing. That's a key piece, and Todd the CEO really wanted to have this, research for IT, research for developers and it's a DNA that you have to bond with, right? And they bond with the IT DNA, CSA mainly, the whole CSO, CIO side of the house and we bond with the developer, CTO, VP of engineering. But most importantly I think the way that we think of our customers and the values that we both share is what makes things work or not. Yeah, so far it's been a good journey.

Grant: I love it. Well, Matias, thank you so much. I know we're running up on the end of our time here. We had a hard stop. But amazing, really, really appreciate your time and your being so open with us and sharing the back story and then how things are going, what you've been up to. So this was great.

Matias: Absolutely. Thanks, Grant. Thanks for the great podcast, and we'll be in touch.