Jake Aaron Villarreal: I'm Jake Aaron Villarreal, born and raised in Silicon Valley, here to take you behind the scenes to share what it's like to be a startup founder, the journey they're on, the problems they face, the products they build, in an effort to make our lives better. I'm excited to have with us today Kevin Kissi, co-founder and CEO of Zof AI. Kevin, welcome to the show.
Kevin Kissi: Hi, pleasure to be here.
Jake Aaron Villarreal: Well, Kevin, thanks for joining. Where are you dialing in from today?
Kevin Kissi: I am in Oakland, California.
Jake Aaron Villarreal: When I started this podcast, I had this vision to go behind the scenes to share what it's like to be a startup founder in Silicon Valley, where I'm born and raised. And weekly, we dive deep in the trenches to find the wins, the losses, and the lessons learned with the hopes that it helps you run a better startup. But here's the thing. If you've gotten any value out of these conversations or been inspired at all, hit the subscribe button. And I get it. Your podcast feed's probably overflowing. But to stay up to date what's going on in Silicon Valley, stick with us because at the end of the day, we're all just trying to build something that matters and we're better when we do it together. So, hit that subscribe button and follow us wherever you find your podcasts. Now, let's get back to the show.
Okay, great. I love Oakland. I just drove through there this, this weekend. So, it was beautiful and all sorts of exciting stuff happening there, which is, by the way, if you don't know, Oakland is really part of Silicon Valley. It's just across the bay from San Francisco and there's a lot happening there. So, a little bit more about Kevin before we jump in here. He's a seasoned software engineer leading an AI-powered software testing platform with nearly a decade of experience, including leading engineering teams at Microsoft. Kevin brings deep expertise in AI, machine learning, and building impactful software solutions for startups and enterprise systems. Kevin, we had a call a few weeks back about kind of your, your upbringing and where you're from. And you know, there's a lot to tackle there, but you know, what are some of the earlier experiences you've had that have shaped the path you're on today?
Kevin Kissi: I think the, you know, I think I can date it all the way back to I saw signals of wanting to build something that, that solves people, something that is as close as possible to an oxygen, oxygen service. And so I mean it just carried along, just wanted to have an impact. People you know, seeing that my work is something that people use to get from point A to point B. And over time how I carry out that mission has changed. He has been through consulting, has been through working in corporate America, and he has also been through being in venture, worked on you know different other startups over the time. Also been through nonprofit as well. So that has always changed in how I manifest that into the real world, but in Zof I truly believe that we're building something that is closely aligned to that.
Jake Aaron Villarreal: Really cool. You know, working for a big company like Microsoft has advantages and also opens doors for you. What was the big break or what was it that you saw that you felt like, 'Hey, there's an opportunity to try building something on my own and building a team,' and and maybe this isn't your first startup, but what's the opportunity that you saw while working there?
Kevin Kissi: I think I got to see how big, big of a deal QA is, you know? Because if you're dealing with a high fidelity product that we dealt with, with billions and billion people actually using it. And for my case, I mean, our solutions ended up on billions of devices, right? Millions of devices. And so quality becomes a very, very important aspect of our work. We spent a lot of our time on that. We spent a lot of our time on QA. And so I got a chance to see also how much Microsoft spends on QA as well. The vendors that are part of the process, how inefficient that process is, how painful it is for engineer managers to manage, work with vendors, work that can be fully automated internally, and how taking full ownership of QA meant that you have a productivity decline of the features that you're also responsible for. And so that's what kind of forces the organizations to consider looking elsewhere instead of...
Jake Aaron Villarreal: Yeah. Well, that's great. And you know, the market is a massive part of software. If you think about it, any product that you use today, whether it's on a mobile phone or your laptop, is software that's been tested, because if it doesn't work, you won't use it. So the numbers out there are, you know, billions and billions of dollars spent annually. And of that, you know, 1/5th of that, whether it's testing or software development, is typically for just making sure that it works. So today, we'll be talking about atomic-size agents that enable teams regardless of technical expertise to automate their testing for web applications and mobile applications, solving 99% of bugs with AI. So I guess give us, give us your sort of high-level 30,000-foot view of Zof, Zof AI, of you know how it's redefining testing and kind of what, how does it work?
Kevin Kissi: Yeah, from a bird's eye view, um, you know, we believe that if you build agents that are limited enough in scope, um, you can get to the point where you can actually get higher levels of accuracy and consistency and dependability as much as possible. And, and then you just build a way of being able to command those agents at will to be able to have a whole workflow. Then you can actually tackle all of QA under one roof. And so that's the journey that we've gone on. You know, I could probably get into our thesis of why, you know, we exist the way we do. We believe that all our software at some point will be for the most part being built by AI, right? We believe that it's going to, going to be at a point where a small piece of software generation and software development is going to be done by humans, right? Now we might see that software development using AI tools like you know, Cursor, Lovable and whatnot, they might be at the junior level engineer.
But I think over time they're going to continue to get to maybe say level two software engineer, or maybe you know, level two software engineer would be someone that can work without any supervision. And then maybe like senior that can actually you know get to a point where they can actually orchestrate and, and figure out what other things to consider and lead on, on things. I think we'll get to that point over time as the workflows become a little bit more, a little bit more not complex necessarily, but more, more capable. And so with that premise, QA needs to follow along, right? QA also needs to be fully automated with no human in the loop. Be able to meet that speed of development, right? The velocity has changed. The velocity is, you know, several X. I want to say 10x, but I would definitely say it's way more than 10x.
And so with that approach, and also because the fact that QA is that you know, piece of software development that gives confidence to go to production, you don't have much room for errors, right? You need to be very much on target with accuracy. And so with that, you know, the best approach that I see is that you need to build smaller things that can yield that level of accuracy, right? And so that's why we've taken the approach that we've taken. And, and then being very precise at orchestrating that. And then also the approach of no human in a loop obviously is, is evident of the fact that you know, if humans are not building the software, then we need to find ways you know to test without humans needing to be part of that workflow.
Jake Aaron Villarreal: So yeah, I mean when you talk about the tools that are out there today, and you mentioned a Cursor and Windsurf and a number of other tools that are being deployed that actually help engineers code a lot of what they're looking to build. And maybe at some level it will automate all the coding. Who knows? There's always been a conflict between the developers building a product and then having another set of eyes to look for the bugs or look for the problems that are in the code so that they can then alert them to fix it. Where does a tool like this fit into that scenario? Whether it's someone doing the building themselves, developing, or code-automated tools that are actually developing without any humans in the loop. I don't know, is that, is that currently in the market today?
Kevin Kissi: But we are going to make it in the market, where you know you can just command an, an agent like maybe Windsurf or Cursor or whatnot to uh build you a specific capability, right, within software. It, it's going to orchestrate itself, build it for you. And then it's going to call something like Zer... Zof to also test and find the bugs within that, and check to see that it, it met your requirements. And then if it meets all of those requirements and you know even meets like security you know standards, it meets like compliance and all these other things, then it will just go into production right away and your users can start using it right away. So that's, that's the direction that I think we're going to, we're going to be in the very, very near future, not very, very far from now. We're just, just a few weeks away from that.
Jake Aaron Villarreal: That's amazing. Wow. So the outcomes would be that as an engineer or tools that are developing code, your system integrates and automates the testing, creates the test cases, the test automation, delivers, you know, the bugs that it finds. Does it actually fix them on the fly or does it just alert you to here's what needs to be fixed?
Kevin Kissi: Yeah. So today we are alerting and bringing attention to the bugs that we find. But we also could have a feedback loop that we're working on right now, so that the agent that you're using to solve the, to actually build the, the solution for you can also address those bugs. So we actually do have, today we do have a feature called Auto Assignments. And so that means that we'll assign a bug to either a human or an agent that you're using. So you're able to track who caused the bug and assign it to that person, whether it's the human or an agent. And so you can have that continuous feedback loop, that and at the end of the day we get to a point where we get a finished product that you...
Jake Aaron Villarreal: Yeah. You know there's so much conversation today about agents and AI agents and orchestrating and managing agents. What's the difference between an atomic agent versus an AI agent from a layman's perspective?
Kevin Kissi: Yeah. So I think you know, for us, we just came up with that word, um. An atom is that smallest level of, of matter, and so our idea is that the smallest possible QA agent within a QA discipline. Like say within security, there's several you know atomic size u, within that, and we have like say an agent that all it does is just look at SQL injection. Just does SQL injection, nothing more than that, right? So we consider that atomic size agent and it does a very, very well, considering. And so that's what we mean by you know atomic size. I, I think I missed part of your point. I don't know if I'm answering your question.
Jake Aaron Villarreal: Yeah, no, I think you are. I think there's a lot of different words out there today around agents and you know it means different things to different people. So for you it's essentially taking a granular look at agents and you know, if I think about a platform like yours that you're building, give us an idea of how many agents are actually collaborating, working on bug finding and fixing when it comes to QA automation today.
Kevin Kissi: Yeah, before I get to that, maybe I, I missed some key parts of that earlier question. So with you know you know, limited scope agents, atomic size agents, the difference is that they have all the context on what they're testing and no other context whatsoever. Right, there's no other anything else that they know, they have any you know visibility to, they just know this and that. That's it. Other agents out there might be a little bit more generalized. As in, "Hey, you give me this prompt and I'll figure out how to solve it for you," right? So for us, atomic size, you give anything else that is not related to say SQL injection, it won't be able to do anything. You know, so it's just that one tool that does just that. And then following up on your next question, which I just forgot.
Jake Aaron Villarreal: Yeah, no worries. Hey, I'm ask, I'm throwing a lot at you here. In terms of like yeah, the number of agents. There's so many platforms that have you know this orchestration layer of they've built agents that then manage it, and it's might be a few, and some are like there's much more because the problem they're trying to solve is, you know, maybe more complex. So, kind of walk us through visually if you can, for the listeners that aren't able to look on a screen. Like what is, what are we really talking about?
Kevin Kissi: Yeah. So, I mean, we're talk... so what I try to tell people is you imagine a company, right? There are so many people with different roles, you know, and they have like specific, you know, OKRs for their role. They have descriptions for your role and they do just those things, right? And then they have a manager that sits on top of them for that particular, you know, area, and then that person has another manager that kind of... and but together they all move together as a company to accomplish one thing for their customers, right? You can think of it the same way as a set of agents that are trying to, you know, give a green light to go to production, right?
You have all these agents that are focused on just this or that, and that. And they sit under a category of testing, say maybe security, say compliance, maybe say you know, you know, compatibility testing that has multiple agents under that. And basically it's managed by you know sending specific test requests to that... well, I don't want to get into the details of how we do it, but essentially we have a similar structure in terms of managing these agents and being able to call the right agents for the right test case. That sort of thing going on there.
I think you know, the orchestration is probably one of our biggest IPs. You know orchestrating a whole workflow that engages multiple agents uh, and then being able to aggregate that data all across you know what we get from all these different agents and then making sense out of it, and then you know distilling it down for the user to say, "Hey, this is, this is the outcomes of your test workflow. Is it a green light or is it a red light to go to production?" Right. I think that is that crit-, critical sauce or critical recipe that we have that makes us a lot different and makes us uh more capable I suppose. But this is, this is the trajectory that I think we're all heading. Anyone who is in the QA space, if they are not, then I guess there might be a problem for them very soon as we offer you know 20X the value in the market. So that, that's, that's... and that's you know, even for other functions like say you know legal, you know other, other areas. If you're tackling say a case, there are so many aspects of the case that need to be researched. So if you're using agents to do that, you need to figure out how to manage all of that and aggregate all of that information and then come up with you know strategies and whatnot to execute where you need to.
Jake Aaron Villarreal: Yeah, you know, QA is... you know, we are a recruitment company, but we have built our own applications and testing and we at one point were providing testing services to our clients too and we talked a little bit about that. You know when you're talking to a company, and if you, by the way, have never developed software or tested it, there's like this whole process that you have to define what you want to test and what do the test cases look like. In other words, like what are you going to ask the application to make sure it does well and then test it to see if it actually performs. And so test cases just alone take you know, this is a while back, but it would take a company like you know weeks to build these test cases.
And then at some point come to us and say, "Okay, every single function of our application needs to be tested. So run these test cases to see if you can break our system." And then you get back to them and you know two or three weeks later you've got a report of, "Here's what worked, here's what's broken, here's a video snippet of what was broken and now go fix that software developer." It's a lot of work. Yeah. When you talk about test cases and workflows, like how big of a library do you have to support multiple clients, multiple enterp-, enterprises? And how quick is it to actually engage your platform and start using?
Kevin Kissi: Yeah. So right now actually we do have the, the enterprise grade 2.0 services live, but not yet GA'd yet. So that's something I'm really, really proud of. We got it working just yesterday, everything talking to each other and everything. Basically, it's infinitely scalable, right? If your application is large enough, we might end up generating say 200,000 test cases for it, right? A human might not... human might, might not be able to do this, right? We have higher permutations of these test cases that we're generating because we want to make sure we don't miss any edge cases, but we're also in a trajectory of, you know, finding optimization within that, right? We might have way more test cases than needed, but that's because we want to make sure we don't miss anything as well, right?
And so trying to figure out over time... so when a customer jumps onto our pro-, our environment to start using us, over time we might not keep generating more test cases for that same application. Maybe the first time we generated a whole lot more test cases because we're, we're trying to cover everything. Right? Now, over time we come to have a very clear understanding about how the application works, what are the defects, that sort of thing. And so another test run on that application is, it has a much more deeper context from a previous test run. And so then we're able to just be more on target. And so that's basically like you know how things are functioning today. Did I answer all your questions?
Jake Aaron Villarreal: Yeah. I mean there's so many different categories as well of testing. Exactly like, where, where, what does your platform cover?
Kevin Kissi: Yeah. So we are covering all categories of testing. Not having all the agents online. Currently we have 26 agents that precise-, precisely do... we have about I think 17 that are not live yet, but the ones that are deployed today, 26 of them. And we're covering anywhere from interface testing to load testing, stress testing, endurance testing, security... we're touching some aspects of security, not all aspects of security. We're touching compliance, GDPR compliance. I think you know these, these other categories have businesses that are focused solely on that, but they're not fully automated with agents. So we have, uh, disciplines as well. Um, and so...
But when it comes to say unit test, we don't actually generate the unit test in the workflow, in the one workflow that's... that's the workflow is usually for like late stage test, that is after you build the app and you're trying to see whether it can go to production or not. But when it comes to say unit testing and whatnot, we have a, a different workflow where you go and you target a specific agent, like say the unit test, set of unit tests. We have a unit test agent that generates the unit test for a specific language and then also has... we also have a generation agent that is also going to you know sandbox your application, test everything, make sure that all of the, all the unit tests that we, we have generated work properly, and then we give you a detailed report, that kind of thing.
So yeah, we have um also like integration, end-to-end test. We find a critical path so we can actually test everything, make sure all your different services are talking to you, to each other. That is, all the con-, that all of this is possible because you give us your requirements documents that gives us the context of you know how to gen-, accurate test cases and what we need to test for. And then also, even a step further um, is we want to, we want to get to a point where you don't even need to give us the requirements documents. Our crawling of your application and, and other aspects should be enough. So that's, that's what we're working towards. But today we do also crawl and gain context and scope of the application as well. And then we add it all together to the requirements document that we... you've given us, for something that we call internally a "context file," of which we use for generating these test cases.
Jake Aaron Villarreal: Got it.
Kevin Kissi: That... to, to some degree able to cover your entire applic-...
Jake Aaron Villarreal: That's really cool. So if a company has built an application, they give you a, a requirements document and they say, "Look, we want to use Zof AI from beginning to end," and probably depends on the complexity of the application and how big it is, enterprise versus maybe a mobile app or whatnot. What, what's the reality of you being able to come back to them and say, "Okay, we're ready to go now. We're going to do the testing and here's the result." Like how, what can they expect in terms of delivery of making sure their application is running well or at least it's getting accurate insights about where their bugs are and they're being worked on or fixed?
Kevin Kissi: Yeah, certainly. So, you upload a requirements document. You give us the... of your current when... if it's live, you give us a dev, you know, version of it or whatnot. And chances of us being able to give you a no go or go is very high. Based on... it's, it's related, based on the, the requirement, the depth of the requirements document you give us. If you give us all the parameters that is necessary to test, say when it comes to say API testing, if you give us you know clear parameters for doing API test, we don't have to come back to you and say, "Hey, we're missing context." Some of our agents, one of the things they come back with is, "Hey, we're missing context."
And then through our specification studio, you can give us the details that we request. So we have another feature where we go through the requirements document with you and then we say, "Hey, these are different things that are opportunities for us, so that we can get to the point where we can have full coverage of our testing." And so that's where we just kind of like have that, you know, feedback loop with the user. So we can make sure we have proper context from what we're testing. So I mean, the reality of us being able to get to the point where we give you everything that you need um tested and then being able to say, "Hey, it's, it's ready to go to production," is based on how well documented your requirements document. A lot of bigger companies, they tend to have much quality requirements documents. And then smaller companies that might not you know follow that kind of hard process might just have user stories here or there that might be missing from requirements doc and whatnot.
Eventually we find out that they don't have enough of that information through the first test, and then we come back to them and say, "Hey, you need to give us this," and then we test again and realize, "Hey, you gave us something that is not accurate. You need... we need more information here," and then we work together until we finally get to the point where everything is covered. And this is all just you interacting with you know, AI agents that are in the back end that are figuring out all... and we get to that point. And we're also scoring our, our process as well. We're also scoring and telling you the coverage level that we've reached. And you can also give us feedback. You can give the agent feedback as well. So it can actually position itself to the point where you are at an absolute in your testing journey.
Jake Aaron Villarreal: Got it. You know, one of your selling points is it's a no-code testing platform. How does this change the role of QA engineers or product managers?
Kevin Kissi: You know, one of the things that we've been seeing with, you know, interacting with certain customers is that they want someone, some human to be an, an owner of some QA work, right? And so even if they're using us to test and they don't have to actually get into the code or anything, that person is going to be the one that you know logs into the platform with the requirements doc. Or that person is going to be the person that's you know, provides any missing context. You know, some of our customers have even asked us to allow them to be able to modify the test cases that we generate. And so in order to do that, you have to go into settings and then select manual mode to be able to go in there and be able to edit some of the test cases.
That is not where we want things to be. Eventually, we're going to be pushing... this is, that is a signal that trust is not there yet, right? And it's a journey. Eventually, the trust is going to be there. They're going to see that, "Oh, the test cases are being generated are on target, right? Modifying is not probably the best approach. Given more information, the requirements document might be a better approach. Or, or based on how they've built the application, they're going to over time get better and better about how they want to build as well. So that it's testable application by AI." Um, so maybe you've, you've hardcoded certain things in your application, and so then it's hard to find those key parameters, then obviously we're going to struggle to be able to test everything, right? But maybe say you're storing this here and you're giving us access there, that kind of thing. Do a better job at testing.
So you know, someone is, is, is an owner, or you know, we're building such that all the team members in an engineering team can be on Zof, and that way we can actually track how everybody's doing in terms of their quality standards, right? So for, one of the key features for our application is that we're able to look through all the commits. If you have an engineer on your team that is causing most of the bugs with their commits, we're able to identify that person, and so that person is going to be scored differently from someone that has fewer bugs with their commits. And someone that is also meeting SLAs in terms of fixing those bugs soon as they appear and surface. So that person is going to have a much higher quality score. And so the whole entire team gets to be on the platform and participate in this QA journey for any organ-...
Jake Aaron Villarreal: Well, you know, it's interesting, you know, you have companies like Meta and other big organizations that they say, "Look, as an engineer, you're going to develop a feature or a function, and you're going to own it. You're also going to test it and make sure it's ready to be deployed." So, if this is a tool that helps an engineer do their job better on the testing side, which I'm sure you probably don't like to do that much, I mean, you built the application, you think it runs well, but there's going to be some bugs. I mean, that's natural. But to have something that can automate finding those without you having to do the work.
Kevin Kissi: Yeah.
Jake Aaron Villarreal: I mean, why would you not want to look at that as an engineer and forget about like anything else? So, the question I have for you is who are you selling to within a company?
Kevin Kissi: Who's most excited about this type of technology? And so I mean, given my background, I built with you know, the, the point of view of engineer management, right? Our goal has always to be to create more capacity within our teams, right? And in order to do that, you need to u- find some optimizations within you know, the work that your team does, right? If you're spending some time, a lot of time on QA, and that can be fully automated, why not use that solution that does that for you, right? And then your team can also own... Also, another thing too that to consider is that you want your team to own QA as well. You don't want it to be handled by some vendor which you have to be managing as well, and they might not share your quality standards. But your team is directly under your control, right? And so you are able to, you know, torture them into you know, adhering to your quality standards as a manager. And so when you have a tool like this that is, sits within your team as a member of your team and your team is subscribed to it, you own all of the QA process as well, right? Anything going to production, it's you know, you're able to, you know, have full control of your fate, knowing that whatever you put into production is well tested and it's bug-free, right?
Whereas if you're, the alternative is if you have any external team members that are working on something, you know, then you, you, you risk, you know, either losing more time to checking their work or risk maybe sign off on something that might have some bugs on it, right? So our biggest customers tend to be engineering managers that are within you know teams, and they are the first people to get adapted to this, right? Engineers also see like, just single individual engineers also see value in just being able to not have to work on QA at all, right? You know that painful aspect of testing everything. Like, for example, if you're building something, a small feature that is you know UI-based, not that you just only have to do the unit test for it. You also have to go and check the UI as well, right? If you have to go and check and make sure everything is working. I mean, that's double work. You know, you're doing the code side and you're also doing the interface side.
What if you had something that you're plugged into that is automatically generating the unit test for you, testing the unit test, making sure that you haven't broken any integration issues, you know, you're able to do regression on the fly, you're able to test the UI. You have multiple you know browser agents that are spun up and testing various aspects of that for you, coming back to you and telling you, "Hey, this thing is not working, focus on this," telling you how to fix it as well, right? A good percentage of your work is automated, and all already you're also using tools like maybe Windsurf or Cursor to also improve your production. So it makes sense to also even go a step further and also doing you know more strategic work instead of broad work, by also having those two parts being automated for you.
Jake Aaron Villarreal: So yeah, that's amazing. And I, I see a lot of value in not just the automation, but just also the culture. Because if you think about it, you have engineering that's working with QA teams, and there's a lot of friction that can happen there. And oftentimes, you know, maybe your star developers are a little bummed out at times when they're being scrutinized about their tech and you know, it doesn't have to be like that. If you have a system that's supporting them in a process that's automated, it's, you know, not an energy leak, but helping them actually do their job better and faster and more accelerated. So, I, I see a lot of positive to this, to what you guys have built and what you're continuing to innovate. There's a lot of AI tools in the market today, and a lot of them are coming. What's, what do you see as your advantage in, in how you maintain your position and also continue to build in a, in a crowded space?
Kevin Kissi: Yes, this space is very crowded. What we're seeing is, you know, I've seen a lot of generalist solutions out there. And I think they end up not having that, the quality that is needed, you know, to give the confidence. At the end of the day, you're trying to give a team confidence that whatever they've built is good enough to go. And then you're also giving them uh suggestions and identifying the bugs that they need to fix. And you need to, you want to identify them fast, right? The way we stand out is quality, right? The quality of our testing, and that's based on the approach that we've taken. And then also the fact that you can actually cover more horizontally, right? Vertically, you have more accuracy. You can hone in on just targeting just one specific agent and say, "Hey, this agent, I want you to do this for me." Scalability agents just ch-, test to make sure that if I'm scaling my application, I shouldn't run into any issues. Right?
So, we have that critical thing you can do at any time. You can just go and select whatever agent you want to select. A lot of different competitors don't have that. They're just like, either they are one size fits all or they just focus on just one thing. And so what you find yourself doing is that you have to use this tool for that thing, you have to use this tool for that thing, you have to use that tool for that thing. When maybe you could maybe just organize a workflow that does a lot more for you, and then that workflow is not going to be something that is so generalized that it misses like you know 30% of the things that are very important to you, right? We, you know, our goal is to be at 99.9% accuracy and we work towards that. And, and, and the fact that we're, we're, you know, using atomic size agents allows us to be close to that as possible. And so, you know, in the market, we're changing the way QA works by just saying, "Hey, instead of worrying about unit test, this is just something that should disappear, right?" It should just be in the background. You, you're building something. You don't need to think about where you need to test, how you need to test it. It's just done for you, right? You just get results. That's it.
So, we're that company that we want to, you know, it's different from every other company, you know, but we are that company that wants to disappear, right? We want to, we want to, we're building a solution that basically just sits in the background. It just works and it works perfectly all the time and you don't have to ever worry about it.
Jake Aaron Villarreal: Yeah, that's a perfect solution for today's world with AI accelerating so much, and it's, it's incredible to just see the growth and the transformation across all industries. So, I know there's a huge market, huge opportunity. It sounds like you're building something incredibly useful. You know, let's switch gears for a moment here. Talk a little bit about the company size and where you're at employee-wise and just lo-, generally located. Are you, you know, local? Are you international? Walk us through the culture, your company.
Kevin Kissi: Yeah. So, we've done some really creative hiring, you know, because we, we, we realized that we need to build a lot of these agents fast. And so, we brought, we brought on a lot of interns. Sorry, excuse me. We brought on a lot of interns that are working full-time. We are about 46 currently in the, in the company. Engineering is most of it. And then also we care a lot about distribution. So marketing is also a decent-sized team. Our marketing team is actually quite technical too. There are data science people that are coming up with different ways of reaching customers and different technologies for converting and re-... And so that's the, that's basically the, the size of organization. We have multiple people in different parts of the organization. It's, you know, it's, it feels like a big company with a bunch of interns that are working, you know, you know, as full-time employees. But yeah, that's kind of like what we're, you know, what we got going on here.
Jake Aaron Villarreal: Yeah. Talk a little bit about that because I think interns have different levels of expertise. And some are, you know, in the beginning of their college career, some are graduated and they're just looking for their first job, but they'll take a role on that's defined as an intern. How do you define an intern?
Kevin Kissi: Yeah. So, I mean, so we were very, very strategic in the interns that we brought on. Like some of the interns we have, they used to be full-time employees at Microsoft, full-time employees at Amazon, and they went to do their graduate degree. Some of them have, a good percentage of them have actually finished their graduate degree and they are in the market and they are doing an internship with us because they believe in what we're building. They know this is the future. This is something new and it's exciting to be able to attract such folks. So, a lot of them already have some experience, right? Maybe level two software engineer somewhere, but now they're just doing their masters. And so, maybe they're in between their masters and so they're taking an internship while finishing their masters in computer science or whatnot. And so, that's the kind of people that we have in-house.
And so, and yes, we, we do have maybe like two or three that are undergrads, like senior undergrads, but they are very performant as well. They come in, they see everybody here, and then it grades the standard and, and the level at which they also have to perform. And then over time you see that they actually end up at that same standard. Coaching them, it takes a lot to do when you have interns coming in and they don't have already the experience. But when you, when you look at the trajectory of when they came in and what they've been able to build, it's only a matter of time until they get there. And they get there very quickly with these, you know, AI tools that are already out there that they can also benefit from to help them bring things, right? You know, my team uses, you know, Cursor and, and Windsurf and all these other tools out there to actually help them build fast, right?
So, in today's world, you can, you can basically get more context about how to build something by just asking an LLM, "Hey, how do I approach this problem?" Right? Without, without them having to come and talk to me and ask me, "Hey, how do I build this?" So, most of the time it's not like I'm having to like coach them on how to fully build something like in terms of like the man-, granular, getting into the granular details of that. It's more so about context and direction and approval to take this turn or take that turn, look into this door a little bit more, or maybe take a pause and then focus more on this. So I spend a lot more time on that than actually you know, get into, "Hey, this is, this is how you should write this you know, this piece of function," right? You know, sometimes I'll get into that just, just, just to be more, you know, you know, accelerate things a little bit more. You know, also I like to be a little bit closer to code too, even though we've just become more like a system now. But I want to, you know, I want to continue to stay closer to code and I try to contribute as much as I can to the code side as well. But yeah, you know, interns can actually still yield this, a decent size productivity or velocity as someone who is experienced.
You know, someone who is experienced might have some bad habits. They might feel like, "Oh, maybe I shouldn't use, you know, this LLM because I feel like, you know, I've always done it this way." But maybe if you ask, you know, you know, this LLM, you might come up with multiple different ways of approaching that problem that maybe you might not, you know, consider, right? And so these kids have that bias of doing that right away or, or starting there first and then questioning their ideas of how they wanted to approach it so that they can be on target from the jump, right? And so I mean there's uh there's, there are definitely some you know you know, plus, some minuses to consider on both sides of you know. Initially I, I considered maybe if I want to hire a team I'm just going to focus on seniors and principals because they just need to know how to use LLM to do especially what they need to do you know. Because you know that's the tools we use today. But I think with enough sufficient leadership you can you know, good enough leadership you can actually get a team of interns to produce good work as well. I'm very, very impressed by the things that we've been able to build, like things that have not been built anywhere else on this planet have come out of interns. And so I'm very, very proud of what we've been able to do with... we were able to achieve with interns.
Jake Aaron Villarreal: Yeah. Really, really cool. We haven't heard that a ton. So, it sounds like you, you're on to something that's really helped your company accelerate and really continue to do what you're doing. I think that's incredible. What, what's something that you wished you would have known before you started your company that you know now that would be helpful for others to learn as they start their own startups?
Kevin Kissi: Yeah. Yeah. You know, I when I started this company, I thought it was going to be easier to raise capital. I really thought it was just, "Oh, it's simple. You know, I have the experience. I have a clear vision about what I'm trying to build. You know, if I partner with, you know, a co-founder that has this and that, you know... I partner with somebody that has a PhD from Harvard," I thought. And also has raised, you know, money in the past from VC capital. And I literally empowered with someone else who also had a Harvard MBA. And I thought, "Oh, that those are checking the boxes, right? I'm trying to check the boxes. You know, technical guy that knows what he's doing." But it turned out that it's a little bit more complex than that. It's a little bit more grunt work than that to some degree. Sometimes you don't even know what VCs are looking for anymore, because we try to check all these boxes and still come up short. And so that's something that, you know, I should have known.
I think over time I, I got caught on, right? I got caught on by figuring out that, "Hey, we can just hire interns. You know, we can just hire interns." I mean, the goal was, we raised capital, we hire that super team that does what we need them to do. And because we're using interns, maybe we, we get 2x the number, so we can get the same velocity that maybe we might have gotten if we had like a smaller, more experienced team. And so, I mean, I've learned a lot over time and I've found ways to improvise and, and, and pivot to, to make sure that we get to where we need to be. Um, but yeah, it's, it's, there's a lot of ups and downs. You know, I think, I thought it was actually harder to get customers. C- Getting customers is a lot easier, a lot easier than actually getting VC. And so now we're focused solely on just our customers. Because you know it's, you have to tackle the things you can win at. All right, we can win at getting our customers. But if we can easily win at you know VC capital, maybe we focus on that, that can show up later. That's the, that's the way we've been approaching things.
But we just you know spent a lot of time just like you know, create, maintaining the excitement within the company and externally as well. And that has you know given us a decent size you know wait list of people that are waiting to try you know version 2.0, that kind of thing. So I mean that's you know, those are things that I thought you know, "If I move to SF and I focus solely on this, I do nothing else but that, you know, I quit real estate, find someone else to manage that, I don't do anything but just Zof, nothing else, good things will happen very, very quickly." But it turns out that it's a longer journey than that. So that's one of, another key thing that I've come to realize.
Jake Aaron Villarreal: Yeah, well proximity is power. So the fact that you are in Silicon Valley will it be helpful when it comes to building those relationships with VC firms if you need it? Sounds like you might not need it, but if you do... I like the strategy that you have with interns and building product and focusing on the customer. Because at the end of the day, if you don't have the customers, VCs aren't going to care, right? Like you have to show client usage, low churn, revenue, growth. So those are all the things I think that are fundamental. And then you look at like strategically how are you getting to market, and if you have data scientists that'll help you on the marketing side... I mean, it's all about the data and the outreach and the systems that can help pull in, you know, u-... getting above the noise with all the AI tools out there. That actually something that we work with that actually delivers, that you can try, that you can do it quickly and see a good outcome. I mean I think you're on to something really cool here. So, uh, if anybody wants to find Zof, Zof.ai, where do they go?
Kevin Kissi: Yeah, just, you know, go to zof.ai and yeah, our website will guide you towards, you know, pricing page. You sign up and then you're, you're right there into using this amazing product we built.
Jake Aaron Villarreal: Really? Awesome. And Kevin, if they want to find you, where do they go?
Kevin Kissi: I'm very, very active on LinkedIn. You know, that's one place that if you want to kind of listen to a lot of the random thoughts that I have, you can definitely follow me and, you know, connect with me on LinkedIn. But yeah, all over the place in SF. I go to a lot of these different events that I think are worthwhile, worth being at. And so, if you're in SF, chance of you running into me at the different events is also possible. You know, once in a while it's better to leave the office, you know, not be cooped up in here 12 hours a day, 16 hours a day. And so going to some of these tech, tech events that are going around SF, it's, you know... I just basically just wake, you know, just look on Luma, what's going on today? I'm like, "Okay, well, this is a good break." Yeah. So, that's another thing, another thing that I do and I get to meet a lot of people that way. I met some cool folks like... I went to events hosted by Linchpin. I met the founder and CEO of Linchpin. Great conversation there. So I mean I go to some of these interesting events and I meet cool founders and have a good chat and see how we can work together, sort of thing.
Jake Aaron Villarreal: Yeah. Well, thanks so much for coming on and sharing your story. Really appreciate you spending your time with us today and for the listeners for listening. It means a lot to me. I'm your host Jake Aaron Villarreal signing off for now, but can't wait to catch up with you all in the next episode. Until then, Kevin, the world, take care. If you like what we're doing, don't forget to subscribe, leave a review on Apple Podcast or wherever you listen, and follow us on YouTube where we go behind the scenes to learn what it takes to be a startup founder.
.jpg)
.webp)
.webp)
.webp)
.webp)
