Mandy MooreOr Weis is a Founder, CEO, and serial entrepreneur. His latest venture Permit.io has just raised a $6 million seed funding round.
In this episode, Or talks with host, Aaron Bassett about working in Intelligence Corps in the military and focusing on development around cybersecurity, how when building anything significant in the world, if it has actual impact, it requires a lot of effort, and how as an entrepreneur, it's always great to create products in which you have empathy for your users. Understand your users.
Links:
Permit.io (Twitter | LinkedIn)
Or Weis: Twitter | LinkedIn
Do you have ideas about how we can make our show better? Or would you like to be a guest on an upcoming episode? Reach out to our #devrel team at devrel@newrelic.com. We would LOVE to hear from you with any questions, curiosities, and/or feedback you have in hopes of making this the best show possible!
Give us a follow: @PolyglotShow
Transcript:
Aaron Bassett: Hello, everyone, and welcome to another episode of the Polyglot Podcast. I'm joined this week by Or Weis. Or is a Founder and CEO, and serial entrepreneur. And his latest venture Permit.io has just raised a $6 million seed funding round. Hello and welcome to the show, Or.
Or Weis: Hi, Aaron, it's great to be here. I'm excited to talk with you.
Aaron: Hi, good to have you. I know we were just chatting a little bit there before we actually started recording. And we were already starting to get into some of the answers to these questions. So I can tell even before we probably get into it, it's going to be a really fun conversation. Was that a fair intro for me to call you a serial entrepreneur?
Or: Yeah, if I like it or not, that's kind of the situation I'm in. I find myself constantly starting new projects, starting new companies. I do think I bring them to a significant level of growth. But I should probably start to focus more on the growth stage than starting new things stage. But it's just so fun starting new stuff.
Aaron: Oh, I am 100% there with you. Yeah, it's a bit of an issue of mine as well. I really enjoy that ideation and that excitement you get from starting something new. But yeah, I don't mean to say serial entrepreneur in a negative way. The companies that you've founded they have gone to be very successful, like Permit.io with the seed funding round.
Or: I'm obviously a bit tongue in cheek with that statement.
Aaron: [laughs]
Or: But yeah, still, I think I can do more. That's kind of the mindset I'm in now. I want to reach the stars or, as Steve Jobs said, leave my mark on the universe. But we'll have to wait and see.
Aaron: [laughs] Okay, we can go into the different companies you started in a second. But let's go right way back to the beginning then. So what got you interested initially in tech?
Or: Well, I basically got interested in tech without actually being interested or aware that I'm going into tech. Very early on, my parents and my sister, my older sister, kind of got me working with computers. I basically had been almost writing code at the age of five.
Aaron: Oh wow.
Or: In elementary school. And then, in junior high, I started getting into building websites and small applications and playing with Visual Basic. And without really knowing it, it became a key part of things that I do, a big passion of mine. So I can barely remember myself not working on tech and software.
Aaron: [laughs] So what was the first computer you had then?
Or: An IBM computer, I think it was like a 386.
Aaron: Wow. It is going back a while.
Or: Yeah, it's not like a Commodore or anything like that but still pretty, pretty basic. It only had DOS. And the first things that I learned to do were like DOS commands because there were games I wanted to play. So I had to know how to insert the floppy disk run and install. And I barely knew how to talk or to communicate fluently. [laughs] But I already knew how to type the commands and that I guess was a good kick-start.
Aaron: It's such a common kind of way people get into programming. It seems to be either they wanted to run games off of floppy disks, or they wanted to customize their Myspace page. That's the two ways when I talk to people in my generation [laughs] about how they got into programming. That comes up a lot.
Or: Yeah, the next big step, if we can call it that, was starting to build websites on GeoCities. Remember that?
Aaron: Yeah. [laughs]
Or: So that's even before MySpace. And there was no drag and drop. You had to write code to make any of that work. And I remember working with Visual Basic then. JavaScript wasn't even mature enough at that point in time. It's an interesting flashback to think how premature and how unorganized the entire web was, but it was still fun and things kind of worked. And we had that thing tracking your cursor on the website and all these kinds of silly things that I just found fun as a child.
And from there, I kind of got deeper into coding. I learned C and C++ and started building more games and stuff like that. Again, it was still more of a hobby. I can only say that I really got serious about tech and really just started to understand technology when I got drafted into the military and served in the Intelligence Corps. That was really, I think, a really significant milestone in my career, turning me from like a snot-nosed kid that plays…and does a bit of hacking into a full-blown developer.
Aaron: Sure. And so your time in the military then was your focus then on application development, or was it the tools you interacted with? What really sparked that change then from a hobbyist to a --
Or: I actually can't say too much. Well, I can tell you, but I'll have to kill you.
Aaron: [laughs]
Or: But what I can say is I worked in the Intelligence Corps. So the Intelligence Corps is obviously responsible for collecting intelligence. And I focused a lot on development around cybersecurity. I had the good fortune of working on significant projects that had, at the end of the day, amazing impact on lives, on the geopolitical situation. And in all cases, things that I look back in retrospect, I was like, that's part of a science fiction novel or a movie or something. And that really opened up my eyes to what is possible, what you realize is possible, and what actually is possible.
There's a talk I gave a few years ago back in San Francisco in ObservabilityCON. I talked about high stakes and high stacks. And there, I covered a project that I worked on where we had a limited set of opportunities to deploy to production, which is really where when you think about the cloud nowadays, everything is CI/CD. You constantly end up deploying again and again. It's almost transparent. So think about a project where people come and tell you, "You only have four opportunities, that's it. If you don't get it by the fourth time, it's done; people are going to die."
And we ended up having obviously bugs and errors in our code and having to debug those with bits and glimpses of information. For people looking, you can find this talk on YouTube if you want the full story. But again, experiences like that both kind of enabled me to see how deep you can go with software, the big impact that it can have. And also working with really challenging stuff like basically putting your head to the wall; you either get this right now, or you never will, and there are significant consequences, on average tends to get the best out of people. So it really changed the way I'm able to work with software.
Aaron: I've never been in that situation military-wise. I have worked in the public sector before. And it is a completely different way of working as you said. There's so much siloed information. There's so much you have access to and don't have access to and deployment and things. It's just so, so different to anywhere else, any other situation I've ever had to work in.
It does, whenever you come out of that, at least for me, whenever I came out of that kind of environment, we'd be very grateful for the almost free-flowing CI and CD that we would have in the public sector. But yeah, it's different stakes involved. And that's why the checks and balances they have are there, I guess. So once you came out of the military...how long was your military service? I'm sorry, I don't know anything about the drafting.
Or: So it's a mandatory three-year service. Now it's like two years, almost three years. But when I was there, it was exactly three years. And I did an additional three years. So I did a bit over six actually, so six years in total. Some of them is just a grunt worker or a junior developer in some cases, if you want to describe it that way.
Aaron: [laughs]
Or: And other parts of it as an officer and a team lead and kind of more senior developer, I guess. And also, I find it hard to convey to an American audience often because they don't really have similar experiences. So this is the age where in the United States you go to college, and it's like college is obviously a much more relaxed environment, usually more relaxed than high school. So for us, it's vice versa. They take you out of high school and just throw you directly into bootcamp, and bootcamp is very strict.
Aaron: [laughs]
Or: The purpose of bootcamp is to basically break you as a person and reshape you into something that the military can actually work with, and it's a generic grinder. No matter who you are, you go through the same steps, the same yells, the same exercises, the same everything, the same using a rifle kind of practice. And when I did my service, I had occasions where I was doing very advanced software work.
But at the same time, they will tell me, "Oh, the Prime Minister is waiting on the result of this project. This is the highest priority." And with the same breath, another person, another officer would come into the room and say, "We need another person for guard duty. So you're off this project for two weeks. Go stand on top of a hill with a rifle and guard something," in the middle of nowhere. So it's very weird. It's not something that I find easy to convey or give examples to. But it's a unique experience, and I think it's, to say the least, it's kind of character building, I think.
Aaron: Sure. And did you find then whenever you left the military, transferring that knowledge and that experience into the private sector was that easy for you to do? Was it difficult?
Or: Oh, well, it's definitely difficult. Building anything significant in the world, no matter why you do if it has actual impact, requires a lot of effort. It's not a walk in the park. But I think a lot of the experience I gained there aside from giving me really significant skills and tools that I can work with it gave me and other people that served with me in 8200 and similar units that unique perspective on what is feasible and what you can do if you set your hearts and mind to it.
And maybe I can give you another example here. So I had the good fortune of, during my service, to also work with some American counterparts. And we were working essentially on the same project from two different sides initially without knowing it and then ending up through relations talking about the project. And it was very apparent the different perspective each organization has. So most intelligence, I won't name specific names, but most intelligence American organizations have impressive budgets.
Aaron: [laughs]
Or: The Intelligence Corps in the IDF has a decent budget, but it doesn't compare, to say the least. And so we were like, "Yeah, we were trying to get that piece of software. So we were hacking their..." hacking like building software. "And we were inventing new protocols and stuff just trying to replicate that element." And our counterpart on the American side said, "Oh, we just bought the company that produces that."
Aaron: [laughs]
Or: But that mentality of no matter what, we'll be able to fashion a solution for a technical problem with the least amount of resources really paints a picture of you can do anything if you set your heart and mind to it. And I think, as I said before, so it's hard no matter if you are going to work in a startup or you're going to start your own company. It's going to be hard.
But if you have that basic belief that you can do it and you have the realization that there are bigger challenges and you might have already solved them in the past, it gives you the perspective and alignment I think to get down to it and be to some degree fearless and just jump in and get the job done.
Aaron: I used to get asked a lot when I worked in agencies if, you know, "Is this possible? Can we do this?" And so it was like, yeah, you give me unlimited time and unlimited budget, and I can do whatever you need me to do, [laughs] which seems to be a very American response from what you're saying. But you came out of the military back into the private sector. Did you immediately jump into running your own companies then, or how did that get started?
Or: So I joined a startup as the first employee. I knew that I wanted to start my own company. I knew it even before I got drafted. It was, for some reason, kind of engraved into my mind that that's something that I should do. And the service in the military only strengthened that. But I was cognizant enough of the challenge and how different of a world it is that I said, oh, I should probably join a company first, a startup, and see how this kind of thing even looks like before just going running blindly into the battlefield.
And so I joined a young company as the first employee, as the first developer, along with another friend. So we were both two first engineers there, a company called Intigua. It kind of pivoted and changed to a different company called JetPatch. But anyways, back in the day, we were essentially building containers before containers were a thing but with a really bad go-to-market as compared to Docker, for example, that ended up eating the market.
So I joined that company, and we built some really crazy technology there. So we basically implemented containers through RPC to other virtual machines. There weren't jails or containers in the Linux kernel at that point in time. So we just used another machine as kind of the encapsulation there for that. So the tech was pretty amazing. We were doing RPC hooks and RPC calls and re-compiling applications on the fly to basically produce that, but it was definitely an overkill.
And in the end, the far simpler solution won. And I think that's one of the downsides I think coming from...so I gave a bit of praise for the advantages of Israeli tech perspective. I think a downside of that perspective is overdoing it. A lot of times, a good, simple product with good marketing can take you a far longer way than a very advanced product with capabilities with poor marketing. So that was an important lesson.
But I worked with some really great people in that company. That other employee that I mentioned ended up co-founding Solo.io, which is a significant player in the service mesh space today. And the CTO of that company ended up founding another company called Logz.io which is also a significant player in the space. And there are a bunch of other good people that worked with me in that company. I won't mention all of them just for the sake of time.
Aaron: [laughs]
Or: And after that, I started a startup called Reactful that is still ongoing, but it's kind of small. And I don't feel passionate about it enough to go into it, but it's still live. People can go to reactful.com and see it. And afterwards, I got back to the industry. And I worked as a freelancer and then as a VP of R&D in a cybersecurity company called Netline, where I reminisced back to my days in the army and worked on security projects for governments and like-minded agencies.
I'm really happy to say that I only worked on defensive projects as opposed to offensive ones, especially with today's news. I always felt that offensive cyber capabilities are essentially weapons, and they shouldn't be commercialized, at least not without very significant regulation. And I think we're starting to see the outcome of that regulation missing. We're starting to see it in the public space now.
Aaron: Yeah, they are weapons. So it's good, as you said, that we're seeing some of the regulation come through for them.
Or: It's not quite there yet, though.
Aaron: Yeah, yeah, it's not. It's very much...and there's still a lot of work to be done there. But it's good to see it's starting and being recognized for what it is. Before we get into the actual projects themselves at the companies you started, which I do want to expand upon, looking at them, they all sit in this Platform as a Service kind of sphere. Was that intentional or accidental?
Or: Maybe that lesson I learned with Intigua, that first company that had great tech but poor go-to-market. I think that really kind of encouraged me, especially looking at how go-to-market evolves today, to really go for models that give you an advantage in how you interact with your customers, especially coming out of Israel. The more you need to depend on complex sales cycles; you're in a disadvantage compared to other players that are closer to the market.
Aaron: Sure.
Or: So adopting things that can remove friction, that can speed up the sales cycle, that can speed up the adoption cycle are something that just makes a lot of sense to me. And I think especially combining that with modern trends like product-led growth, PLG, I think it's just the way to go. This is where all the market funnels are aiming towards. And the other side of that is the audience that I decided to cater to.
I feel as an entrepreneur; it's always great to create products that you have empathy for their users, that you understand their users. Ideally, you are the user. So I find myself mostly catering to our developers. And developers love infrastructure platforms, software platforms that they can build on. So that's what I ended up building. And the combination of giving quick access to that and enabling developers on that that's just my sweet spot.
Aaron: Yeah, there is that old advice of you write what you know. I think that applies here as well as it does for authorship, even for myself. I've been in developer relations for quite some time now. And I tend to go towards companies that are CPaaS or Platform as a Service type companies because that's what I know and what I enjoy working with. And if I'm going to be an advocate for something, it's going to have to be something that I enjoy. So yeah, I can definitely see how that would work as well for founding your companies. So let's talk about one of your first companies, then, Rookout. What was your elevator pitch for it?
Or: Working at Netline as a VP of R&D, I was really frustrated when we started to adopt more cloud development, and more containers, and Kubernetes, and flows like that. I was really frustrated with developers coming back to me and saying, "Really, I had my heart set on finishing the task you assigned to me today, but I ended up just not being able to debug it because it's running in a container in the cloud. And it was too complicated to get a glimpse of what's going on there. And so I wasn't able to finish the task today."
And I was like, why is this so complicated? It used to be so easy. I had the code running on my machine. I could set a breakpoint and see exactly what's going on, but now I can't, and that's super frustrating. We got all that power, but we lost that basic intimacy with our software. So that was like the basic aha moment or pain moment for myself that I was experiencing. I was like, I want to get rid of this. I want to get the ability to debug software in the cloud as if it's running locally. And that was kind of the basic idea for Rookout.
And the pitch there was like production debugging in observability. So you're getting all of these alerts from great solutions like New Relic and your log solutions. But at the end of the day, you need to get to how the code is behaving, not just the alert that just happened. You need to see what the code is doing in order to fix it. And so you can reiterate and add more logs, but that's both a risky process and a time-consuming process.
So what we offer you instead is non-breaking breakpoints, and as an experienced developer, you already know how to set a breakpoint. So it's the same thing, same interference only now it's running in production but in a way that doesn't stop. It doesn't hinder your production. It doesn't slow it down. But it gives you whichever values or variables, new log lines, traces, whatever you want, instantly on your screen without having to restart, redeploy, or write any more code. So that's kind of the offering there with Rookout.
And it essentially created a new category, the production debugging space. There are like maybe four, maybe even five companies now in that space. I'm kind of happy to say that Rookout was a significant element in starting that space, maybe even THE company that started that space. And that's, to some degree, an impact that I had on the world, which I'm excited about, like being a category. Who knew?
Aaron: [laughs] Yeah, it sounds like the cloud equivalent of moving from console.logs to using a debugger. You're moving from log messages to having an interactive debugger that you can use in production, which I'm sure any developer who's gone through that journey is as you level up your own development skills, you start off just putting alerts for your code, and then you discover a debugger. And you can look at any variable you want in the context of what's going on. It's a shift really in the entire way that you debug and that you write code.
Or: Yeah. And also, once you get used to it, once you get used to having advanced debugging capabilities, having them being taken away from you is just a horrible pain. And the problem is still increasing. More and more companies are moving to more microservices and to serverless and to more distributed architectures and more velocity in scale of software.
So now it's not just debugging one instance. You have ten different instances behind the load balancer using other microservices. And you need to be able to slide through all of them, and tracing helps to some degree. But again, tracing gives you a sample, and a lot of times, you want to go deep into this specific problem and solve it. That's what Rookout does.
I'm still a board director there, still a stakeholder but not that actively involved today. And the company is still growing and doing well, which is awesome to see. I actually had a pitch from another entrepreneur today. And they told me...they kind of described...I won't go into this, what they're working on, because it's their thing. But they described it as Rookout for something, and that was a very cool experience.
Aaron: But yeah, as you're saying, once you get used to those kinds of things, it's very hard to let them go. I know whenever transpolation first was taking off, oh, you write your code in this one language, and it gets transpiled into another language.
The tooling around a lot of them was very difficult. And you would lose a lot of the...your stack traces would be inaccurate, and the lines that it pointed to would be wrong. Or your stack trace would just be within the transpiler rather than in your actual source code. If you don't have accurate debugging tools, it makes your life as a developer so much more difficult.
Or: Completely. Totally. That's so true. And it actually reminds me of one of the unique challenges that we had with building Rookout. So you would think that the biggest challenge would be the one where you're able to inject those debug points like the ability to...what we essentially do is recreate hooks in memory to grab execution for a moment and then additional purpose code to extract specific variables so you'd think that that's the...So that element of the ability to insert a breakpoint on the fly that's what people mostly perceived as the magic part. Even advanced engineers looking at it they're like, how the hell does that even work?
Aaron: [laughs]
Or: But in retrospect, that was the easiest part about it, getting the hooks into it. The more challenging part was actually around the area you described with transpiling code. And the challenge there was actually the human-machine interface. So you know when you're clicking on your code what line you want. But you don't necessarily know which version of the code is running.
And you don't necessarily know how you transpiled it specifically to run in production, not because you're not proficient or anything like that but just because there are a lot of elements in the way that you don't necessarily control like your build process or some other elements that other engineers worked on. So getting the people using the product to be able to understand those many differences and select that right version of code that was one of the most and I think still is one of the most difficult parts of getting that experience right, I'd say, which is ironic to some.
Aaron: Yeah, it kind of harks back to what you were talking about right at the very start of this episode, where you were talking about how you first got interested in technology, and you're writing little HTML pages, and JavaScript is just there for mouse cursors. And I know for myself and a lot of other people that's how we got started as well.
And a lot of it was you viewed source on a page because you're interested in how did they do that? And you could go look at the code. And then to run your own code, you FTP-ed it to up to GeoCities or whatever site or Angel hosts or whatever other free hosts you'd find or other FTPs that you'd find.
Or: It's all nostalgia.
[laughter]
Aaron: Yeah, and it just worked. There was no build process. There was no transpolation.
Or: It was simpler back in my day.
Aaron: [laughs] Yeah. I do feel bad sometimes for developers coming into the industry these days that it's so powerful what we can do, but it seems that the barrier to entry has been raised so much as well.
Or: That's true. The complexity like the stack itself, building the most basic thing, that stack is constantly growing all the time just looking at the package.json like the requirements for a Common Node.js or even front-end application. That's increasing in volume by the minute without any advanced capabilities being added. It's just like a natural trajectory. And that, at least I think, blinds the engineers to the fundamentals of how these things work because they have so much things on the top of the stack that they need to understand that it's harder for them to get a glimpse into the underlying components.
And there's a joke that goes like, real developers program directly to the compiler. And then another engineer goes, no, real developers write in Assembly. And another one goes, no, real developers take a piece of wire to their tongue and create beats directly according to that.
Aaron: [laughs]
Or: And so the stack, like the baseline, is maybe still the same. But it got so many layers on top that you basically you can't see it anymore. And yeah, I think that, on one hand, that adds a lot of challenges for people to get started just to wrap their heads around what's actually happening when you're building software. On the other hand, you can build really amazing things. Like recently, I started working more with Next.js, and Netlify, and Vercel.
The concept of just writing code and pushing it to a Git repository, and it magically pops up on a website with a CDN, and everything is running smoothly, and you get a quick build process. That's mind-blowing for me. Thinking about that FTP process, you mentioned with GeoCities and getting every line correct because, otherwise, that thing is not going to run, and it's going to work only on a specific browser and not the other ones.
So it got more complex, but we got more power. And I think we are going to see that trend continuing. And the thing that I'm kind of hopeful about, maybe in general for humanity, if I can be so grandiose, is things like low-code/no-code. I think what's happening is we're all becoming developers, even those of us that don't want to. [laughs] But more jobs are going to be replaced by automation, machine learning agents, et cetera, et cetera.
And more jobs are already kind of turning into some kind of development work with simplified interfaces like low-code/no-code interfaces, and I think we'll be seeing a lot more of those. And I think that's a significant thing, a trajectory where we'll see impacting a lot of more industries and a lot more applications. So I'm excited about that, and I'm excited how that's going to change our society where we're basically all developers to some degree. But I'm also kind of saddened about losing that basic touch with the fundamentals of technology, like the nostalgia we just covered.
Aaron: [laughs] But they'll have nostalgia.
Or: Sure thing.
Aaron: We're expecting our first child just in a few weeks, so we're really gearing up for that.
Or: Congratulations.
Aaron: Thank you very much. And a lot of other fathers would be really excited about getting them their first baseball mitt or their first football. And it's like, well, I'm not American, so I know neither of those sports anyway. I'm like, at what point can I introduce them to Scratch or EduBlocks? [laughs] So hopefully, they'll have nostalgia for that whenever they get older. We'll see. But yeah, so you're still on the board there. But you've now moved on to your latest venture Permit.io which, as we mentioned at the very start, has just received a seed funding round of $6 million. So congratulations, by the way, on that.
Or: Thank you.
Aaron: I'm sure that has been an awful lot of work as it was only just announced very recently. Wasn't it?
Or: Yeah, it was announced just last week. We actually raised the round slightly earlier. But now, when we launched our self-service and people can enjoy the product without too much hassle, we felt it's a good time to kind of come out of stealth and announce the round and announce the company. And yeah, actually, the fundraising wasn't that hard. I did that...and I don't want to sound show-off-ish, but it was basically like two weeks.
Aaron: Oh, wow.
Or: For young entrepreneurs getting started, the average is three months to half a year. But like with everything else, once you're familiar with how it works, it's easier to go about doing it.
Aaron: Yeah. You have, as you said, the serial entrepreneur; you have that background as well. You kind of know how it works and hopefully the connections and things. That's all, like anything else, experience.
Or: Yeah, and it's still a lot of work and still a lot of tension and juggling a lot of things that you need to get right in a critical amount of time. So there's a lot of pressure, but you can do it quicker, I guess is the bottom line of what I'm saying. Anyhow, so Permit.io is another developer tools company. Again, that's my passion. And we kind of started with our own pain points as well here. And it's actually a pain that I experienced in Rookout.
So at Rookout, building our product, like any other product, we had to build access control for it. We had to build permission and role so people can use a product. And we ended up building and rebuilding this five times. And doing so, I was like, this is probably four times if not five times too much.
Aaron: [laughs]
Or: This is not something I care about as part of my product. I want to build my product, not these kinds of peripheral things that are mandatory but are not unique to this product or any other. So it was very apparent to us that it shouldn't be this way. Developers shouldn't be building access control and permissions from scratch over and over. And they shouldn't be struggling with this topic that can actually be very misleading. I thought, when I was building the first version of our access control, that oh, I'm just going to do this once, and I'm done.
But the rabbit hole often goes deeper than you think. And a lot of demands and requirements come from customers, and regulations, and security, from angles you don't necessarily expect. And they often, if you don't build it right, don't use the right best practices. You often find yourself starting from scratch. And we found that there are these experiences that repeat for every product. So think about user management, the ability to assign roles. Think about API key management and secrets management; think about audit logs.
So you're seeing what your customers did, and each of your customers paired their tenant, being able to see what they did within your product. Approval flow is like the ability to ask permissions from another fellow user, emergency access, and the list just goes on and on. Every time you've seen one of these experiences, and you've seen them a billion times, every each and one of those times, some poor schlep of a developer had to build them from scratch.
Aaron: [laughs]
Or: So our offering is very straightforward in that sense. So we call it full-stack authorization, and it's the idea that you don't have to build any of those elements unless you want to. And it's comprised of three parts, the infrastructure, so the basic components basically a Sidecar container and an SDK that you can bake into your software to enable authorization into them.
A back-office where the different stakeholders can come in and work with you on this also with low-code interfaces so, for example, you can delegate and enable security to write their policies and roles on their own without having to require you as a developer to deploy a new version.
And lastly, those interfaces that I mentioned for the customers themselves. Every customer is going to need those. There's no reason that you have to rebuild them from scratch. So it all comes ready out of the box. You plug it in, and you can focus on actually building your product.
Aaron: And I'm sure any of our developers has built many of those things many times or tried to work with some of the tools that come into some of the frameworks as well. And yeah, none of them cover all of the use cases. And you do find yourself kind of iterating over them again and again. So that sounds really useful. Can you tell us a little bit about what's in the future for Permit.io? What do you hope to achieve now that you've done this latest fundraising round?
Or: So maybe I should start with maybe where we're at now and then build to the future.
Aaron: Of course.
Or: So we started with an open-source project. We, first of all, adopted an open-source project called OPA, which is Open Policy Agent, essentially a decision-making engine that's very performant. We brought it to the application layer, made it event-driven using our own resource project called OPAL, which stands for Open Policy Administration Layer. It essentially enables you to track changes in the application and dependent data sources and sync them into your authorization there into OPA.
I'll give an example of why you need that. Let's say you want even a basic policy like only users that have paid for a product to be able to use it. That information and who has paid that doesn't sit in your database anymore. That's a third-party service like Stripe or PayPal. And you want when someone swipes a credit card, you want them to have access at that moment, not next deployment or next polling interval.
Aaron: [laughs] Yeah.
Or: So getting that event from Stripe, for example, to immediately propagate into your software that's where OPAL comes in. That's what OPAL does. And we launched OPAL half a year ago, but we had the good fortune of having a significant community grow about it. It's already being used in dozens of companies also in production in amazing companies like Tesla, Accenture, Zapier. And I don't even know about all the companies because it's open source. So I know about those companies because they came in and asked for more features and capabilities. But there are a bunch of others I don't even know about.
On top of that, we're offering our SaaS service that takes OPAL and OPA and not only offers them as a service but also gives more capabilities on top, all those interfaces, and management, and hosted key and hosted flow that just makes it all streamlined. So you don't have to build anything, again, unless you want to. And the next steps there are a couple, so you already heard that we're very open-source, connected, and driven. So we're planning to release more open source. Our SDKs are going to be more open-source and add more capabilities in them.
Aaron: That's great.
Or: We're planning on additional experiences that you'll be able to use as part of the open-source offering. We want to make this accessible to as many people as possible so people can build software with the right best practices even if they're not taking the full service. Because at least if you build it on the right fundamentals, if you use those best practices we baked in, when you want to upgrade, if it's on your own or us, you will be able to without going back to the drawing board, which can be a very painful process like several months on average. So that's one part of it. And the other part...I don't want to give too much away.
Aaron: [laughs]
Or: But I will describe what I'm seeing coming in the future, and it also kind of connects to what we talked about in how software is changing. So more and more people are going to be driving more and more software. But that software is going to be interacting more and more with other software rather than with people. So nowadays, when you're building applications, you're thinking your main users are human users. But more and more, its applications being managed by applications working with your application. And that change is only going to increase, and I'll give a quick example just to illustrate that.
So let's say I'm using my phone to turn on or off the lights, my smart lights. So it would be Siri or the Google Assistant talking to IFTTT, for example, which is another cloud talking to let's say I have a light from Xiaomi to Xiaomi's cloud talking to what's actually running on the light bulb. So we have four to five different applications interacting with one another. And they're rapidly becoming more intelligent. If you just do a quick Google search on any buzzword, you'll find that buzzword combined with machine learning.
So in three to five years from now, we'll be seeing machine learning agents all over the space. And controlling what access we have to those agents to change them, what they're allowed to do on our behalf, and what they're allowed to do in our applications is going to be critical for just being able to keep track of what's going on with all these crazy elements running around.
Aaron: Yeah, it seems like there's never a week that goes by where I don't have to re-off some app so I can turn on my lanai lights or adjust the temperature in my house. It's like everyone has their own portal, and their own authorization, and their own logins, and their own phone app.
Or: They're not enough standards. So we need better standards. We need better building blocks that are shared. That's why we're focusing on open source. And that's why we are working with a lot of players in the authentication space, also to be announced soon. We don't know exactly how the future is going to be. We know it's going to be more interconnected, and we know controlling that connectivity is going to be critical. And we want to focus on getting that right so we can keep connecting things and enjoy amazing solutions.
Aaron: [laughs] Yeah. It's no benefit to us if we've got all these wonderful devices to make our lives easier if all we do is spend our days authorizing them against each other.
Or: Exactly. And also, if they're misused, they could become vulnerable as part of that or if we can't express how we want them to actually be used.
Aaron: That's definitely a big vector as well that we're just finding out more and more about the misuse of these smart home devices and the vulnerabilities that they can bring into our home networks and things. So yeah, any movement around the security there is obviously very welcome.
Or: Yeah. So that's also why I feel like this is a good sweet spot for me and my co-founder, who comes from a very similar background. He was a student of mine back in the Intelligence Core 16 years ago. So we both are passionate about developers. We're passionate about developer tools. So our staff used to build developer tools internally within Facebook. And I already created a previous developer tools company and obviously worked a lot around security. So it's kind of in the intersection of a lot of things we care about.
Aaron: It sounds great. But unfortunately, we're at the end of our time for this episode. So I just wanted to, before we go. Obviously, Permit.io everybody should go check that out. We'll make sure it's linked and things, but it is Permit P-E-R-M–I-T.io. Go have a look. As you said, it's kind of self-serve. People can sign up, give it a try.
Or: Right.
Aaron: It looks like a fantastic service. And yeah, as we've talked about there, it really does answer a need. A lot of developers are probably building undertime. So go check it out and see if it can help you in your next project. Is there anything else you want to shout out? Any of your recent talks or anything like that that you think people should go see?
Or: Yeah. So if you go to permit.io, there's a video page. You'll find a lot of engagements where I had a talk. But I think even better; if you want just to talk to me directly, you're more than welcome to do so. I'm very open, and I always love talking to fellow engineers. You can find me as @orweis, O-R-W-E-I-S on Twitter, LinkedIn, everywhere else, GitHub. And I guess most easily is our Slack community. If you go into permit.io, there's a community on top. You can click that and just message me on Slack. And you'll find me very responsive and always happy to talk to fellow engineers working on your problems, just chatting about tech like we did here.
Aaron: [laughs] Sounds wonderful. Well, thank you so much. I will make sure that all of those different resources there, your community Slack, et cetera, are linked in the description for this podcast. So please do go check them out and pop in and say hello to Or. Give him some thoughts and feedback on Permit.io once you get a chance to try it out. This has been a really interesting conversation. Both of these things are examples of them and the many projects before. So I will definitely be trying them out myself on my own projects.
Or: Awesome.
Aaron: They look like they're going to be super useful. So thank you very much for that. And I just genuinely enjoyed our conversation. So thank you so much for joining us on the podcast.
Or: Thank you. It was a lot of fun and really my pleasure.
