--- title: "Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl) | 转录" canonical: https://wavect.io/zh/appearances/inside-the-stack-building-startups/ language: zh description: "Inside the Stack: Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl). 阅读转录." image: "https://wavect.io/img/yt/W2ETt-Sj2hY.jpg?v=686108295596" --- Kevin in the Wild / 嘉宾访谈 # Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl) 主持方 [Oluwole](https://www.youtube.com/channel/UCJMRR0tsXm1OVI7uVInC1pA) 录制语言 英语 31:54 录制发布日期 2026年09月18日 [阅读转录](#transcript) ![原始录制: Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl)](/img/yt/W2ETt-Sj2hY.jpg?v=686108295596) 原始节目 [Inside the Stack](https://www.youtube.com/channel/UCJMRR0tsXm1OVI7uVInC1pA) [原始录制](https://www.youtube.com/watch?v=W2ETt-Sj2hY) 转录 自动字幕经排版便于阅读。人名、词语和时间戳可能有误，尚未标注说话人身份。正文保留录制时的原始语言，以原始录音为准。 ## Intro & Kevin Riedl’s journey to founding Wavect [观看此片段 · 0:00](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=0s) [0:00](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=0s) Like everyone learns at the different pace, right? Some people learn it after the first product and some people don't learn it after 100, right? I see that with very successful uh founders and CEOs that we're working with. They don't understand the basics. I see it really every week. People come with these sky high expectations that are many ways, but I think AI changed the process substantially. It shortened it. Sometimes maybe the idea is great but uh [0:31](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=31s) it's only something [music] usable to yourself uh because for small projects that you only use yourself any money is a lot of money. [music] Welcome to inside the stack everyone. I still remain your host Olu and um I have here with me Kevin Riley who is um a founder the founder of Waveset. Wave set is a software company that has shipped like tons of products. I I feel like they've shipped even more products than what I've built since my um since I [1:12](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=72s) started my tech career. I want to believe that it's over 50 50 products. 60 70 [1:19](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=79s) 75 like is what we publicly claim. Yeah. [1:24](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=84s) 75. Well, honestly, that's that's a lot. And I'm sure there's a whole lot of things that we would get from um Kevin. So what I want you to guys to realize is Kevin is very handsome technically and this conversation would sit right at the intersection of um software engineering, product thinking, client work and um definitely building a company. So for everyone out there using to tech and who's actually thinking of building a [1:48](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=108s) company, Kelvin is here to show his um like to share his experiences to share some of his thoughts and um we'll talk about how his thinking has changed after shipping so many products. will talk about how he approaches um client requests, the trade-offs behind technical decisions, you know, what happens when systems need to scale and um how a lean engineering team can sometimes achieve far more than what you might expect. So, Kevin, nice to have [2:21](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=141s) you on the show. [2:23](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=143s) Thanks for having me. Really a pleasure. And uh thanks for the very nice intro as well. Hey, you're welcome. So, could you tell everyone, our viewers, a little bit about yourself, you know, your journey in tech, what got you started in tech? [2:41](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=161s) Sure. Sure. Uh, I I will try to make it short to not bore anyone, but uh I basically was one of those uh kids that started uh building websites in in I think 11 years, 12 years old. And once that uh got to a certain point, I started uh actually trying to get into systems if you know what I mean. Everything was legal, but I tried to find ways and it was just always a challenge and that that I I just love that. And along that time was when I [3:17](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=197s) joined my first uh identity based uh startup. Um which then got me hooked into building my own startup. Um and then one stone after another like one brick after another was laid and yeah like lots of failures along the way tons of learnings. Um and yeah over the last years uh that there were investments in the startups there were uh yeah another few uh projects that we have started and yeah since 2018 2022 depending on how [3:55](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=235s) you want to frame it. We are basically building software projects for uh international companies mostly US, Dubai, Singapore, you name it like ## Operating an AI-native software agency [观看此片段 · 4:04](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=244s) [4:07](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=247s) basically the the innovation hotspots and uh yeah, here we are. [4:15](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=255s) Yeah, that's nice. All right, so can you just give us a brief about um Weets? What do you do? How what's your process like? [4:25](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=265s) Uh sure, sure. like uh waveact in general is just a hardcore AI native uh software agency basically. So we really bank on on the bet that uh midsized agencies will be in trouble uh through the recent AI changes because you do have enough cost through your employees that you uh have certain pressure but you also don't have the benefits yet of a 50 100 uh person plus agency. So that's kind of our bet. So we said, okay, how can we structure our company [5:01](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=301s) in a way to basically outperform all these at least midsized agencies and uh yeah deliver better and and faster than than most of them as much as we can. Um yeah also about the company we uh have been teaching kids around the world from Thailand to Germany, Austria online about software development and AI for many years now. In summary, we have educated or let's say conquered uh in certain ways uh like crossed ways with [5:38](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=338s) over 10,000 kids. Uh that's at least our internal estimation. So take it with a grain of salt. And yeah from a like if I understand your question correctly the process of building software uh obviously it's a long one and and uh you can go into [6:00](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=360s) Yeah. [6:01](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=361s) Yeah. I get I I I I get that. So I think maybe during the course of um the the the interview or the the session we will definitely get into one or two of how it how it actually works. All right. So um my very first question is you've been involved in building about like let's say give or take 75 products give or take 75 products. What do you understand about building software today that you simply couldn't have understood? You know, maybe like [6:32](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=392s) after you've built your first project, your first two products, your first three products, you know, it's a significant milestone. 75. Building five products is not the same as building 20 products. Building 20 products is not ## The #1 lesson from 75+ products: What not to build [观看此片段 · 6:45](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=405s) [6:46](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=406s) the same as building 50 products. Building 50 products is not the same as building 75 products. There's a lot of learning along the way. So can you just share with us some of those nuggets of knowledge? What were those things that you did not understand then but that you understood but that you understand now? [7:03](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=423s) Sure. Uh that that's a great question. Um the main thing I would say is like everyone learns at the different pace right some people learn it after the first pro uh product and some people don't learn it after 100 right I see that with very successful uh founders and CEOs that we're working with they don't understand the basics and like often times not all of them obviously and the main issue is not how to build but what not to build and how to make [7:33](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=453s) sure you build the right like the 100 year old story, sorry I'm exaggerating here about uh product market fit. So um making sure you build something people actually want and how you get there, right? So [7:52](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=472s) obviously things have changed with AI a little bit because it was it is easier now to get something you can demo and and uh use as some kind of an MVP which is awesome and great. Um but the core principle of hey make sure you don't waste time, tokens, money, resources on the perfect dream product as many people try to build uh still holds up cuz I see it really every week. People come with these skyhigh expectations. uh the product should do everything [8:29](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=509s) before they even on the market even uh sold the product for a single dollar anything like that and that's why most software products actually fail in my opinion and that's definitely the core learning I made that countless of times myself I still sometimes tend to do it myself because it's just so appealing so so cool to think okay I'm building that cuz I think it's cool. I think it makes sense. But that doesn't mean others think so too and think so [9:04](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=544s) enough to pay for it. [9:06](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=546s) Yeah. I think you've answered my next question like so beautifully because my next question was actually about um was there a time when you say you stopped thinking about how do we build this and then you know just started asking like should we even build this? So I think you've you've answered that perfectly. So most of us especially those of us who are not in the business side of course I'm a little bit in the business side I won't say I'm not in the [9:32](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=572s) business side but for when I was starting up I think it was always about how to build what are the bells and the and the whistles I have not actually sat down to ask myself like should I actually build this and I think that is one major question that anyone who is building anything most of the time if it's not for your portfolio as long as you want to build it for other people to make use of you need to ask yourself ## Translating client ideas into code and managing feature requests [观看此片段 · 9:54](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=594s) [9:55](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=595s) like should I should I just build this? Yeah, that's that's a wonderful that's wonderful knowledge. Thanks. Thanks, Kevin. All right, so um another question is mostly about like clients um interaction. When a client comes to you with an idea, you know, most clients don't come to you with their idea fully formed. They come with they come with like should I say like a framework or something know or a feature request like how do you get from [10:24](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=624s) what they are asking for to the actual problem that they have like what is the process [10:29](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=629s) that that's an awesome question because it basically summarizes the difficulty in building individual software. It's it's rarely about uh okay how do I build this from a technical standpoint. Of course if if you build Netflix scale or whatever then that is a huge challenge. Um but in the beginning that's rarely the issue. So it's usually about hey how do I translate what the customer has in his or her head into code. And the [11:03](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=663s) beautiful thing with AI now is they are doing that already by VIP coding stuff and often times or most of the times it's some throwaway prototype. But it helps you get a sense of what they want cuz they prompted and iterated and got their ideas during that process and added that or removed stuff and so on. And that's usually something that otherwise would have happened. and still happens obviously during the discovery process [11:37](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=697s) where you get to a a specification or where you get to MVP where they say okay that's that's good enough to to get out there in a first version and then to iterate upon so that's there are many ways but I think AI changed the process substantially it shortened it um because people are now able to express themselves in a visual manner which they otherwise try to get down to some sentences or paragraphs or during course [12:11](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=731s) meetings and most people struggle with that almost everyone I would say because it's difficult to describe an image right and then draw it without seeing the image that's kind of the difficulty [12:25](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=745s) right thank you um that's that's a nice u response and um honestly I'm We've not even been like how many minutes now and um I've gotten a couple of things like in my own on my own part I've gotten a lot of things and I'm sure our viewers also would have gotten one or two um wisdom from from you. So I appreciate you once again. I know we've not gotten anywhere but I I would want to appreciate you a whole a whole ton. [snorts] All right. So, have you ever [12:58](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=778s) had to tell a client like, "I understand what you're trying to build. I understand your ideas, but I don't think you should build this now." you know um [snorts] let's let me let me give an example for for example maybe like a store who currently should I say store maybe like a client who sells clothes who is who is more or less like um should I say like an online vendor or something who a client what she just what he or she just need is [13:33](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=813s) maybe um what is what is it called maybe like um should I say Google, a Google address, a phone number or something, you know, or maybe just like um basic websites [13:49](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=829s) just to tell the person like just to tell people or clients like, "Hey, this is what I do. Contact me on this phone number to actually, you know, get what I want." But this person wants something like um an Amazon website, like a a marketplace. Have you ever had instances where you've had to tell someone that like I don't think you should build this yet? I think you need to build your market out first. [14:13](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=853s) I do that literally multiple times a week. Um like the reasons are different uh per project and person cuz every circumstance is different. Sometimes it's what you mentioned. Okay. Uh are you sure you want to build this because computing uh competing with uh Amazon for example directly might be incredibly hard and nearly impossible. Why not pick a niche and grow from there? Or as you said, maybe let's start with an audience [14:44](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=884s) first or let's let's try to get some kind of a weight list or or something like that. Absolutely makes sense. Or sometimes maybe the idea is great, but uh it's only something usable to yourself. I had that yesterday. Hey, I want to build this. Um I actually just need it for myself. Okay, cool. Awesome. Um are you sure you want to spend uh money, like a lot of money on building this? Uh because for small projects that you only use yourself, any money is a [15:20](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=920s) lot of money. Yeah. [15:21](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=921s) Um, so there are many different reasons why you shouldn't build stuff and there are very little reasons why you should build stuff. But the main challenge is to not get discouraged by that and automatically say, okay, almost nothing makes sense because [15:43](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=943s) if you try to pull everything apart, everything is a no. [15:48](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=948s) Right? So, so it's about okay, what risk I'm willing to take for what reward, what's the outcome and how can I reduce that risk that that's all that any business is or building software reduce the risk enough to increase the certainty to a point and then try to act in a way to to get there as cheaply and fast as possible. And yeah, there are tons of ways, right? And the better you are in that, the more successful you become and it's a [16:24](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=984s) learning process, but I'm not chef bas either, so I have tons to learn too. Um, so it's Yeah, [16:33](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=993s) thank thanks so much. All right. So, um after building 75 products or more, what what are those warning signs that you would see that would make you think that hey, it there's a probability that this project might struggle later on maybe ## Handling scope creep and changing client requirements [观看此片段 · 16:50](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1010s) [16:50](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1010s) like um should I say client struggle or something you know [16:55](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1015s) struggle in what regard? Now when I say project struggle um let me maybe like you know we have some clients who are not satisfied. [17:05](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1025s) Mhm. [17:06](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1026s) We we would you know we would have sat down discuss the product requirements. Hey this is what the MVP needs. Then maybe a couple of weeks later we halfway through the project then he or she calls back and tells you hey I was discussing with my mother-in-law and I and we feel like this feature might actually might be a a good fit. So, you know, those things change, they change the face of the product. [17:34](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1054s) Mhm. [17:34](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1054s) They might tell you that, hey, [laughter] you know, we could it could just be like a client who who is not, should I say, really satisfied. You might use um for the project, you might let's let me just take it maybe like blue color and then tomorrow he says, "Hey, I want this to be yellow." And then later on he changes his mind like this yellow color does not look doesn't look fine to me. I want it to be orange. You know [18:02](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1082s) things little little things that might be frustrating. [18:05](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1085s) It's a fantastic question. [18:08](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1088s) Um there there are two facets to it I would say. on one hand uh always consider yourself an advisor I would say because uh in the client uh provider relationship you're trying to satisfy the customer right of course that involves to make them successful but if they want a terrible color or if they want a feature that in your eyes is absolutely nonsense and you told them, hey, okay, I would try to validate that further or are you [18:47](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1127s) sure you want to build it? In my opinion, it doesn't make sense and they still want it and they pay for it, it it's their beer, right? They uh pay for it and they want to take the risk because maybe I'm wrong, right? I can just advise them with my own experience. [19:05](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1145s) That's that part. As long as they're fully informed and know the risks, that's fine. Um because otherwise I would create that negative tension of telling them what not to do and they want to hey but I want that and I like that and then then there's this kind of competition and you don't want that, right? They're the wouldn't say king because that's also not true, but they're your partner and it should be on eye level. just tell them how you think, [19:35](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1175s) what you think and uh if they want it anyway, give it to them. Um the second one is because you said weeks later, and that's the more challenging part is the scope itself. You agreed on a certain uh project scope. You said, "Okay, I'm charging you X for that." Yeah. [19:58](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1198s) And then weeks later they change their opinion and and want to do something else. The the main mistake or there are basically two ways to to solve that is uh you either work with uh retainers or on an hourly basis which has a lot of disadvantages as you can imagine but at least you're flexible and the customer can change their mind how often they want because they have to pay for it. That's fine. If you have a fixed price, [20:27](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1227s) it's super important to be super clear in the offer. Don't assume anything. Everything that is listed here is included and everything that is not listed here is explicitly excluded. And if you make that really clear, you will see that uh customers tend to iterate and discuss the offer a lot, which is annoying, but it's less annoying than changing the scope layer and they're pissed and you're pissed. And so that that's the best solution for that. [21:01](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1261s) All right. So, um now let's get into into the technical parts. Um can you take us like through a system or a product that you've built where um performance and scalability were important in the beginning like what problem were you solving and what made it technically challenging? [21:23](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1283s) I mean uh scalability is inherently ## Designing scalable systems and real-world fintech challenges [观看此片段 · 21:24](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1284s) [21:25](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1285s) challenging always uh because you have to account for concurrent operations. Uh although people overestimate how much concurrent usage they actually will have, right? We had clients that said, "Hey, we need to make sure this thing can handle a,000 uh users concurrently at the same time, but then in the end they had maybe a thousand users per month, right? Which is a very different thing. So uh [21:58](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1318s) and that obviously makes a huge difference in how you architect and build something from a technical standpoint itself. Uh this project specifically is a great example cuz it even was a fintech product which means it kind of was uh e-commerce checkout and and people had to uh be able to pay uh through different means of payment which included uh crypto payments which included fiat payments and so on. And we also had to include different payment [22:32](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1352s) providers. So you had to deal with a lot of external factors. These things had to be very available like the third parties tool cuz they have their own limits as well. And you obviously also have to autoscale your thing too because in this case it was a drop based marketing which means uh demand searches and then it falls off and just having a really high uh like a lot of containers running a lot of uh resources in your cloud [23:05](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1385s) running wastes a lot of money. you have to scale down and you have to scale up on time and that that's a main challenge to make sure hey no matter how the usage grows we can handle that the load the concurrent load especially up to a certain point and you do that obviously with of course with um benchmarking like actually testing that making sure okay how does the cloud behaved how does uh your application behave uh does it get low [23:37](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1417s) and all these things and uh is like what happens if if something moneywise like on the transaction side is happening, how do you handle that? How is it then on the support side like when something goes wrong? Where can users go to and how is that resolved both business and technical? Um so there are tons of things uh and the higher the scale you go the exponentially difficult this gets. So um that that's why I urge founders to be [24:13](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1453s) humble here often times say hey are you sure you will have this usage right from the start do you really want to optimize for that because it will cost and and take a lot of more time right so it's um but yeah there are tons of difficulties with that the tools change the the process change uh everything changes [24:35](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1475s) now Um [snorts] when you're designing when you designed that particular system did you like did you decide to scale from first from day one or you or when there was demand that was when you built in um scaling? [24:52](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1492s) Uh are you talking about myself or customers or [24:56](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1496s) No, you know we you used um the um the fintech product as an example. [25:01](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1501s) Mhm. So I was asking like okay number one was it a new product or it already had users that's one. Then two when you built it did you like factor in the scaling [clears throat] at the get go or it was later when there was demand for it? Like in that specific product there was a marketing agency involved and they obviously prided themselves with saying okay we are able to generate that demand. Um and that did generate some [25:34](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1534s) demand like uh in summary we have raised or the client has raised over a million bucks something like that. Um, but yeah, it it's it wasn't like it still was I think like just 40% of what they aimed for. So, they didn't achieve their goal. Um, but yeah, uh, in that case, it basically was, okay, uh, let let's get this right and scalable from the get- go, which makes sense. It's just the scale of how scalable does it need to be [26:10](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1570s) from the from the start was the wrong decision. But that that's more reasoned because Yeah. [26:19](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1579s) stakeholders. [26:21](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1581s) Yeah. So have you have you ever had any system or any project where your initial ## Dealing with wrong technical assumptions and heavy server load [观看此片段 · 26:25](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1585s) [26:26](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1586s) assumptions about the performance and [snorts] um scale actually was wrong? be that was so honest [laughter] [26:39](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1599s) and I I I would believe uh that's also the right way of doing it. Uh that that's why uh we have fallen back to to agile development. Now it's maybe more spectrum in development with AI, I don't know, or loop based engineering, but uh it's you always make assumptions and the assumptions you make and I I really love Jeff Bezos here as well. It that that's a technical topic, but you can still apply it in some way. Is it a [27:14](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1634s) twodoor decision or a one door decision? A one door decision is you go through, you can't go back without meaningful costs. A twodoor decision is or two-way decision is you can go through and you can go back without incurring a lot of cost and resources. So, and I think that like if you're in university, you will immediately learn, okay, everything around a database is usually a oneway uh decision. Um, and it tends to be true to a certain extent and [27:51](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1671s) other things are two-way decisions often times. So it's really I think all about that and most assumptions are just wrong and being okay with that and being clear with customers or people you engage with. Hey, it's totally normal that we have to change things uh to get to something that actually works and people want and yeah if that answers your question. [28:21](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1701s) Yeah, it does. It does. It does actually. It does. um as um both an engineer and as as an entrepreneur, there are times when your assumptions might be wrong from the get go. You might scale for a,000 users and then you have 2,000 users. Now, you can scale for a,000 users and just get like 500 users. So, it's it's correct. All right. [28:44](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1724s) Look at the big ones. GitHub, how many uh like how often have they been down this year? Right. That's a huge worldwide enterprise product and they still struggle with that. [28:58](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1738s) They didn't expect that amount of usage, [29:02](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1742s) right? [29:04](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1744s) It it will always stay that way being okay with that. [29:07](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1747s) Honestly, there was I think we've had um AWS outages about twice or thrice this year. AWS also also had a couple of outages. So even the big ones fail sometimes. Absolutely. Yeah. [29:24](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1764s) Yeah. All right. So, um when a system starts struggling um under load, when start struggling under load, now this is more of your engineering side, not the entrepreneurial side. Now, what do you look at first? Do you look at the database first? Do you look at the infrastructure first? Do you look at the architecture, the application code or somewhere else? [29:48](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1788s) Depends on the maturity of the application. uh the more mature the more uh let's say alerts analytics and so on you hopefully have which means you you know okay what is wrong and what might not be wrong you also hopefully do have a CI/CD pipeline that catches a lot of things like software tests and so on um if something breaks usually you you start with okay is every component of the infrastructure up or down? Yeah. So [30:22](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1822s) like visibly down and then you like as most people you basically just start digging into it like which component possibly is it then you look at the logs and then you hopefully are able to fix it quickly. Um but yeah obviously the more mature the product the way different things look like but that's in its essence as always from the MVP to enterprise how it will always look like when you really break it down. Someone looks where the issue might be. You nail [30:59](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1859s) it down. you fix it as quickly as possible while staying true to your process and then uh hopefully everything goes up again. [31:10](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1870s) Thank you. [31:12](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1872s) Okay guys, thank you so much for staying to the end of this session. Thanks Kevin for your time. Thanks Kevin for staying till the end of this um session. Yeah, so we've come to the end of the session. I really appreciate you all. I hope you guys have gotten one or two nuggets of wisdom from our guest Kevin. Please don't forget to like, share, and if you've not yet subscribed, please do so now. Subscribe and I still remain your [31:37](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1897s) host and I will catch you in the next episode. See you. Bye. [31:52](https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1912s) [music] ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/#webpage", "@type": "WebPage", "dateModified": "2026-11-05", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-11-05", "url": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/" } ] } ``` ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/#webpage", "@type": "WebPage", "dateModified": "2026-11-05", "datePublished": "2026-11-05", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "mainEntity": { "@id": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/#video" }, "name": "Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl)", "url": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/" }, { "@id": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/#video", "@type": "VideoObject", "contributor": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, "description": "Inside the Stack: Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl)", "duration": "PT31M54S", "embedUrl": "https://www.youtube-nocookie.com/embed/W2ETt-Sj2hY", "hasPart": [ { "@type": "Clip", "endOffset": 244, "name": "Intro & Kevin Riedl’s journey to founding Wavect", "startOffset": 0, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=0" }, { "@type": "Clip", "endOffset": 405, "name": "Operating an AI-native software agency", "startOffset": 244, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=244" }, { "@type": "Clip", "endOffset": 594, "name": "The #1 lesson from 75+ products: What not to build", "startOffset": 405, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=405" }, { "@type": "Clip", "endOffset": 1010, "name": "Translating client ideas into code and managing feature requests", "startOffset": 594, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=594" }, { "@type": "Clip", "endOffset": 1284, "name": "Handling scope creep and changing client requirements", "startOffset": 1010, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1010" }, { "@type": "Clip", "endOffset": 1585, "name": "Designing scalable systems and real-world fintech challenges", "startOffset": 1284, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1284" }, { "@type": "Clip", "endOffset": 1914, "name": "Dealing with wrong technical assumptions and heavy server load", "startOffset": 1585, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY&t=1585" } ], "inLanguage": "en", "name": "Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl)", "publisher": { "@type": "Organization", "name": "Inside the Stack", "url": "https://www.youtube.com/channel/UCJMRR0tsXm1OVI7uVInC1pA" }, "thumbnailUrl": "https://wavect.io/img/yt/W2ETt-Sj2hY.jpg?v=686108295596", "transcript": "Like everyone learns at the different pace, right? Some people learn it after the first product and some people don't learn it after 100, right? I see that with very successful uh founders and CEOs that we're working with. They don't understand the basics. I see it really every week. People come with these sky high expectations that are many ways, but I think AI changed the process substantially. It shortened it. Sometimes maybe the idea is great but uh\nit's only something [music] usable to yourself uh because for small projects that you only use yourself any money is a lot of money. [music] Welcome to inside the stack everyone. I still remain your host Olu and um I have here with me Kevin Riley who is um a founder the founder of Waveset. Wave set is a software company that has shipped like tons of products. I I feel like they've shipped even more products than what I've built since my um since I\nstarted my tech career. I want to believe that it's over 50 50 products. 60 70\n75 like is what we publicly claim. Yeah.\n75. Well, honestly, that's that's a lot. And I'm sure there's a whole lot of things that we would get from um Kevin. So what I want you to guys to realize is Kevin is very handsome technically and this conversation would sit right at the intersection of um software engineering, product thinking, client work and um definitely building a company. So for everyone out there using to tech and who's actually thinking of building a\ncompany, Kelvin is here to show his um like to share his experiences to share some of his thoughts and um we'll talk about how his thinking has changed after shipping so many products. will talk about how he approaches um client requests, the trade-offs behind technical decisions, you know, what happens when systems need to scale and um how a lean engineering team can sometimes achieve far more than what you might expect. So, Kevin, nice to have\nyou on the show.\nThanks for having me. Really a pleasure. And uh thanks for the very nice intro as well. Hey, you're welcome. So, could you tell everyone, our viewers, a little bit about yourself, you know, your journey in tech, what got you started in tech?\nSure. Sure. Uh, I I will try to make it short to not bore anyone, but uh I basically was one of those uh kids that started uh building websites in in I think 11 years, 12 years old. And once that uh got to a certain point, I started uh actually trying to get into systems if you know what I mean. Everything was legal, but I tried to find ways and it was just always a challenge and that that I I just love that. And along that time was when I\njoined my first uh identity based uh startup. Um which then got me hooked into building my own startup. Um and then one stone after another like one brick after another was laid and yeah like lots of failures along the way tons of learnings. Um and yeah over the last years uh that there were investments in the startups there were uh yeah another few uh projects that we have started and yeah since 2018 2022 depending on how\nyou want to frame it. We are basically building software projects for uh international companies mostly US, Dubai, Singapore, you name it like\nbasically the the innovation hotspots and uh yeah, here we are.\nYeah, that's nice. All right, so can you just give us a brief about um Weets? What do you do? How what's your process like?\nUh sure, sure. like uh waveact in general is just a hardcore AI native uh software agency basically. So we really bank on on the bet that uh midsized agencies will be in trouble uh through the recent AI changes because you do have enough cost through your employees that you uh have certain pressure but you also don't have the benefits yet of a 50 100 uh person plus agency. So that's kind of our bet. So we said, okay, how can we structure our company\nin a way to basically outperform all these at least midsized agencies and uh yeah deliver better and and faster than than most of them as much as we can. Um yeah also about the company we uh have been teaching kids around the world from Thailand to Germany, Austria online about software development and AI for many years now. In summary, we have educated or let's say conquered uh in certain ways uh like crossed ways with\nover 10,000 kids. Uh that's at least our internal estimation. So take it with a grain of salt. And yeah from a like if I understand your question correctly the process of building software uh obviously it's a long one and and uh you can go into\nYeah.\nYeah. I get I I I I get that. So I think maybe during the course of um the the the interview or the the session we will definitely get into one or two of how it how it actually works. All right. So um my very first question is you've been involved in building about like let's say give or take 75 products give or take 75 products. What do you understand about building software today that you simply couldn't have understood? You know, maybe like\nafter you've built your first project, your first two products, your first three products, you know, it's a significant milestone. 75. Building five products is not the same as building 20 products. Building 20 products is not\nthe same as building 50 products. Building 50 products is not the same as building 75 products. There's a lot of learning along the way. So can you just share with us some of those nuggets of knowledge? What were those things that you did not understand then but that you understood but that you understand now?\nSure. Uh that that's a great question. Um the main thing I would say is like everyone learns at the different pace right some people learn it after the first pro uh product and some people don't learn it after 100 right I see that with very successful uh founders and CEOs that we're working with they don't understand the basics and like often times not all of them obviously and the main issue is not how to build but what not to build and how to make\nsure you build the right like the 100 year old story, sorry I'm exaggerating here about uh product market fit. So um making sure you build something people actually want and how you get there, right? So\nobviously things have changed with AI a little bit because it was it is easier now to get something you can demo and and uh use as some kind of an MVP which is awesome and great. Um but the core principle of hey make sure you don't waste time, tokens, money, resources on the perfect dream product as many people try to build uh still holds up cuz I see it really every week. People come with these skyhigh expectations. uh the product should do everything\nbefore they even on the market even uh sold the product for a single dollar anything like that and that's why most software products actually fail in my opinion and that's definitely the core learning I made that countless of times myself I still sometimes tend to do it myself because it's just so appealing so so cool to think okay I'm building that cuz I think it's cool. I think it makes sense. But that doesn't mean others think so too and think so\nenough to pay for it.\nYeah. I think you've answered my next question like so beautifully because my next question was actually about um was there a time when you say you stopped thinking about how do we build this and then you know just started asking like should we even build this? So I think you've you've answered that perfectly. So most of us especially those of us who are not in the business side of course I'm a little bit in the business side I won't say I'm not in the\nbusiness side but for when I was starting up I think it was always about how to build what are the bells and the and the whistles I have not actually sat down to ask myself like should I actually build this and I think that is one major question that anyone who is building anything most of the time if it's not for your portfolio as long as you want to build it for other people to make use of you need to ask yourself\nlike should I should I just build this? Yeah, that's that's a wonderful that's wonderful knowledge. Thanks. Thanks, Kevin. All right, so um another question is mostly about like clients um interaction. When a client comes to you with an idea, you know, most clients don't come to you with their idea fully formed. They come with they come with like should I say like a framework or something know or a feature request like how do you get from\nwhat they are asking for to the actual problem that they have like what is the process\nthat that's an awesome question because it basically summarizes the difficulty in building individual software. It's it's rarely about uh okay how do I build this from a technical standpoint. Of course if if you build Netflix scale or whatever then that is a huge challenge. Um but in the beginning that's rarely the issue. So it's usually about hey how do I translate what the customer has in his or her head into code. And the\nbeautiful thing with AI now is they are doing that already by VIP coding stuff and often times or most of the times it's some throwaway prototype. But it helps you get a sense of what they want cuz they prompted and iterated and got their ideas during that process and added that or removed stuff and so on. And that's usually something that otherwise would have happened. and still happens obviously during the discovery process\nwhere you get to a a specification or where you get to MVP where they say okay that's that's good enough to to get out there in a first version and then to iterate upon so that's there are many ways but I think AI changed the process substantially it shortened it um because people are now able to express themselves in a visual manner which they otherwise try to get down to some sentences or paragraphs or during course\nmeetings and most people struggle with that almost everyone I would say because it's difficult to describe an image right and then draw it without seeing the image that's kind of the difficulty\nright thank you um that's that's a nice u", "uploadDate": "2026-09-18T00:00:00+00:00", "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/appearances/", "name": "Kevin in the Wild", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/", "name": "Inside the Stack", "position": 3 } ] }, { "@id": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/#episode", "@type": "PodcastEpisode", "associatedMedia": { "@id": "https://wavect.io/zh/appearances/inside-the-stack-building-startups/#video" }, "datePublished": "2026-09-18", "inLanguage": "en", "name": "Building 75+ Startups: Why Most Software Fails (w/ Kevin Riedl)", "partOfSeries": { "@type": "PodcastSeries", "name": "Inside the Stack", "url": "https://www.youtube.com/channel/UCJMRR0tsXm1OVI7uVInC1pA" }, "publisher": { "@type": "Organization", "name": "Inside the Stack", "url": "https://www.youtube.com/channel/UCJMRR0tsXm1OVI7uVInC1pA" }, "url": "https://www.youtube.com/watch?v=W2ETt-Sj2hY" } ] } ```