BUILD

SUCCEED

David DeRemer:

Hi, I'm David, and this is Build to Succeed from Very Good Ventures. Today we speak with Kevin Smith and Mikel Corcuera, the co-founders of the AI-powered podcast app, Snipd. In this episode, we learn about their experience building with AI to create an innovative product that uses AI, so let's build some knowledge. All right. Hi, Kevin and Mikel, welcome to the Build to Succeed podcast. Thanks for joining us today.

Kevin Smith:

Hi, David. Thanks for having us.

Mikel Corcuera:

Yeah. Hi, thank you. Thank you so much.

David DeRemer:

Absolutely. So given what you guys do, I wanted to maybe get us started with just a little quick question of so what is your favourite podcast at the moment, given that I'm sure you guys are seeing quite a lot of podcasts these days?

Kevin Smith:

Mikel, you want to start?

Mikel Corcuera:

Yeah, I can start. I'm currently listening to Legacy. It's two reporters who tell the story about famous and influential people. I'm currently listening to the episode about Freud. Well, the episodes, four episodes per person, more or less. Yeah. It's the Freud episode and it was recommended by my girlfriend who's a psychologist, so that's why I started with that one.

David DeRemer:

I'll have to check that one out.

Mikel Corcuera:

Yeah.

Kevin Smith:

I'm a big fan of Lenny's Podcast. As an example, Lenny is a former product manager of Airbnb, and he has startup people on product, people, founders. And basically, they talk about building products, growing products, and it's always super interesting. He always has super interesting guests on, so I can very much recommend it.

David DeRemer:

Nice, yeah. We'll have to get links from you guys and we'll throw them in the show notes for people who want to check those out. So given the question about podcasts, maybe we should give a little backstory around why we would start there. So maybe for those people out there who haven't used Snipd yet or have come across it, can you guys explain a little bit about what it is? And maybe try to like what's the elevator pitch, the quick summary of what you guys do?

Kevin Smith:

Yeah, yeah, definitely. So Snipd is an AI-powered podcast app. For everyone who listens to podcasts, I would say just as your audience, who listen to podcasts to learn, follow their curiosity. So we have a lot of AI-powered features like you can chat with the episode, you get AI-generated chapters. We also generate little mini-bios for each guest. But the feature that we're most known for and also where our name Snipd comes from, is the ability to save any insight that you hear in a podcast, simply by triple tapping your headphones. So how that works is whenever you hear an amazing insight, you triple tap your headphones, and now AI summarises the insight that you just heard, and saves that together with the original clip. And all of this together we call a snip and we call it snipping.

David DeRemer:

I love it. So what's the story that led to this? How did you guys come across this idea? What led you to each other, I guess, to start Snipd? And where'd you get this kind of concept that you wanted to commit all your time and energy to it?

Kevin Smith:

Yeah. In a way, it's interesting because I think the answer to both of those questions, it's almost the same answer. So my personal story, it starts with, before starting Snipd, I joined an early-stage tech startup here in Zurich, and it was my very first experience in working at a startup. And even though one of the things I had studied before that, so I had studied mathematics and economics. You would think that if you study economics that they would teach you anything about how to build a business, and in particular a startup, but of course, they don't. So I had no idea how any of this worked. So what the founder did, he recommended this podcast to me called How to Start a Startup by Sam Altman back when he was CEO of Y Combinator.

And I listened to this podcast, and for anyone who doesn't know it, basically it was a lecture at Stanford. Every episode was one lecture, and they would have one of the biggest, best entrepreneurs that we've seen in the last 20 years be the guest and they would just talk about one topic. For example, there was Dustin Moskowitz from Facebook, or Paul Graham, Peter Thiel.

Peter Thiel is the founder of PayPal. So here I was in Zurich, in Switzerland where we're based, riding my bike to work every morning, and learning from these incredible people that are living on the other side of the planet. And best of all, I'm doing all of this while not even losing time, because I would ride my bike to work anyway in the morning.

So this was how I got into podcasts and really learned or realised for myself how podcasts are one of the largest knowledge libraries in the world that humans have ever created. And it's this very enjoyable way of consuming information, but of course, I ran into a lot of issues. You'd be on your bike, the typical thing is you hear this amazing insight. Peter Thiel drops some contrarian knowledge, and you want to remember that. And you're like, "Oh my God, I need to tell my team. It's such an amazing insight." So what do you do? You have to get off your bike, take out your phone, open up the Notes app, write down what you just heard. Maybe save the timestamp, maybe take a screenshot to remember the timestamps to be able to come back to it.

So you do that a couple of times, but then after the third or fourth or fifth time you're like, "Okay, come on, this is too cumbersome. I'll remember it." Yeah. And then you get to the office, and of course, you've forgotten about it. A couple of days later you might remember again, then you try to find it again in the podcast, but of course, you can't because it's all in audio. So you use that skip 30-second button like 500 times, and once you do find it again, you want to share it with your colleagues. So you send them the episode, and of course, they don't listen to it because at the end of the day, it's a two-hour conversation. So these were all of the issues that I experienced.

And long story short, another friend of mine, Ferdinand, who's not with us here today, he and I, we were talking about this. Both our background is in AI, and he was saying like, "Hey, I have the same issues." And given that our background was in AI, so this is before ChatGPT came along, we thought, "Hey, there's a better way of solving that." With all of the advancements that are happening, we should be able to create a more usable and delightful experience there. So that's how I started and maybe, Mikel, you can tell the story how you got into this.

Mikel Corcuera:

Yeah. I met Kevin in that startup, in the startup we worked before Snipd. I came to Snipd in a different way. I was there working as a front-end engineer. I was there for four years, and at some point, I wanted to do something different. We were working with web technologies with Angular. Yeah. I heard about Flutter from our CTO back then, he was a back-end developer. He learned about Flutter, he was excited about it, and I said, "Okay, let's give it a try just to learn something new." And I really started liking it, I really liked the developer experience. I really liked where this is going. I also liked it because it was new for me. I wanted to build an app. After some point with that, I got a little bit bored of the product we were building and I decided to leave.And I said, "Okay, I leave and I figure out what I do." One thing that was clear for me was I wanted to learn Flutter in between jobs just to see whether I would land a job with Flutter or not. And I wanted to find a job where I will build a product for consumers. In the previous startup, it was B2B2C, and even though we were building something for the end user, it was very hard to see that connection.

So we were building something, the bankers would see it, and I have no idea how people were using it, whether people were using it. So that felt for me, it was like not very connected to the product. So I decided to learn Flutter and I knew that Kevin and Ferdi were building something. I had no idea what it was. I said, "Yeah. I'd rather learn Flutter while doing something that makes sense, some cool idea, than just do another to-do app, because it's like the usual learning exercise." So I talked to them, I said, "Okay, I have three months in between jobs. Let's get together. I will help you build the UI," because they really needed help in that area.

They had some prototype that never sees the light of day, so then I started working with them. But basically for me, it was a learning exercise. I said, "Okay, while I find another job." And time passed, I was doing interviews with other companies, and at some point I had two offers, plus I was still excited to work with them.And the three of us sat together in a meeting because I was in Spain back then, and I decided to say no to those offers, and they offered me to join Snipd as a co-founder. It was still not founded, but during [inaudible 00:08:40] the three of us would find the company. And I said, "okay, why not? If I don't do it now, I don't have kids, I don't have family."

So it was why not? I really enjoy what we are doing here. I think the idea was amazing, and the experience of building something from scratch and the idea that that would be used by someone. We still didn't have a prototype that we released, but it was something that I was so passionate about being able to build the app, have it in my hands. And knowing that that would be the thing that the user will use. So I decided, "Okay, let's go with it." That's how I started, yeah, that's how I joined them.

David DeRemer:

That's so cool.

Mikel Corcuera:

That was already four years ago, more or less, right?

Kevin Smith:

Yeah.

David DeRemer:

Four years ago?

Mikel Corcuera:

Yeah, so then we decided to start. And that's when we started really building it, integrating the idea, and finally releasing the first version of the app.

David DeRemer:

That's great. I love the origin stories here because Kevin, you identified a need based on your own personal experience trying to listen to those. I know exactly what you're talking about. There's podcasts I listen to. There's one I really love called 2Bobs. And it's like they have so many insights that it's just like if I go for a walk and listen to that, I'm just basically my head's down in the Notes app the whole time writing notes. And so something like Snipd comes along and you're like, "Oh, this is doing that same thing, and giving me the opportunity to collect those things and mark those insights."

So you building it from that insight and being like, "Hey, I have this need." And from that position of personal desire, and I think so many products have come from that. And then Mikel, on your side, it's like, "Well, okay, I want to build something that actually I want to use, that is something useful for me," even if it wasn't the thing that you originally dreamt up for yourself.

So there's just a really interesting insight there of how these things and teams materialise, which I think is a lot of fun. And I do want to get into the technical details of how you guys have built it because there's some AI stuff. But before going that far, given it was a personal idea and podcasts are pretty popular, one of the things I would imagine would be difficult is to figure out the initial feature set for this.

You have all this AI change, people consume these things in different ways. You have people riding a bike, walking down the street, in a car, sitting on a couch, for different reasons. Some people do it for entertainment, some people do it for learning and personal development. So when you were getting started, how did you really decide what the user really wanted? And maybe over time, has the feature set changed from the idea phase to what it ended up being? How did the actual concept develop over time?

Kevin Smith:

Yeah. This is actually quite interesting, because now looking back when we had these first conversations and we're prototyping first versions, we did not think that the aspect of saving the insight would be the biggest part of it. We thought the big thing is discovery. Because what we saw was if we have users who are saving the best insights in podcasts, there would be 10, 100 times more people who would want to just discover them. So it's almost, in a way, the idea was almost a little bit like a TikTok for podcasts that we then came to be like when talking with one another.

Where a certain section of users would create snips while listening, and another section would just consume these snips or use them as a discovery tool. So when we actually then started to create the first versions that we got into people's hands, we thought the difficult thing will be to get people to create snips. I didn't think that there was so many other people like me, and then everyone would consume them. But once we gave people the prototypes, what we saw, found out was actually exactly the opposite. Is that all of them were creating snips, and they weren't just creating one snip an episode, but 10 snips an episode, and they really loved that.

So this was how it's almost like the feature set didn't really change, but the focus of what was the main thing that we put front and centre? That then changed through building something and putting into people's hands and learning from the feedback.

David DeRemer:

How did you collect that feedback? Did you just talk to your users? Did you have a feedback capture tool? I'm just curious how you uncovered that insight.

Kevin Smith:

Yeah. That has developed quite a bit over the years. So in the very beginning, we didn't have an app live, so we were just on TestFlight. So this was just talking to friends, giving it to friends, asking them to use it. And then once we had a version live, then we always had a big feedback button at the top of the home screen where they could immediately give us feedback. And that was, I think, one of the most important things that we did in the beginning. To really have that front and centre, it actually took up a lot of space, so any designer would've hated it. But that's the way how we collected the feedback and it was just a Google Form behind it. There was no fancy whatever, and that worked quite great.

David DeRemer:

That's awesome, nice. Well, so let's get into the technical side of things because you have an AI story here, and of course, AI is super hot right now. And I think you guys got started with it, I think, before all this became super hyped. Because you've been working on this for four years, and had these ideas from the beginning and the AI was part of the genesis of what you could do here. So maybe walk us through a little bit about some of the technical choices you've made along the way, both in terms of how you decided to build it. How did you prototype this? You mentioned getting some TestFlights out and things. And then maybe how has the technology really driven your approach to the user experience itself in terms of what the product actually does?

Mikel Corcuera:

Yeah, maybe can answer that. I think at the beginning, the most important thing for us was not that much about the technology we were using, but that we wanted to ship something as fast as we could to get feedback. In the beginning, the reason we decided for Flutter, was because I was learning Flutter and it was, "Okay, I will learn Flutter with this." Kevin and Ferdi, they knew Python, so they will do all the debugging in Python. So for us, the main focus was, "Okay. Let's get something out as fast as possible for our friends and family first, then to TestFlight, and then to the app store." And I think in total, it took us less than six months to go all through that process. I still think that the decision of using Flutter was the right one.

At the beginning, it was only me working on the app side, now we are only two, so it's a pretty small team. And the reason we can have both an iOS and an Android app is because we use Flutter. Or we could have used another, I don't know, React Native or something like that, but I do think Flutter has allowed us to build fast and to build an app that looks very nice. I think one thing that people talk a lot about when talking about Flutter, is this developer experience and hot reload. And I think it's not only important for the developer that that's there, so of course, I like working with Flutter because the developer experience is much nicer than maybe Angular. But I think that is reflected also on the product at the end, because I have joy creating the UI.

I will go the extra mile and try to make it much nicer. It will also be faster because of the iterations of the UI. We know how it works. We also don't have a designer. We work all as the designers or me, I work as a designer, but I don't usually do it on Figma. Because Flutter is so fast to iterate on, we can really just start building, do maybe a few prototypes in Figma, then jump directly to code. And because it's so fast to iterate and move the button here, put this colour here wherever you want, I think it allows us to go to the end result much faster. And one thing that is very important for us also is the interactions, like how the user uses the app and how it feels. It's not just how it looks, and I think that's very hard to replicate on Figma.

And with Flutter, you can really have the app in your hands, change a value somewhere, try it again, see how this scrolling feels, see how this animation feels. And I think with other frameworks, that will take you maybe you have to restart the app, go back to the screen you were before, replicate the state, and the whole process takes you much longer. So I think the willingness from the developer to get there is sometimes not there or sometimes the time is not there, so I really think that Flutter allows you to create these polished experiences that is so much harder in other apps. And I think in the way the developer is also, I think, they have more joy using Flutter, at least for me, than using let's say Angular to create these polished experiences.

So I'm still quite happy that we use it. We, of course, have found that some things are not as easy in Flutter. Everything that has to do with native code or native interactions, it's always a step, you have to take another step. You have to integrate it with a plugin, you have to create a plugin yourself. So sometimes it's not as easy to interact with the native side, but all in all, I'm quite happy that we really decided to use it.

David DeRemer:

That's a really interesting use case for startups there too, where if you have engineers who have a good visual eye, there's the traditional designer developer handoff. Or you do everything in Figma, and then you document that and you hand it off to the engineers who implement it. But I think that's an interesting insight in terms of especially if you're trying to do something fast that's new to the world where you're trying to test it. Do that quick prototype in Figma that gives you the direction, and then just get in there and just start doing the last 20% in code itself.

Mikel Corcuera:

Yeah. And I think one thing that it's important of doing it in code, is you have so many different cases. I don't know anyone who has built a new one knows that, "Okay, the designer will test these few fields with a nice case, a small title with a small description." But then you use the app and there is people, I don't know, there are some podcasts that have five lines or title, and it doesn't look nice on Figma. If you put it there and you just use their design, it doesn't look nice. So I think by using real data also while you are designing the app, it also allows you to catch these cases much earlier and try to figure out a solution for those. And I think just feeling it in your hand, it's also a big thing. It can look nice on Figma, but then you use it and it's, "Okay, this doesn't work."

David DeRemer:

Yeah, no, totally. No, that makes total sense. And that's where you're right, the hot reload and even just the ability to iterate quickly and get it on different devices and understand. Even on iOS or Android, does this interaction need to be a little different on Android, because of something about the OS? Or something that you really sometimes can't tell until you put it on a real device and give it a try, and you're right about all those states. One of the hard things is I think really great, creative designers, they want to do the big-picture stuff, they want to build really cool interfaces. They don't necessarily want to tell you all the 37 different states that can happen when you're trying to enter a password on the login form. But those things are really easy to figure out once you're in there trying to like writing a code and figuring out all the different situations you're trying to handle.

Mikel Corcuera:

Yeah, exactly.

David DeRemer:

That's awesome. So it sounds like that front-end choice, which was out of a position of just curiosity and interest on your part, ends up becoming a bit of a strategic advantage for you guys as you get going.

Mikel Corcuera:

Yeah, I would say so. And I think that allows us also to maintain the small team, which is also some advantages. Also, maintain only one code base for both Android and iOS, you don't have to think about when do you release one or the other? So I think it has a lot of advantages.

David DeRemer:

It's funny because you mentioned about that factor, how it allowed you to get on iOS and Android in prototyping early stages so quickly. And I've been doing Flutter so long now, it's been since 2017 that we've pretty much exclusively been writing apps with Flutter. That it's almost I forget that the old way was you had to have two different sets of developers, or you did one and you only did iOS. And then your friends and family who were on Android, you're like, "Well, if we're successful, I'll get around to building something for you."

Mikel Corcuera:

Yeah. That's a good decision if you start, I would say. You can also see as soon as you start monetizing, most of the money comes from iOS, so that would be one strategy. But as soon as you want to then release on Android, what you will have to do to port everything to Android is huge, right?

David DeRemer:

Yeah, massive.

Mikel Corcuera:

Depends on what your app is, you may have to be in both platforms anyway.

David DeRemer:

Yeah. And I think the key is you still get that monetization boost from iOS when you focus on one of these multi-platform or cross-platform tools. And I think the truth is, I think, React Native has gotten a lot better too. Early iterations and approaches of this stuff were just not quite there, they were substandard. And I think a lot of companies that tried them or teams or individual developers got burned by it and felt, "This isn't really quite what I'm looking for." But I think Flutter and React Native have both gotten so good that, I don't know, it's crazy why people would be building fully native at this point. For me, from my perspective, but I'm a little biassed.

Mikel Corcuera:

Yeah, me too. I'm a little biased as well.

David DeRemer:

Let's talk a little bit about the back end here. It sounds like on the front end, you had a technology choice that helped you iterate really quickly and get out there, but let's talk about back end. You mentioned Python, that you guys had experience in Python. How did you go about figuring out what to do? Especially with the AI side of it and things, how did you make some of these tech choices early on?

Mikel Corcuera:

I think for the AI, I will let Kevin explain how he started them.

Kevin Smith:

Yeah. I think in general on the back-end side, the two interesting things in the beginning were what to do with the AI, but also what to do with the data. So maybe that's something if you only care to go a bit more into detail because we started with Firestore and then at some point, migrated everything over to Postgres. But with the AI, so back then, just to give a bit more context, so this was four years ago or something like that. So this was long before ChatGPT or ChatGPT APIs were like a common thing or even available. So the way that you got AI into your app was to have either you built, you trained the model yourself, or you used an open-source model from Hugging Face.

And then you fine-tuned it for your own use case, and then you deployed it on your own servers. And all of basically the entire AI research community, the AI world was running on Python. And that was also what we had experience in before because we were doing that in our jobs before, so that was for us, an obvious choice. And in the meantime, I think Python has just gotten bigger and bigger because the AI community has grown so much, and it's still Python first in a lot of these cases. But what we did there was had basically, as I just mentioned, we had these open-source models from Hugging Face that we used. We fine-tuned them, we deployed them on GPU servers that were running on Google Cloud.

I guess most of the challenges there that we had, they were mainly, I would say, DevOps challenges. Once you had the model working, actually keeping it running, we didn't just have one model. That's also one big difference to these days. Back then you had, for every single task, you had a separate model and you fine-tuned it to do just that. You couldn't just ask some generic question. It wasn't just like, "Hey, give me a summary. Hey, give me a quick overview, give me a title." So we had, for example, an AI model or back then you would call it an NLP model, natural language processing model, that would just create a title for a snip. So the input was the transcript of what the user saved, and the output was a title.

And then we had a 100% completely separate weights model that would create a summary for it. And so for this, we had various of these models and basically on our GPU servers, we were loading them into the GPU memory, then unloading them and loading the other one in. And there were just a lot of issues of some stuff's staying in memory, and at some point you can't load the new models anymore. And we had a lot of issues that we actually never solved. So we had jobs every two days, we would restart the GPU server. The typical things of just like, "Yeah, just get it to run somehow." So these were the challenges in the early days, and now in the meantime, that of course, has changed a lot.

We still have some open-source models that we're running on our servers mainly for where we see that we have cost advantages. But most of our AI processing is now happening via the APIs from ChatGPT, Google, also Perplexity we're also using, but that comes with new challenges.

David DeRemer:

Well, let's dig into this, because I'm sure a lot of people out there, AI is such a hot thing right now. And I think that there's a lot of confusion and a lot of anxiety, and just a lot of uncertainty around how do you even do these tools? Do I need to be a PhD in math and an AI engineer?

What is that even? Do I need to be a data scientist, or is this just hooking up an API like anything else? So I'd love to dig into this with you guys and maybe start by being, it says, "Powered by AI. Snipd is powered by AI. "So maybe when you hear a phrase like that, or in your context when you say it's powered by AI, what does that actually mean to you when you're communicating that?

Kevin Smith:

So this is really a big topic that we have internally, is it AI-powered? Is it AI-native? Is it even something that we should mention at all? And we've gone back and forth. Now, the reason why we call it an AI-powered podcast app or sometimes AI-native podcast app, is because these days, we are in this transition phase where it's still something special that your product has AI, and at least AI baked into the core functionality. And that helps gets people interested in like, "Oh, what are they doing different? This is something that wasn't possible before." So it creates some curiosity. But to be honest, the way that we are looking at it is we see AI as it's basically like the new electricity. So in the future it would just be in everything. And it will be so common that you will not say, the same way today you don't say, "Hey, I have this electricity powered watch."

No, you just have a watch. In the same way in the future, we will not say, "I have an AI-powered podcast app." I'll be like, "No, this is just a podcast app and obviously it has AI baked into it." But if we use these terms, if we do use them internally, we do actually love the way the term AI-native over AI-powered. Because AI-native really means to me that you thought through this from first principles of what is now possible.

Thanks to that, we have this technology. Rather than just looking at, "Ah, this is how we used to do it before. Okay, now we just add a little feature of sprinkle on top." And I think you can see some very famous examples. So there's Cursor, which I assume a lot of your audience is familiar with. That was a case where before you had other, you had a GitHub Copilot thing, which really much more felt like, "Okay, it's just now a bit better of an autocomplete." Because it really rethought the whole process of, "Okay, if we have these powerful tools, how can we integrate them much more natively?" So that's what we try to do with Snipd, like really things from first principles.

David DeRemer:

I like that. So AI-native, AI-powered is that first principles of what can you do with this technology and start there, and then build the product idea. So was AI always a part of the product vision from the beginning then? Because you said you started four years ago, I don't think that this was a super common thing that everybody starting out was like, "We're going to use these tools." Because I think it was daunting building the models and getting into that stuff. When did AI become a core part of the mission where you really made the product this AI-native perspective?

Kevin Smith:

So it was from the very beginning. So this was, it basically all comes back to myself and our other co-founder, Ferdinand, our backgrounds being in AI. And for me, basically Snipd was built on two big, let's say, realisations or beliefs that we have. One is that we see podcasts as one of the largest knowledge libraries in the world. And two, we believed early on that AI would fundamentally change how we can interact with spoken audio. And really, the point that made it clear to me this realisation long before ChatGPT came along, was a paper that was published by Facebook's AI team. Where back in the day, what they did was they used the two main technical innovations that led to huge breakthroughs in text processing with AI. They applied that to speech processing, and it just worked really, really well. And that for me was the moment where I realised, "Wait, everything that's happening in NLP, like this text processing at the time, all of that will happen in speech as well." And if you have both of these worlds, now you can do so much more with spoken audio.So we had that vision from the very beginning, but it wasn't clear from the very beginning what we'd be able to do with it.

David DeRemer:

So that's interesting. So then you're not clear what you're able to do, but then you get in there and you start experimenting with these tools. And at the time you didn't have, when you first got started especially, you didn't have these large language models that are so popular now. How do you go about answering that question, what actually is possible?

How do you go about experimenting with different open-source models and approaches and tools, and then figure out A, what's possible reliably? And then B, which approach or which tool gives you the best outcome? Because one of the challenges here with AI is they're not deterministic, so you get different outputs each time. So how did you go about making these decisions, especially in the early days? Now it's a little bit more obvious like, "Okay, I'm going to use Claude or I'm going to use OpenAI or Gemini." There's some more specific directions, I think, people are more likely to go. What was your insights in terms of how can we even today make better choices with these tools?

Kevin Smith:

Yeah. I think, again, it has changed quite a lot if you look at back then and to today. So back then, in a way now looking back, maybe it was even easier because you had less choice in a way, and it was clear what you had to do with it. So there were a couple of open-source models, but then you had to take that and you had to fine-tune it for your task. And it was just for a single task usually that you did that for, and then you just saw how well that worked. The big benefit that we had, and that I also recommend to anyone working on something today is we didn't aim for perfection. When I now tell you, "Hey, there was a summary for this Snipd, this insight that you just heard."

Today, everyone thinks of this perfect summary because everyone knows how ChatGPT is. Back then our summary, let's be honest, it was actually crap, but it was good enough for the really hardcore person, who really, really, really wanted this, to use it. And the summary, every third word or something would make sense, and you'd be like, "Yeah, yeah, yeah." A couple of keywords triggers, then they talked about this and about that, and then it sort of worked, and we just bet on all of this getting better over time. And the way that we actually looked at it was that we thought we would have to do all of the work, so we did not envision these APIs to just come along, especially not this early.

So we envisioned us having to do the work to make it better and better and better, of course, with again, standing on the giants of the open-source models that at the time, even OpenAI was still open sourcing some models and Facebook was open sourcing a lot of models. But we thought over time we would get bigger, we would get more successful, we would have more data, we would have more people on the team, and with that, we would improve these ones over time.

David DeRemer:

Nice. So that's how you can embrace the hallucinations, just with an innate assumption that it's going to get better?

Kevin Smith:

Yeah, that's how we saw it back then. Now today, I think even the term hallucination back then, it didn't really exist. I think this is actually more a bigger problem today, especially also for us, because we've outgrown the early adopter that forgives everything, the weirdest hallucination. But when it comes to hallucination, I think the underlying thing that you're referring to is it's not deterministic, that you have this randomness in there. And the way that we handle that is, I think that is really something where if you're a programmer, you do have to adjust a bit how to think about coding.

And you have to free yourself away from this deterministic flow, and much more the analogy that I like using is having a bunch of interns work for you. So it's like you have a task here and you hand it off to an intern. The great thing is you don't just have to have one intern, you can have 10 interns, and you can even have interns that judge the output of the other interns. And this is more the analogy that I use to try to handle all of these cases. If you can have as many interns as you like and you want to improve the quality, one way is to exactly split it up, have two people, two interns work on the same thing. They come together, they judge what's good, what's not good.

You have a third one who's maybe the final decision maker and all of this, and these are all ways of improving the quality in handling of these cases. And maybe the final thing that's just important is you have to live with the fact that it will fail sometimes. This is another thing where you have to adapt the way that you think about code, where usually if you've written everything nicely, it shouldn't fail. Or if it fails and there's something, there's a bug and you need to fix it. No, it's just you have to live with a certain percentage depending on how difficult the task is, that that will fail and then fail gracefully.

Also, the end-user experience has to reflect that. And also the user has to, yeah, that's just another thought that just came to mind. One thing that has helped us as well is that we've always been very clear that we are an AI-powered podcast app and that we have AI everywhere. And so the user then also learns, "Okay. If this is written here and no, it's generated by AI, can I trust it or not?" Or if it's missing something, "Okay, probably the AI did a mistake here," and that then also helps.

David DeRemer:

Yeah. Well, I think we're in an era too where people are learning to appreciate that because the code is not deterministic. It's just no different than if a friend of mine listens to our podcast that we're recording, and I was like, "Hey, tell me what you think," and they;d give me a summary. They're going to not get it totally right. Even our memories are not super good at exactly being factual of this stuff. So I think people are getting used to that, but AI is everywhere. So you guys are using AI to actually develop the app too. Is that part of your engineering workflow? Is it full stack for you guys everywhere AI?

Kevin Smith:

Yeah. Mikel, do you want to?

Mikel Corcuera:

Yeah. I think each one of us on four different tasks, we use it differently, but it's certainly something that is in our workflow. I think for me personally, I use it differently depending on the technology I'm using, how familiar I am with it, what kind of tasks have I tried? With Flutter, I know they go from A to Z, and the context is much bigger, so I am there less reliant on AI. Now, for example, if I'm trying to build something new, one good example was how we build a new landing page. We use v0, I don't know if you're familiar with it, it's from Vertex. It's like coding, let's say, tool to build web apps. And the cool thing about that is that, so we are four in the team, so it's two front-end people. We also have Ferdi, who is maybe working on the AI or in the back end, and he started building the website. So the cool thing about v0 and this AI tool was that he was able to grade the main content of the app without having any knowledge on web or design.

Even though then I took over and I had to change a few things here and there, I think it was very helpful for us as team to have him be dependent on, "I want to focus on the content," but of course, you cannot just write the content on a Notion page. You would still have to visualise it to see whether it works or not for a landing page. I think it was very good for us that he was able to work on that independently, create the basic look and feel, create the content, and then handed that work to me because I have the experience on the front-end side to polish it and making it production ready.

David DeRemer:

That's awesome.

Mikel Corcuera:

So that's one of the extreme of how we use these AI tools, and there is something in between. For me, with Flutter, as I said, I usually jump to the chat and say, "Hey, how can I do this? How can I do this other thing?" I think for Flutter it's not as powerful. There is less code around than, for example, let's say React, so you can feel it also in the answers it gives. But we also have a web app, not web app, we have the share page and we have a few web tools, and there I'm less familiar with it. So there I'm much more leaning to Cursor or something that is integrated on the IDE to help me, "Hey, how did you create a component in Angular?" I forgot about it because I didn't work on that for three years, so that's super, super helpful for me.

And there I have, let's say, less expertise on what the process is, so I find them much more helpful there. So for me, it's depending on my knowledge of the kind of task that I have, but definitely we are all using it on developing. I think some of us use-

David DeRemer:

That's a cool framework to think through it actually, because I think a lot of engineers are struggling right now with figuring out where and when and how to apply these tools. Because you get pressure from socially just reading LinkedIn or reading tech blogs and stuff of everyone's using all these tools to be so productive, what should I be doing, me? But it's interesting, because if you know the app super well and you already have that context, and you can go in and be really productive and really quickly produce something, then maybe an AI Copilot is not as useful because you can just yourself get in there and get it done. If it's something new you're trying to add or something you're not an expert at, it's helping you to get things quickly. And rather than hiring a web engineer or a freelancer or somebody coming in to do that, you can get somebody to move it far enough, where then you, as a competent engineer, can get in and get it the rest of the way. And so I think that's a good framework because I think sometimes people are like, "Oh my gosh, do I need to replace my core expertise with this?" And it's like, "No, it's an augmentation that helps you get better superpowers," right?

Mikel Corcuera:

And I think at some point, you need this core expertise also to judge what it's giving you. We give you a lot of things and some things are good, some things are not so good. And some things will work, but some things will work in a way that if you have the expertise on Flutter, I know that this works, but I know the issues it may have. So I think it's still important to have that so you are the judge. You're reviewing what the AI is outputting. Of course, you will test it, but there is much more to code then. I think as Kevin said, it's like an intern. You can give it to an intern, he will give you something that works probably. We create a PR, it works right, but that's why we have PRs.

It's not just that he passed the test, like, "Okay, how did you code it? What are the issues that this may introduce or not?" So you can then guide the AI to build what you want, how you want it. And if you have the expertise, you can get it much better and maybe you need it in less places. I'm still personally learning how to use it. It's not that I have the answers to these things. It's also a new tool for me, and in some places I'm more comfortable using it, and in some others I'm still like, "Yeah, I don't know." I have used it and it didn't work out that well, but I think I'm still also experimenting on different tools and different ways of how to use it.

As you said, I'm also going to dip into LinkedIn, into, I don't know, Hacker News. You get these stories and you are like, "Am I missing out? Is it good? Is it bad?" And it's also a little bit, it gives you a little anxiety, but I think as developers, we're also afraid that, "Hey, are we losing our jobs?"

It's a little bit terrifying, but as you said, it's also an augmentation. I think it's much more positive to look at it that way like, "Hey, I'm a good developer already, or maybe not, but I think I am. But then I can be even better and can be even faster, and I can maybe delegate the things I don't like, or I'm not that good at the AI." And I still use my knowledge to be a better developer than someone else that uses the same tool, right?

David DeRemer:

Totally.

Mikel Corcuera:

Yeah. I think we all still have to figure out what is our workflow? I think also before AI, everyone had a different workflow. Not everyone was programming the same way, and I think it's the same. I think it's important to be open to try it and see how it fits in your workflow.

David DeRemer:

Yeah, I love that. There's so much fear and hype, and anxiety and just chaos out there around this whole change. And it's really as you think about it for us, those of us that have some engineering skill or capability, it's no different than it's ever been in terms of something new comes along and you got to learn it. And the true expertise is being the engineer of understanding how to use your tools effectively to get your outcome. And the tools change and the things that you need to figure out and learn change, and I think everyone's still just figuring this out. There's like when you read LinkedIn, it's full of people who claim themselves to be experts and wizards and masters of this stuff.

And the truth is no one's really been doing this that long. And I always say, "You guys are one of the apps that actually is on my phone that has core AI features." Whenever somebody's like, "Oh my God, are we behind? Do I need to shift my career to AI or something like this?" It's like, "Okay. Think about how many apps you have on your phone where there's an AI feature that is a core element of what you're using right now." And there's just very few still that actually have a lot of like you guys are definitely one of them, and then you have the core ones like ChatGPT or things like that. But we're still so early in this, and that's what I think is really interesting about your team. So one of the things I wanted to ask you about was, there's a couple of nuances here. You guys have AI background.

You approach this from an AI-native approach. You are using actually AI features in your product. So it's not just that you're using AI tools to be more effective in productivity and delivery, but the tool itself is very AI driven. And you're a small team, you're a startup, you're a small, nimble team. And I was curious, what kind of recommendations or insights would you guys have for larger, more established teams based on your experience over the last several years getting this product going? At VGV, we work with a lot of very large enterprise companies that have big teams, complex internal structures, complex existing code bases.

And one of the things we often want to bring to them or that they want for themselves too, is how do I get that more fast, innovative, quick, small, lean team dynamic that you guys are enjoying right now into my company? And I'm curious what kind of advice you would give to those leaders to how to infuse some of the things that have worked for you into their cultures?

Kevin Smith:

Yeah, shall I take this, Mikel?

Mikel Corcuera:

Yeah, take that one.

Kevin Smith:

Look, at the end of the day, I don't think we have the perfect silver bullet here, but I can tell you what I think makes us fast. It's not just because we're a few people. A few people shouldn't make you fast, but what are then actually the characteristics here? And one of the things is that all four of us understand the product deeply. We understand the user. All of us have, just as an example, all of us actually are doing customer support. So each week, it's someone else who's handling that so we have really the direct connection to the user. We are all using the app ourselves, and basically we all have the authority to write and push code. And once you have that, then every single person can act autonomously.

Of course, it's important to have a direction. We need to align and everyone needs to know what is the important thing that we're working on right now? And this is the big project that we're working on, et cetera, but it's often then the small things. Even if we all say, "Okay. We have Project X, this is what we're doing now," but there are so many small, little decisions that everyone has to take. And if all of that has to go through some kind of approval process, then you just get slowed down so quickly. And I believe just looking at a lot of what I hear from colleagues who work at big corporations, this is something where I realise it can never be as fast as if you're just four people. But it seems that there's so many processes in place, especially at older corporations, older companies, that are just actively trying to go in the other direction basically. Like, "Oh my God, no, you can't push code without, I don't know, having five, 10 reviews and it always has to be like this."

Yeah, this is a bit from my side what my experience and thoughts there are. Maybe one additional one is definitely if you work in a small company, especially in a startup, it is the success of each single employee is basically equal to the success of the company. It's just very difficult to decouple that, and in large corporations, that's actually often quite different. The success of a single individual is more about getting the next promotion or being part of this next "cool, big project," or getting a salary raise. And all of these things can very easily be completely decorrelated to the actual success of the company, so I think that helps in a small company to then run in the same direction.

David DeRemer:

Those are great. I think you're totally spot on. It's that empowerment thing and the complexity and the trust, and these big companies build all these systems and it's hard. It gets really complicated. And I think that is ultimately, there's so many management books and all the guests we've had on our podcast here, it always comes back to team dynamic and leadership trust.Does the leadership really trust the team to act and to not be super nitpicky about everything they do, and let them do their things that they want? And communication is the hardest thing, keeping everybody aligned, so I love that. Thank you, guys. This has been really great. I want to wrap us up here.

And one of the things I just wanted to ask as a parting shot is, given that you guys have been in AI-native land for several years, predating its popularity and the broader zeitgeist, what do you think our AI-native future really looks like? Where does this go for Snipd? And where does it go in general for engineers, and for knowledge workers and everything else out there? What do you think?

Kevin Smith:

So I think the most important takeaway for me, is that I believe all of us still underestimate the impact that AI will have and how much it will change things, and that includes myself. Because I think for us, in general as humans, it's so difficult to understand anything that's exponential or goes in the direction of an exponential progress. And that is what we're going through right now with these models.

So I'm actually quite careful always to predict or try to frame myself as knowing what will come. And more try to go back to just remind yourself that you're underestimating it and then that's already a good approximation, but I can give you a couple of things. One thing that very few people are only talking about, I believe, are AI in the real world.

Because right now, most of the very public process, I would say, has been happening in the digital realm. Basically, all of these LLMs and then with the coding, and generates a generation of images and audio, video, but you can see how these humanoid robots are making more and more progress. My wife, she works for a company that does autonomous robots, and it's just clear how this will happen.

And it might be a bit like autonomous driving where we're like always three years away, always three years away, but you can see what's happening with autonomous driving now. I think in the last five months, Waymo has done twice as many rides than in all of the years before, something like that. They have, I don't know, 20% market share in SF for ride hailing.

It's happening slowly but then suddenly all at once. So if I can just say one thing, maybe real-world AI is something that a lot of people are not talking about yet.

David DeRemer:

Very interesting. Mikel, do you have any thoughts?

Mikel Corcuera:

Yeah. To be honest, I also have no idea how it will change. I only know that it will change a lot, and I think it will change a lot for us developers. That's maybe where I'm more worried or excited both at the same time, but I think there it will change a lot. And I agree with Kevin that we really don't know how much it will change.

I think I would say much more than what we think it will, but I'm trying to have a positive attitude in the sense trying to get away from, "If I lose my job, I won't be useful." I want to think that, "Yeah. We will be able to maybe, as developers, build much more, much faster, and still enjoy using these tools." So that's where I have my hopes and views.

David DeRemer:

Anytime we have these major changes, but there's so many examples of technology over the history of mankind just having these radical shifts that change workforce. And honestly, it's a little bit disappointing and disturbing to me that people feel like, "Oh, because of AI, suddenly there's just going to be all this unemployment."

I'm like, "I feel like it's not really giving all of those people a fair shake." It's like you think that something's going to change here, and they're just going to say, "Well, shucks, I lost my job, I'm not going to." People are crafty, we have ingenuity, we figure new things out to do. And realistically, what I've always felt about AI and some of these tools, these code assistants and things like that.

Really, it's the same thing that Flutter did for us. It's like it's giving our developers more productivity, more superpower, more better developer experience. And I think all the tools that people are worried about AI, "Oh, AI is going to come and replace my job." No, it's not. It's just going to make your job better.

And you just have to take it upon yourself to graduate to more interesting things that you can do with your time, and I think that's the exciting part actually.

Kevin Smith:

From our side, if there's any developer listening and is afraid that they will lose their job, I can only say that we try to use AI as much as we can in our coding. And I think we have enough things to code for at least 10 more developers easily. There's always something, we have such a long list of ideas. I think, what's it called, general in paradox or something like that? I forgot the name. I think this is so true. Basically, if a good basically becomes cheaper, then the demand for it actually goes up and it goes up by much more than the "price decrease." And I think software is one of these things where that will happen.

David DeRemer:

That's a great thing to end on. Positive note, I think we have to be optimists, and we have to look at this as the opportunity and the excitement for what's ahead. There's so much doom and gloom, it's unfortunate. We've got to stay focused on this is going to make everything so much better in the long run, and so I thank you guys for coming on here.

Thank you for making Snipd. It's a really awesome tool. Really cool to see that connected from your personal observation and need and your own passions, and then leveraging the latest and greatest tools to make something people enjoy using and makes a difference. So thanks so much for coming on, telling your story.

Kevin Smith:

Yeah, thanks for having us.

Mikel Corcuera:

Yeah, thanks for having us, David.

David DeRemer:

Thank you for joining us on Build to Succeed, a Very Good Ventures podcast. We hope you enjoy exploring the experiences and insights of leaders that have built successful digital products.

Please take a moment to leave us a review, and don't forget to subscribe to get our latest episodes. Thanks again and see you next time.

‍