December 19, 2022

Episode 138: Or Weis, Co-founder & CEO at Permit.io

Or Weis is the CEO and co-founder of Permit.io a serial entrepreneur who is passionate about developer tools, previously founding Rookout.com, a leading production debugging solution; and “Upwards”, the largest founders’ PLG community. Before becoming a founder, Or worked as a lead engineer in multiple cybersecurity and big data companies, the intelligence corps., as a consultant for the Ministry of Defense, and as VP R&D at Netline CT cyber division.

Prompting better and safer engineering Or has been recognized as a Snyk Ambassador, and as a JFrog Superfrog.

Julian: Hey everyone. Thank you so much for joining the Behind Company Lines podcast. Today we have Or Weis, co-founder and ceo at Permit.io. Permit is a full stack permission solutions with the premise that you never have to build permissions again. Or, thank you so much for joining the show. I'm so excited to chat with you and learn more about your background.

Experience and also, you know, within the world of cybersecurity and so intricacies what your perspective on it is and really diving into the product that you're building at Permit.io. Before we get into all the good stuff at Permit how have you managed or have you, in the past with your cybersecurity experience have you managed any intense cybersecurity attacks and how did you defeat them?

Or: So first of all, yeah, I, my career started in the intelligence report in the, I. Where I worked as a software engineer, team leader, reverse engineer yada. And there I literally worked on projects that were there. The results of those projects were life or death situations. So I'd say yeah, pretty much deep sticks with with the cybersecurity elements there.

I can't tell you too much about those. Well, I can tell you, but I'll have to kill you. And that's the whole thing, . So we will put that aside. And, but luckily working on my uh civilian projects I haven't run into any deep cybersecurity difficulties, but that might be because I'm very, Of the, did the elements acting. So I put a lot of thought into security in advance and in general, if I can give one word of recommendation around cybersecurity, is to do it by design. Never added as an afterthought Recently checked with a friend. With a friend, and they've kind of described it and insecurity into something that you are building as an afterthought is the equivalence of adding chocolate chip to a cookie after its bake , nothing really get the result we want.  

Julian: I love that analogy that it strikingly makes so much sense within cybersecurity. You know, how are, how quickly, I was talking to a couple other founders who work within the space of cybersecurity and they were discussing the evolution and how quickly it evolves.

In your perspective, how quickly is or are these attacks evolving and how sophisticated are they?  

Or: That's a very good question. First I, I'll say that while I come from a cyber security background and Permit.io touches on cyber security, it's not a classic cyber security company. We're a DevSecOps company, meaning we cater to developers, we provide them tools to build software and as part of that, we ibu their software with with security.

That's one aspect of it, but the focus is just on building the software and having permissions. And I actually think that's by itself is the answer to your question. , because the race the arms race of cybersecurity, both on the defender side and the attacker side is constantly accelerating.

The only way you can keep up is if you move the cybersecurity elements earlier in your process. Kind of touching on that point to add before, so in general, this is called shifting. Bringing the elements closer to the developers. So if we're building software today, we want the developers to be involved and have real impact into the security model and posture of what we're building.

Again, if we edit only later, if we have bring the requirements of the developers only later we're gonna have a bad time. So we. Early on with the developers and we want to give those developers tools that are already ready made with the security best practices. Cuz it's really hard to roll your own with security encryption, authentication, authorization.

Rolling on your own can be very painful down the road, let's say that.  

Julian: Yeah. And then so what or how does a developer, how do you enable developers with the product. To add these security features ahead of time. Is it certain layers? Where is it incorporated in the user journey? Does it incorporate user input?

And, you know, kind of if I was someone using the application, is there something that I need to do as a user to be able to maximize the security that developer has built into?  

Or: Yes. So I'd say there's a set of best practices. I recently gave a talk at the conference called devcon. I gave a talk called Dark v a rcc, the five layers of Modern App Security.

So for people that want to go in into mapping and coming out of the dark, essentially mapping out the gaps that they might potentially have in the software that they're building or using. Dark as a framework that I presented that helps you do just that. It takes longer to present, so I won't go through that.

But suffice to say there are frameworks that you can use both as a software user , and as a software developer to identify where you need to put more attention. Make sure you don't have cybersecurity gaps and it can be very quick. That being said, I think most of it translates to using the right tools.

As a developer it can be, and I'm a developer at heart and originally and still. So as a developer it can be very enticing to build something like you run into a challenge, like, oh, I need a way to store information here, or I need a way to verify information, or I. To check for credentials or I need to decide if someone's allowed to do something or not.

It's can be very enticing to just try and build it on your own. Cuz as a developer that's what you do. You run into a technical challenge and you write code to solve it. But I think the smart thing to do is not to reinvent the wheel. It's the first thing. Check if they're already existing tools that solve it for you, and then at least learn from their best practices or mistake.

And and maybe even use them or use their open source versions. Even if you don't adopt them at day one, at least you are aware that they exist. So if when scale or more friction or more demands come in and you need to use that tool, at least you'll have some some of the groundwork to adopt it cuz you are aware of it.

So I'd say awareness, mapping out the things that you might run into. And in the end of the day, using. Best practices, open source solutions and tools. That's the best way for all of us to tackle this growing problem of security.  

Julian: Yeah. What are some some stories that you have, do you have any stories where security wasn't considered in the beginning of a development of application or certain feature or a certain aspect of technology that ended up not or ended up leaving the information or technology Vulner.

Or: Yes, I have several. I'll pick one. I'll actually, I'll take one from actually from my from my government background. I won't mention names or anything like that, but I think uh enough time has passed to tell that story. And also what's nice about the story, it really shows us that it's. Minute aspects that end up breaking our our cybersecurity.

So government agency has access and are working on very sensitive information, kind of, implicit. And they need to connect to another government agency. . Yeah. So to do so they build a kind of a interesting one-to-one network solution where they can import files from one network to the other.

That way only those two networks are connected and and we don't connect everything to the internet. Still, we need to make sure that things go run smoothly as we connect between those two networks. So, and no one passes things that are not supposed to. So when you export things from one organization, you go into a kind of a DMZ or intermittent zone where you are supposed to run scans and checks and tests all those are automated and then you can actually.

Us. And people go and there's like a process and people are given documentation and training on how to do it, and all seems well. Until the, like a couple weeks after they discovered that there's viruses and software that's wasn't supposed to be on this network and arrive from the everyone.

And they're like, but how's this possible? We have scans in place that would've detected these viruses and malicious software. So how come did they move between the. Yes. And the reason is people, just the people using the system were just annoyed by it. It was too slow. So they were like, okay, I already did one scan.

Do I have to wait to do the other? I'll just copy the file over. And that's what you get. In general, the weakest link is always the human user, almost always the human user. And even if you are building complex yeah, software solutions and tests if you. don't mitigate for user experience the entire thing is gonna crumble into dust.

Julian: Wow. So is it, would you say it's typically the, I guess, rush to complete certain objectives or tasks that, that lead to some of the, you know, some things kind of getting left behind or are not thoroughly executed? ?  

Or: No. I actually think it's just basic human behavior. Yeah. So you have one mindset as you are designing security and you're thinking, oh, this is important.

Everyone working on this will take care of it. But. When people are going through their day to day, they have other things to do. Oh, I need to get this email to that one and I need to complete this test, and I need that file. And they're running between a lot of things. So they don't have, they don't have that depth or foresight of the importance of cybersecurity in that moment.

So they rush things. They try to just get their day to work. Yeah. And so they tend to round corners. And when that happens, The big plans that we've set don't necessarily match up to what actually happens.  

Julian: Yeah, that makes sense. Throughout, you know, you, that's not your first startup, obviously.

This is I think a multiple third or fourth or something along that nature. What inspired you to uh Third. Yeah. Yeah. What inspired you to jump into Permit.io? I know you were running, you know, another startup beforehand that was having a lot of success. You raised a few rounds and it's still up and running currently at rout.

What inspired you to kind of shift your focus and attention and invest in Permit.io?  

Or: So actually, it's literally what happened at Workout. So at Workout I ended up rebuilding our access control to our. Five times when the company wasn't even three years old. And I was like, that's stupid. I don't wanna do it once, let alone five times.

And when I thought of it about it, I realized that throughout my career I've been rebuilding access control to my products thousands of times. And again, at some point, did I want to? Yeah. And I got together with a friend of mine who's not my co-founder at P Assau. He worked at. And there he saw that they've invested a team of 30 people for half a decade to build the level of access control that they have.

So that really kind of highlighted the situation. It's both a huge annoying problem now and it's only gonna get worse. It's more automated agents, it's more machine learning, it's more complex. Software comes into play. Managing how those elements connect and how you are able to connect people in a secure way to those products becomes a very cumbersome and challenging.

So that's what we aim to build with Permit. The idea there is really that you'll never have to build permissions again. We provide all that you need out of the box so you can focus on building your software. And in the end of the day, as a developer looking and looking at other developers, you don't wanna deal with this graph.

Just like you don't want build authentication, you use something like Off zero. Just like you don't want to build billing, you use something like Strike. There's no reason to constantly rebuild this scrap. Yeah. and I'll add that permissions or authorization is really about experiences, about interfaces.

So think about, I'll name a few things and you'll see that you've seen them and used them in a billion different applications. But the sad thing is every time you used it, some different type of a developer had to create. So, user management with the ability to assign roles, API key management, secrets management audit logs.

So the ability for you as a vendor to see who did what within your system, the ability to enable each of your customers, each of your tenants. To be able to see what they did without them having to ask you for the logs approval flows. So the ability to ask permissions from another user, emergency access, and this list just goes on and on.

Yeah. None unique to any product. You've seen it a billion times, but everyone's constantly rebuild this so they, they're with Permits that you have these experiences ready made. So again, so you can focus on. .  

Julian: Yeah. Yeah. And security is so interesting because we think about or I think about a lot of how heavily users rely on companies to, you know, keep your information secure keep your interaction with that software secure or technology overall.

What, what are intrinsically would you say the responsibilities that companies have when they think about the security of their. Are they, you know, highly motivated to focus on it? Are they trying to build as fast as possible? You know, what have you seen as kind of like routine in terms of how they consider security?

Or: That's a great question. So I think we're actually touching on, for me, adjacent topics. So security is one of them, but the other two are privacy and. . So let's start with compliance. Cause things that really makes it the easiest to kind of understand. So with compliance, when you are working with certain spaces you're working as a security company yourself, or you are working in the healthcare space, then you need to be HIPAA compliant or you're working in FinTech and then you need to be SOC too and maybe PCI compliant.

So there are a lot of requirements coming in, either from your customers or from the authorities requiring you to meet a certain. Yeah. Not meaning that standard can mean the end of your business or at least heavy fines. Privacy is kind of similar, especially if you're in Europe, gdpr or in CPA for California.

In general, these, there are these now basic compliance patterns of how countries. And people expect you to deal with their data in a way that protects their privacy, or at least allows them to retain their privacy if they want to. So those are all basically product requirements that you get just by the fact that you decided to have a product and you wanna serve it to a certain sector.

Yeah. Those are requirements that are basically as important as the other requirements of your product, of it just working, right? , ironically they're important, but businesses don't give a damn about it. At least inherently cuz solving them doesn't pro grow the business. It enables the business, but it doesn't grow the business usually at least.

So. being able to cover all these elements is really about setting the stage for actually making the business happen and enabling it to grow. So are companies trying to sweep them aside or anything like that? I don't think so. I think most companies when it comes to compliance, they want to do the right thing.

They don't wanna , have mistakes there that will end up crippling or even stopping their business. I think on the, there's kind of a subsection between security and compliance, where it's not necessarily a death sentence for the business, but it, yeah. But it can be very embarrassing. It can end up you can end up with some egg on your face as the saying goes, and that can translate to bad business.

It can be negative marketing. It can impact your bottom line. And so people will try to avoid that as well. But in the end of the day, all these things are risks, meaning that, yeah, we, with the human mentality, we don't actually know if the risks are going to be if they're gonna be if they come into fruition.

It's a major and some people are more risk averse and some people are less. But in general, I say that there, there are standards and there are standard expectations. There's like the common practices. Or the morals that people work with. And these are constantly increasing because the demands, the overall demands are increasing.

The morality of cybersecurity, privacy and compliance is increasing as well. So ironically, as it become, as technology enables us to build businesses faster, we have to meet more requirements to just get started. And that's where. That have these essences already baked in come into place so you can actually build your business.

Yeah. Not having to build all of this crap.  

Julian: Yeah, no, it's amazing to see the the increase in amount of developer tools that are out there. Whether it's no-code platforms or you know, full service tools. Like, like, like Permit.io, where you can it's almost like standardizing. What are the necessary components you.

When you bake anything, you're gonna need flour, you're gonna need sugar. It's like having those elements kind of packaged together. But what's so fascinating to me in terms of, you know, the, when you build software or tools that enable developers is the conversations that you have with them to get them to use your tools.

And we've talked to a few founders on the show to see, you know, how they communicate with developers and get people involved in using the. And so how does Permit.io, how do you go about building that community and also continuing to reach out to developers and foster them to use your product and use the capabilities of Permit.io?

What's that process like?  

Or: Terrific question. So I think it. First, it starts with empathy. It's understanding what our customers want, what these developers want, and how they want to learn and find the tools that they want. So let's start with what they don't want. They don't want you to call them up and try and push your merchandise on them.

I don't know about you, but like if someone calls me on the phone nowadays or someone tells me a cold email or a cold LinkedIn message, the first thing I do is get upset. The next thing I do, if they actually try to sell me something, is I get furious . So the world has changed, like the doing business in the form of closing deals on the golf course or.

Steak dinners, it still exists, but it's rapidly fading out. Yeah. And what comes in instead is bottom up motions, and particularly product led growth. Product led growth is really about putting the product up front, removing as much friction as possible so people can try other product and see if they want it.

And if they want it, they'll talk to you. So that's what we do with per. Make it as accessible as we can. You don't need to pay for it. You don't need to jump through hoops. You don't need to talk to anyone. There's self-service. You come, you can use it almost unlimited, like up to a thousand monthly active users like identities that you check permissions for, you, you don't need to pay.

It's free. So you have a wide range to term product before you decide if you want to talk to us or another, or if you want to pay or not. Yeah. So that's the first thing, just removing friction, making it accessible. The other part is making it worthwhile for people to consider. So instead of doing marketing where we tell people why this is the best thing ever since sliced bread, we create value in the comp.

So we create open source projects. So we create tutorials on how to solve this problem in adjacent problems. We create masterclass. So recently, for example, did a masterclass with piano about how to and Google on how to handle sensitive data. So there's a lot of things that we can bring to the table that is valuable that relates to what the product we're building, but it's also valuable on its.

and in general, if you act with kindness, empathy, if you bring people actual value Yeah. That they want, they'll be interested to see what else you can bring to the table. Yeah. And as a result, I have multiple conversations every week over six on average. All inbound conversations with people scheduling through Calendly on our website, just scheduling Zoom calls, and all these talks are not, they're not sales meetings and don't pitch the.

I have technical discussions. I have brainstorming sessions with other people engaging on the similar problems that we're having, and I'm having more fun that way. Our customer is having a barrier, more fun that way, and the business is growing quicker that way as well.  

Julian: incredible. I love the openness to have these conversations, and I'm sure it also leads to more successful you know, in terms of more success in terms of building product market fit and finding the exact things that are necessary or I guess that developers want and need when they're developing and what tools and features that they need to use.

Describe, you know, one thing that is unclear to me and might be to our audience as well is the difference between open source project Opal and Permit.io. Describe the differences and also the relationship between the two.  

Or: That's a terrific question as well. So, when my co-founder and I Asof started working on this problem we started by thinking what we need to actually build the Permit, the solution.

We started by adopting an open source project called opa Open Policy Agent, which is a graduated CNCF project. Pretty popular at this point. And it's a policy engine. You load code policy as code into it and data in the form of Jason documents, and then you can query it. You can essentially ask, according to the policy that I've said, can this user access this feature or not?

But one of the challenges that we had is that Omar was. It really grow into fame in the Kubernetes space. So it wasn't really suitable for the application space. It just doesn't update quickly enough. So that's why we created Opal Open Policy Administration there. It's a solution to keep Oppa up to date in real time.

It creates a realtime pops up socket channel that updates both policy and data. Sorry, into oba. And we just started with that project and it quickly got a lot of positive attention. It's now used by thousands of companies, including huge ones like Tesla, Xavier, Accenture, Microsoft, Cisco, and a bunch of others.

And but when we had that component, we could build. Now that we have the way to update the policy engine in real time, we can build all the interfaces that will update it or will manage updating the control panel on top. All those interfaces I mentioned before, the user management and the policy editor that will generate the policy for you and and editing and creating tenants and multi-tenancy.

So Permit really resides on top of op. , but they're different. So we're not working with the, with an open core model. Open core is the, usually the model where you have an open source project, and that's also what you're selling. You're selling an advanced version of it, or you're selling a hosted version of it.

I think that kind of really lost its flavor nowadays. There's a lot of cannibalization and mostly friction like having to deal with the question, should I. Feature into open source or not is a bad conversation to have. If you're trying to limit what the open source project that you're building, you are doing a disservice to your community.

So I think it's better to have a clear differentiation. So with permanent and Opal, the relationship is what I call open foundation. So there two sister projects, but they're separate. They have different value pro. and the end of the day Permit uses al. It's a foundation or a infrastructure component that Permit can use.

But again, they're not the same thing. So that I think really creates a better balance for us both with creating the open source project, maintaining it providing it to the community, and building the SaaS, offering that in a way that doesn't collide with.  

Julian: Yeah. Incredible. Tell us a little bit about the traction with Permit.io. How many developers are using the tool?  

Or: So first of all, the kind of corn status. So we have thousands of users working with the product on. Of consequence spaces. We have hundreds of active in production customers including FinTech organizations and healthcare organizations.

I was kind of surprised to see that healthcare organizations kind of became 60% of my pipeline. Oh really? I don't actually know why, but I think it kind of relates to what we talked about before of security and compliance. Yeah. When you work in a highly compliant space that really urges you to cover those.

Things earlier and in better quality. So we're catering to we're serving hundreds in production and and a lot of them are very compliant, sensitive companies. And we're seeing significant growth like that week over week. We're adding dozens of new companies to the product and it's really exciting to see how they're moving through that product led growth motion.

A lot of them, even also a lot of paying customers, I haven't talked to them once. . But I provided something to them that they jive with something that resonates with them, something that they can use and solve the problems they have and take them into production and even come in and say, Hey, I actually want to pay for this.

Which is kind of consistent. So before we had billing, we had like customers coming into the community and saying, Hey I want to buy the product, but you didn't provide a way for me to buy the product. Please let me buy the product. That's a very cool interaction. , yeah. In terms of what we're expecting down the the road or like, upcoming releases.

So I think a major one is is Permit elements. So I talked about the experiences that you can embed into your software. So we're already providing those, but they're not as customizable as we want them to be. With Permit elements, we really enable you to self-serve yourself with all the different experiences that you need for access control within your product.

The what you'll be offering to your end. A cool thing that we're solving as part of that is authorization for authorization, and that can be a little mind boggling when you think about it. So, we, you are now managing access control in your product with Permit, let's say. So you are creating policies on who can do what within your product, but now when you are embedding access control interfaces, for example, the policy editor or the user management, Now you need to decide who can use those interfaces to change the way that access control is managed by the product.

And obviously immediately when you are introducing who can manage the access control, now you need to decide who can manage the access control to the access control. And this obviously can continue recursively at infinitive. So it's an interesting problem to solve both on the tax. On both on how you integrate this into our customer's product in a way that is seamless.

And for most of our customers, it is seamless, but we do a lot of heavy lifting behind the stage. And I'd say so those are some of the things that I'm really excited about. And and there are, I don't wanna do too many spoilers, but there are more, there's more open source offerings that we're coming up with that really I think, jive where this space is evolving.

Authorization, unlike authentication is still kind of a nascent space. It has become really hot very quickly, and people are starting to understand that it's really a best practice or a classic tool for you to use. But it's still, it's not as mature as the authentication space. Yeah. And as it's evolving, I think we're trying to add the building blocks for standards that will help people, not just.

Use the tools here, but also think about 'em and connect them to what they already have in place.  

Julian: Yeah. If everything goes well, what's the long-term vision for Permit.io?  

Or: So in the end of the day, we're helping people connect the between themselves and the software that they're building. I'm really excited about what's down the road.

I kind of mentioned it when we talked about , what we saw with Facebook. So nowadays when you're building software, Primarily other human agents. Other human users using your software. But more and more it's becoming other automated agents, other applications on behalf of other applications.

On behalf of other applications. Somewhere down the chain, there is a human user probably, but all of these automated agents are starting to work alongside one another. Yeah. And as this become more complex, really it's about how we build experie. That will enable us to connect with our technology. As our technology becomes more complex, how do we keep it easy enough for us to work with it?

Yeah, and that's I think, the basic mission statement for Permit and and down the road that means catering for all the stakeholders. So we are focusing on developers now, but we want to enable product. And professional services and security and compliance. Everyone should be able to work with their software to set the boundaries that they need in a way that is easy and and not confusing.

Julian: Yeah, I love that. I like to, this next question I'd like to ask for research purposes, for myself and for my audience, whether it was early in your career or currently now, what books or people have influenced you?  

Or: I give this answer often, but but I still think it's a substantial one, so I'll stick with it. I think the book and author that really affected me the most is The Selfish Gene by Richard Dawkins. It's a textbook on biology. It essentially explains how genes work and how they, their extended phenotypes change the world around us. I really love to think about how from these really basic self replicating mechanics, all the complexities without a doubts came into existence.

And I love how this is relevant for basically everything. I'll give a recent example. I had a conversation with with engineers in r and d about should they invest more time planning a complex feature or should they release something small and iterate on it? Yeah. And I was like, Hey, if it worked for nature, like if everything else around us was built in iterations, I think it's good enough for us as well.

And there's like a classic example that I like to give there that people not everyone's aware of. So, . That's a, it's a fun fact, essentially. So how do you think the wiring between your brains, the neurons from your brains to your larynx, how do you think those are routed? How does deadline go?

Julian: I have no clue. Maybe from to a larynx, I feel like it has to go um it can't be a direct access point because then it's I think that it gets too disrupted.  

Or: That's actually what you'd expect. Like the shortest path is like a direct path that's still brainstem, newer larynx. It's not a very long distance.

Let's just pass a direct wire there. But that's not what we see in most animals and in all mammals. What we see is that it starts at the brainstem, it goes down your chest to the level of your heart, and then clams all the way. . This is also true for a giraffe. It's a few meters long in a giraffe's neck.

That's also why probably giraffes have a lag time when they're trying to vocalize, cuz it just takes time for the signal to go all that way. And the reason for that is that evolution doesn't plan ahead and doesn't have the luxury of going back to square one and withdraw. At some point, the, that wiring overlapped a bone and as the bone structure kind of extended, that wire had to extend.

And at no point the evolution was able to say, oh, this is kind of awkward. I'll rewire this. No, as long as you can extend the wire and it ends up working, you can do that. And if it works. And. In the end of the day, I'm using that system right now. I'm talking to you through that system, and it's survived millions and even to some degree, billions years of evolution if you're looking at genetics as a whole.

Yeah. And I think that really when you have that lens, it really paints the entire world with with additional understanding then isn't available.  

Julian: Yeah I I love the way the cross knowledge is shared in how it, it's influenced your kind of philosophy around development and it's all about, you know, maybe not trying to be perfect, but trying to continue to evolve in the iterations and adapt you to product and continue to move forward.

It's so fascinating. And I didn't, and I didn't know that now that's a nice, fun fact for. The next family party or a cocktail party? I and you can read that the selfish gene. Yeah. Yeah, exactly. I know we're at the end of the episode here, so I would like to give our guests a chance to give us your plugs.

Let us know where we can find you, where we can support Permit. Oh, where are your LinkedIns? What's your website? Where, what's your Twitter? Where can developers also get involved in starting to use the tool and start, you know, creating the solutions they need to with the necessary foundation.

Or: Yeah. Awesome. Finding me is really easy. I'm, Or Weis, basically everywhere. Twitter, LinkedIn, gi, et cetera. So you're more than welcome to page me there. Permit.io is surprisingly found@Permit.io. It's easy to find our community on the top. There's a link to our community in Slack.

You can message me there as well. There's a, down the page, there's a link to Calendly. You can just schedule a zoom meeting and all show up. In general, people are often surprised. I don't know really why, but they're surprised of. How how much I'd like to engage with people, like people coming to our community.

Like I enjoy answering questions there on like, on a daily basis. I spend a lot of my time there. It just, that's what I like to do. I like engaging with fellow entrepreneurs, fellow engineers, fellow security practitioners. So, I want to encourage all our listeners, if you for some reason liked my rambling here by rambling here, you can reach out to me and get some more ramblings.

Julian: Amazing. Well, or I hope you enjoyed yourself and thank you so much for being on the podcast.  

Or: Thank you for having me. It was a blast.  

Julian: Of course.

Other interesting podcasts