Quint Co: The Executable Spec Language Made For The AI Era

GM, GM, welcome to what is going to be another fantastic episode of DevNTell. So, if you didn't know, DevNTell is a 30-minute podcast held every week, allowing founders, hackers, and anyone in between the opportunity to come on the show and showcase what they built. And today, I'm ecstatic to welcome Gabriela Moreira, who is the CEO of Quint Co. So, if you didn't know, Quint is a specification language that can be used to describe models and properties, enabling you to write precise specs for your system behavior. So, if you stick around for today's episode, you'll get to meet Gabriela, learn all about the Quint specification language, and how you can start using it to build today. All right, let's get into it.

GM, GM, welcome to the show, Gabriela. I'm excited to have you on today.

Yes, thank you for having me. I'm very excited.

Yeah, likewise, likewise. Uh, yeah, in this age of AI, we know there's a lot of code being produced and shipped, but not necessarily verified. And who knows what vulnerabilities people are shipping today. So, I'm really excited for our audience today to learn about Quint and how they can start using it in their vibe-coded builds. But before we get into that, would you just like to give an introduction about yourself?

Yes, for sure. So, I was doing my bachelor's in computer science, started over 10 years ago, and at that time, I was doing some compiler work. I really liked compilers, programming languages, type systems, all that stuff. And then someone introduced me to a language called TLA+, a formal specification language. And at the time, I was also working in the industry with web development, distributed systems, databases, and I was like, "Oh, this thing would be super useful in my job, but also, the syntax is so mathematical and so scary, I doubt anyone on my team would like to use this." So, I don't know how I can introduce this to them. But I fell in love with formal methods right there, and I got this passion to make this a little bit better so it's more used in the industry because everyone should be using this thing. So, I continued working on my job, and then I made a master's in this topic of tooling around formal verification. And then I met Informal Systems, which was doing a lot of Web3 development, building the Cosmos blockchain. And they were also very into formal methods from the beginning and doing a lot of work with TLA+. So, we met at the TLA+ conference, and right away, we were doing pretty much the same thing, the same kind of tooling. So, naturally, I started working with them, and that's when Quint was born as well. My origin story has a lot of intersection with Quint's origin story. But that's me, I'm living in Brazil, I was born here, I love the country, I love living here. I have a little cat that might intervene in today's podcast. And yeah, very excited about the World Cup.

Yeah, yeah, I can imagine. We're talking off-air, FIFA has taken the world by storm the last little while, so can't blame you if we hear some cheers once in a while through the podcast. But I just want to dig in, you mentioned gravitating towards the crypto scene with the team behind Cosmos. Just curious what drew you into this space other than that same passion for formally verifying code?

It's pretty much the same passion, but what I like to highlight about the intersection of Web3 and formal verification is that Web3 is really the best use case in order to succeed at this kind of thing because, first of all, you have this problem where when you ship code in Web3, it's hard to patch it. This is also true when you are in rocket launches, right? If you have software written in the rocket, in the spaceship, you don't get to fix it after it's in the air. Same with airplanes. So, I think blockchain has that same sort of thing where it's hard to fix mistakes once they are out there. Second, there are such high incentives for people to exploit problems because the money is right there, right? So, if you find an exploit, that usually means you make money instantly, like you don't have to do anything else. So, there are a lot of incentives for exploitation, which means we have more of that asymmetry between attacker and defender. You have to put more effort into making your code correct. And third is, like, by the time I joined, this ecosystem is where the most money incentive was into formal methods, right? Basically, when I was starting with formal methods, you would hear from the research groups and stuff like, "Oh, if you want to work in the industry with formal methods, you have to work on blockchain." Or you get that one job in like NASA or some airplane company, but otherwise, it's just in blockchain. So, that's why I got in. So, when I went in, I didn't know anything about blockchain pretty much, and I, yeah, still don't know a lot, but yeah, I've been to some events, so now I have a bit more context, yeah.

Amazing. Yeah, and I think you chose the perfect industry to apply formal methods and verification to. The industry needs it, even in today's age where, especially this year, we're seeing lots and lots of protocols being exploited, whether it's through AI, or it's very likely aided through AI. But yeah, I think we're not done yet, but we'll see. I guess, for folks who might not be familiar with formal verification and formal methods, could you just give a high-level overview of what they are?

Yeah, I can talk about formal methods in general. I forgot to mention in my intro, but I was actually teaching formal methods at the university for a year and a half, actually still very involved with the university, very grateful for everything there. I'm actually going there after this podcast to watch a thesis. I love the university a lot. So, getting into a bit of teaching mode for formal methods, and formal methods are basically any techniques that help you verify correctness of code or hardware as well. So, software and hardware, but any sort of methods. So, the most maybe the most basic one we use pretty much every day, or a lot of developers use every day, is type checking, right? If you have type definitions and you are running the compiler, and if there is any thing wrong about the types, the compiler will complain to you. That is doing something that is formal methods, like it's formal verification because it's checking the correctness properties. Of course, there's only so much you can express in types, right? They can do a lot, it's very nice. If you learn to use types well, they can do a bunch of nice things, and then if you get into really advanced mode, you get into stuff like dependent types where you can express things about values within the type system and then have proofs that those things hold. It's super interesting. But that's one thing. And then, there are different types of formal methods, and the most common ones that we talk about today in the industry, when you see people talking about formal verification on Twitter, they usually mean something like either proof assistants like Lean, Coq (which is now Rocq, actually, they changed the name), Isabelle, etc. Those are proof assistants, and those are tools where you would write mathematical properties of things and then prove they are correct for every single case, for every single like N and M, N + M equals something, you know? So, you are proving something mathematically for every single possible parameter, and then you are going to do inductive proofs, all of that sort of thing that some of us have learned in university. And then, the other kind of formal methods that's a bit more lightweight is usually what people call model checking, or even stuff like constraint solving also falls into that box, where you have some more automated proving. So, you will still write properties in some way, and then the computer automatically will prove that to you. And that's where TLA+ falls in, and where Quint falls in. And in the realm of model checking, which is the place I'm studying the most and I find myself in the most, model checking is the technique where you have one model of your system, which is a state machine. So, you have one initial state, you have a bunch of transitions, and my cat wants to make an appearance. Look, have a little cat here. Let's remove the cat maybe for maximum focus if she allows me. There we go. Model checking, you have one model, so an initial state and several transitions, you define all of the transitions you can make, you have one state machine that is your model, and then you have properties, any property about the states of those state machines and about the executions of that state machine. And then you give that to the tool, and the tool tells you either true, the property holds in all cases, or it tells you false, and then it gives you one counter-example, which is like one sequence of states that lead you to the counter-example. So, in that case, you don't have any false positives, right? You always have like that exact scenario where the bug happens. So, that is a summary of formal methods, I guess.

Yeah, and I'm sure you could deep dive into each one of those for a great deal of time. And yeah, as you were explaining it, I was having flashbacks to my university days doing proof by induction and what not. So, yeah, definitely not a stranger to all of this. And I guess, I kind of touched on it a bit throughout the start, but I think formal verification is more important than ever, and I think you'll agree as well, just because of the volume of hacks that we're seeing, and so many new builders in the scene who might not even know what that is, or have never touched a programming language in their life, and they're just vibe-coding whatever they want into existence, which is cool, but also really kind of scary at the same time, especially if something gets very popular and you get a lot of users. So, I guess, due to like all the vulnerabilities that we're seeing, especially this year, in your mind, do you think it's just the models are really good at just like exploiting things, or do you think people are just shipping sloppy code, or is like a mix of both, do you think?

I think it's definitely a mix of both, and not even like a necessarily an overlap of both. I think they're both happening independently, and I think it's easy to see that if we look at the news and types of things that are getting hacked, or like if you found bugs on things. For instance, like when Mythos came out, they found bugs in like software that's been there for like 10, 20, 10-20 years, right? That's not vibe-coded stuff, right? And still, there are bugs in those things. So, definitely, I think the models are good at finding at least like one class of bugs. And then the other side, there is like this people that have never coded before, they are shipping code for others to use, and then they are not careful about like the database security, and someone gets in and takes everyone's data, right? That's the other side of the spectrum. So, both things are happening. So, I think definitely both. And then how much overlap there is, even like what, like what happens if you're using AI to find hacks and you're shipping vibe-coded, then like I think it gets just much worse.

Agree. Yeah, yeah, exactly, exactly. And I think this is a good segue to kind of introduce the Quint spec language to folks. So, yeah, stage is yours.

Yeah. Um, so let me start actually, um, from, I talked about type checking. So, let me try this time to explain it like this, right? Um, so in type checking, uh, you already have like some definition of type, some languages like even infer a lot of types, but you get that sense of correctness, you know that if you run the thing, the types won't break. Uh, if you have worked like first with languages with types and then had to work with languages without types, you kind of like know how frustrating it is to have a type error when you are running something. Um, and now, uh, we are having tools, we are having people that believe, there are believing that formal verification can just like automatically write correct code, right? And that would be amazing. And I feel like there is a lot of room to, to explore there, and I'm very super excited about those kinds of solutions. But how much can actually AI know what correct means for your application? Right? They can maybe like I think with AI we get more of these like applications that don't crash, right? You can prove that nothing can like use formal verification, can use other testing techniques to show that something doesn't crash. So, you have software that doesn't crash. Maybe you have software that has no null pointer exceptions. We have software that doesn't, um, have authorization problems of someone invading another person's account. But there are so many nuance in software behavior, how systems should behave, that AI will not be able to tell what is right and wrong. Right? Who knows what's right and wrong is the person building the application, is maybe even the business people beside the application that are like, "Oh, user should be able to do this, they should not be able to do that. In that case, this is the correct behavior, and this is the incorrect behavior." There is so much judgment involved in that. Um, and I feel like there is really no way that we can just let go of that and like, "Oh no, AI is going to figure out what's right and wrong for me." Like, depends so much on what the application is about, all of that like high level of decision-making. Uh, so we need to define those things, right? We need to define what is right and wrong for us, and then we can leverage AI as much as possible. Uh, to write correct things. And, um, so I think this is exactly where Quint helps, right? Quint is not going to automatically make your code correct and formally verified, not even with AI, right? That's not the point. The point is how can we lift this, um, correctness decisions and present it to you like, "Okay, is this the behavior that's correct or is that one, what do you, what do you have in mind?" And then you define that and then Quint like, "Okay, I got it. Now I'm going to check your application for this behavior." So, you are not checking for absence of crashes, you are not checking for, um, underflows and overflows. There are other tools who do that, and that's very important. What we do is like checking if the behavior is correct. So, in the realm of all of like formal verification tools, we are on that side of things where you define correct behavior. So, we do, we have way more focus on, and emphasis on formal specification. How do you specify something, um, properly so you define what correct means for your application without having to learn math again and write math, right? We have a very friendly syntax, you hopefully if you have written any code before you should be able to, to read Quint specs at least. If you want to write them by hand, you have to learn a little of syntax, but AI can also write Quint for you. So, you ask AI to write Quint, you should be able to read what AI wrote for you. Um, and then so we spent most of our time developing Quint was like putting into making it very friendly. And this is not just about the syntax, is also about the tooling around Quint, and we call the specifications you write in Quint, they, they are formal specifications, but we also like to put emphasis on how they are executable specifications. You can take your spec, which is a state machine again, and just like press run and get one path, and then you see like, "Oh, okay, this happened, and then that happened. Oh, this is weird, this should not have happened. Let me like go and fix it."

Uh, yes, thank you for, for such a thorough explanation. Uh, and I guess, um, for the developer out there who's more accustomed to, uh, writing unit tests, running integration tests, smoke tests, what have you, um, would you say that something like Quint, uh, might be a replacement for that, like a more powerful replacement for that, or something that would, uh, more, uh, more so complement all, all, all of that, that's already in play?

I think complement, because, and also throughout the last few years, we also explored a lot how to use this Quint specification to test code. So, we can generate, there is a library we have out there, open source, called `quint-connect`, that will help you connect your Quint spec with your actual code and test it. So, you're going to like take your state machine, get a bunch of like random paths there, or specific paths that reach some nice scenarios that you are interested about, like, "Oh, I want a path where two users have the same item in their cart at checkout. Give me one scenario like that." and then Quint gives you that, and then you test it in your application. So, we've been exploring a lot of that, I think this is a super strong way of testing. But we, more and more, um, for this year are trying to make it so Quint can help you more on your existing testing. So, you don't have to like add a whole new, uh, way of testing to your codebase. So, we are thinking about different ways in which Quint can help you testing, because I think testing is like super, um, important, and it got even like an additional sort of value now, I think, with AI. I think tests, uh, if you have high-quality tests, they are not just like AI slop, right? If you have actually, uh, been careful about the things you are testing, that's currently the best way to like define what correct behavior is, if you are, I'm going to say, if you're not using Quint, but like what people are using actually today a lot is like this kind of testing. And those are the strongest guardrails against, against AI introducing behavior you don't want and you didn't notice because maybe you're not checking the code so carefully, or maybe you tried reading the code, but you didn't notice that some, something bad was being introduced. If you have tests guardrail in your, uh, your behaviors in place, um, you have more protection against AI introducing bad behavior. So, we want to also help, combine that with Quint. How can Quint help you keep your tests actually locking the behaviors in place?

Excellent, well said. And on the, the topic of, of AI, uh, I guess, um, how do you see Quint helping, um, AI-driven, um, codebases and, and workflows in today's age?

So, I think there are, I want to say three different, uh, entry points or ways Quint can help, right? One of them is what I just mentioned about testing. Like, how can, um, you be sure that you are testing different edge cases, you're not like testing just the same sort of behavior over and over, instead of having like a diverse, uh, set of behaviors that, that, um, you're ensuring through your test suite. So, that, that is one thing. Um, and the other two things, one of them is, I think at the code review moment, uh, there's such, such big problem now of like, people are calling like cognitive debt or comprehension debt of like, no one, like, "I didn't write this code, you didn't write this code. How can like we review it and make sure it's correct?" And I really believe that just reading code is not going to be a permanent solution. Um, I don't think we are good at reading code. Uh, our brains are not wired that way. So, we need something that we can like, more tangible, that we can execute. And I think like Quint, it's like more abstract than code, so it's less things for you to write and read, and the way you can execute it and query it, I think is very valuable for, for code reviews. So, we are exploring different things, but I think definitely there is like an entry point there where Quint can help you be more assertive when you're doing code reviews, understand better what are the new behaviors that the code is now going to have after we merge that PR, or did you remove any behaviors, are you testing the behaviors that you are, that you added or removed. Uh, so we are thinking a lot about that. And then, maybe the most, I think it's, the holy grail, uh, is when you use Quint for design, right? And this has always been the case with, uh, other formal methods tooling, like the whole story about TLA+ is like the creator of TLA+, Leslie Lamport, um, has an article about how, why would, how would, who builds a building like a construction building without drawing a blueprint first? So, why would you write any software without writing a formal specification first? That's his point, right? So, the idea of like you should write a spec before you go and write code has been there forever, but most of us are still not doing it. Um, I think we are now doing a lot of plan mode with cloud code, with code acts, we're going to plan mode and then we do a spec, uh, in a way. Uh, so we are getting into that, and I think like if we can fit formal specifications and executable specifications into that flow, uh, that will be, uh, super interesting, and we also been experimenting with that. Um, one of the first blog posts I, I've written about AI was last year, was about this like how we, um, used Quint in the design phase and, and got good results, and then since then, I also been trying like different like plan mode with Quint, and it's interesting because it feels like you're working with a smarter, uh, engineer, if you have Quint involved, because instead of asking like, "Oh, how should I write it this way or that way?" is asking you like, "Oh, should the code behave like this?" And, and it's like asking, asking very good questions when, during this design phase. Uh, so I think there's definitely something there. However, this is a bigger change, I guess, in, in people's workflows, um, so might take longer for that to, be widespread. So, these are the three things, uh, we are thinking about currently.

Awesome. And yeah, no, I think you're definitely going down the right, uh, right avenues here and, um, just curious, are there, um, skills, uh, available for people to, to plug into their, to their clouds and, and codexes?

Yes, uh, so we have this repository called `quint-llm-kit`. And there we have everything basically we tried, like in the past, we were using like a, MCP server that had some examples like codebase. Uh, now it feels like with the new models, that's not so, so much necessary. The new models are already trained in more Quint examples, so we are not using that that much. We have commands, etc. We are converting things into skills and polishing them, so you'll see like there are even some PRs open in the repo now, and, uh, we are planning to launch like the, the official like the skills that we've tried more, uh, pretty soon. But we have stuff there if you already want to start.

Awesome. And, uh, yeah, we'll, we'll definitely link that for folks to, to check out, um, after the fact. And, um, yeah, uh, just, just interesting to kind of, uh, pick your brain about as well. Um, you mentioned it at the start when, when you were describing it where, um, when, uh, AI model kind of produces code, you, and you're kind of going through that code review process, sometimes you don't recognize or know your way around the code because, I mean, for me, like, when I look at it, I'm like, "Oh, like, I didn't write this code, it didn't necessarily follow my, um, my way of coding." Whether or not, like, I, I didn't set up the, the right, um, um, the right, uh, cloud parameters or, or what not. Um, but do you, do you feel the same sometimes when you're like, "Oh, this works, but I don't really know my way around this codebase a lot."

Yeah, definitely, uh, I think, I imagine every developer that's trying to use AI has, has gone through this, and I feel like some people are more excited about it than others, and others are more concerned about it. Uh, I do feel like that, and I feel like there is definitely some point in between let's read all code we ship ever and let's understand every single line, and like let's just vibe-code everything. There's definitely some point there, in, in between. And I was even talking to my team this morning, like it's so hard to determine where that line is. Like, for front-end code that I'm experimenting with, that's totally fine, maybe, to use AI and like experiment with new buttons, until we get like something, "Okay, this is what we want," and then maybe at that point, we need to be more careful. And, uh, how much testing has to do with this as well, because if you have testing in place and you trust the testing, then maybe you don't have to look at the code in such detail. But for the core of Quint, the stuff that we are developing, there we definitely want to be aware of every single line. Uh, I actually have, um, I think, a quite unique experience with this. I just showed you like every, everyone's feeling like this, but now I'm going to tell about something I think is very unique to my situation where, uh, I pretty much know all of the Quint codebase. I think I, I'm, I've written like, I don't know at this point anymore because now we have a bigger team, but like until last year, I think I've written like 90% of it. So, I, um, know every single, every single thing there. So, when then we start having more people contributing to it, even not, not of AI, we are not using, uh, AI heavily on Quint code at all, but like people, um, contributing to new things, and I'm starting to realize, "Okay, now I don't know every single, character on this codebase anymore. I have to like, get used to it." Uh, and, and it feels weird. So, I had this experience, even like with standard AI, um, a little bit, and, and with AI, just the volume is so much, much bigger, right? So, I think it's definitely very important that we understand how the application behaves, and then we don't have to understand every, every single line of code in most cases. I think there definitely are some cases where you do need to review every single line of code, but those are more rare, I think. Um, and I also think that where there are applications where it's totally fine to vibe-code things, uh, it's just, I think the danger is people that are not technical, like they, they are not engineers, they don't know where to draw that line at all. So, like I know that if I wrote, because I, I wrote like a little like, note-taker application with, uh, some silly things that I use personally, every file stays on my computer, totally safe, I can vibe-code it the way I wanted. Um, but if I was not technical, maybe I would like to like ship that and put files in a database, and then suddenly people's notes are exposed, and that's super bad. So, knowing how to draw the line, I think, is a challenge and we don't have a solution for that, so.

Yeah, yeah, and I mean, uh, yeah, it's, it's one of those things where it's like, you have this, like coding was already, it already felt like a superpower, like before AI. Now with AI, like everyone has like this magical alien tool or, or whatever you want to call it, it's just like, you can build anything your heart's desire, right? But, um, yeah, to your point, like, that, I personally think that's kind of where the line is, like where you mentioned, where you start to actually have, um, underlying dependencies like databases, or needing to store secrets or something like that, like once that's there, if you kind of put that in a non-technical person's hands and you solely rely on AI, um, to do it, um, these things are non-deterministic, right? So, um, it's not going to spit out like a very hardened codebase every time. It could cut corners if you're, if your PRD is too big or you haven't split out the work items very well or, or what have you. So, yeah, it's, it's very interesting, um, what is enabled, but at the same time, all these attack vectors are kind of still out there, and yeah, if something really takes off, like, you might, you might run into problems. But, um, I guess this is where something like, uh, Quint, uh, can help, uh, come, come into play here. Um, and, and you mentioned it, um, you guys are, uh, planning on releasing some official skills, um, very soon, but, um, just curious, is there anything else, um, you might be able, uh, to share along the, the roadmap for Quint in, uh, 2026?

Sure. Uh, yeah, the skills is like just a small thing because we are, uh, just on a work of reviewing that now. But we, so, I think, for, uh, I think you might already have this context, but for the people listening, I, in my intro, I mentioned that I worked for Informal Systems and that's where I started working on Quint, but in April this year, we spun out as a different company. Uh, so we spun out of Informal Systems into Quint as a company. And I think that's kind of like just interesting because, um, this context is kind of interesting to mention, and has a lot to do with our roadmap. The, we always wanted to have, to make some sort of like product around Quint, because I really, so my life's goal is just to get this in the hands of like more software engineers, making sure that we can trust software more. I get really frustrated when I am not able to trust software, so that's like my main motivation. And the thing is, we do, are able to do so much more when we have like a business around it and a scalable thing that can maintain the team, that can enable us to like hire more, have more people involved. So, it's really like all about like scaling Quint to the whole world, and, and we believe that making it as a business will be the most viable way of doing that in, in, in the world, um. And, so that's why we started like the, the business, and of course like we've been trying for a while, but really AI have accelerated that a lot, because with AI, we now can use AI to write specifications, they are really good at, I failed to mention this during the conversation here, but AI can write specs, like, it's, they are great at writing specs, they are language models, they are great at writing stuff in a new language, they are great at translating stuff from a language like Rust to another language like Quint. They, they are great at that. So, AI is great at writing specs, and that reduces the cost of getting started with a tool like Quint so much, which enables us to reach more people, and then also creates this whole new need for understanding and for trusting software that we are, uh, capable of solving. And, so that's why we started the company, and then now we are working on bringing a product to people that can help them solve this problem in like very easy way, and if you remember the first time I, the first thing I mentioned in this conversation was like, "Okay, I like this TLA+ tool, but I cannot convince my teammates to use it." And this has been the case since then, like, uh, ever since, because people, TLA+ or Quint, or even other formal methods within their organizations, usually there is like one person that's super excited about it, but they struggle to convince their teammates. So, we want to build something that you are going to be excited to use, and you can show to your colleague, they will also be excited, they will get value quickly, uh, and that's what we are doing. Uh, we're calling the product Quint Studio, which is just a command center for everything behavior-oriented. So, everything that I've mentioned here, uh, we are putting there, we are making sure it's easy, and making sure it feels good to use, and that's going to scale within organizations. So, we have a waitlist for the product, it's not out yet, and we are, will take our time to like do some like betas, have people give us feedback and stuff, because we really want this to, to feel and be really good, but that's what we are focused on on, uh, new Quint Studio. But we are going to be releasing some stuff on the open source as well, uh, some exciting stuff too.

Amazing, amazing. Looking forward to, to seeing that come into the wild. And, um, yeah, uh, as we're kind of coming to time here, um, just wanted to, to get your perspective on things, um, around just being a founder. Um, you, you went through that journey, uh, I'm sure, um, as every founder has and, and probably are still learning things as you go along. I mean, it's natural. Um, but for the aspiring founders that are watching today, um, is there any, um, advice, um, you'd be willing to share with them, just to kind of, uh, kick them into gear?

Well, I feel like, I am in a position of getting more advice than being able to give any, but I'll try my best. Uh, I think I can mostly talk to people that would be, uh, passionate about something and want, want to make it a reality. Uh, because that's how I became a founder, like I didn't had, I think there is a different kind of founder maybe, not better or worse, but like that just like has a passion for entrepreneurship and then looks for one idea and then that's the idea that they're going to be entrepreneurs on. I always hated entrepreneurship. Like, when I was in college, I was like, "Oh my god, I would never do that." And then I was doing Quint and, uh, I really, really loved it, and I was like so passionate, and I just wanted to do what's best for it. And then it was like, it was the time for it to be a company. and I was like, "I, I'm not ready. I don't know, it's too much." Um, and then people convinced me that this is what we should do, and I was like, "Okay, if it's the best for Quint, let's do it. Let's make a company." And it turns out it's not that hard because, uh, I'm so passionate about this, and I feel like I, almost like the vision comes to me because I want, I know what I want people to, to do with Quint, and like to leverage it, I know what it can do for people. So, it kind of like some things that I definitely didn't think would be obvious, kind feel obvious now. So, I can maybe give this like encouragement word of like, uh, I'm not sure. I'm at the beginning. It might be that it's super hard, and like, yeah, I, I regret it, uh. But for now, I feel, I'm feeling really good about this. So, if you're passionate about an idea, and you're scared about the founder life, it is, it is tough, but, um, I don't know, it's very rewarding as well. And it's so good to have great people working, uh, with me and, uh, having like the same passion, and then exchanging ideas, and being on this role where I can, um, make decisions, uh, with them and for them, and, and provide guidance, and then they come and then they do the things, and we, it works, and we are happy. So, there is definitely a lot of rewarding, uh, things, and I still have a long journey and a lot of things to learn ahead of me, but I'm glad I took, took the, shot of, the, the opportunity of, of doing this.

Yeah, yeah, absolutely, absolutely. Well said. And, yeah, sometimes you just got to take that, uh, leap of faith, take a risk, um, gamble in yourself, and, um, it's very hard to compete with someone who's having fun and very passionate about what they're doing. So, um, yeah, I, I think that's, that's like the overarching message here. Um, but, uh, Gabriela, uh, thank you so much for taking the time out of your busy day to chat with us. Um, before we, we sign off, um, what's the best way for people to keep up to date with Quint, um, reach out to you if they have questions, or just get started?

Well, uh, we have the website, we have, um, the waitlist as I said, I think the waitlist is connected to our, um, subscription so you get some email, uh, from like new blog posts and stuff. Uh, the best way probably is joining the Telegram channel we have. Uh, I'm there, I usually answer every single question there. Can also like email me or reach out on like LinkedIn, Twitter. Uh, but yeah, the Telegram channel is where most of the interaction happen. We can also like open issues and discussions on GitHub. Give us a star on GitHub, that's very helpful. Uh, and yeah, we can find every single resource on, on the website, hopefully. If it's not there, just let me know.

Amazing, amazing. And, uh, yeah, folks, all, all those resources will be linked in the podcast description below. Um, so definitely, um, give that a check out, um, if it so interests you. Uh, but with that, uh, just want to thank you again, Gabriela. Uh, really, uh, enjoyed our conversation. Uh, I know our audience did, too. Um, and, uh, yeah, wishing you and the company best of luck, uh, going forward. And I'll be on the lookout, uh, when, when the studio, studio is out.

Thank you, thank you so much for having me. I always enjoy these conversations a lot, and, and this one was very special.

Of course, of course. My pleasure for, for hosting you. And, uh, yeah, uh, with that, just want to wish everybody a very happy Friday, happy weekend. Um, enjoy that FIFA, uh, while, while it's still here. And, uh, we will catch you back here for another great episode of DevNTell next week. Um, till then, have a good one, folks. Cheers. Bye.

Bye.