The Cost of Launching Software Without Human QA | Deepak Shukla

You need really aggressive bug testing almost at a full-time level to test across browsers, across devices.

When you're building cool stuff in a silo, that's cool, but when you are shipping these to actual customers and then something breaks and you can't fix it, like you got a really big problem at that point.

We have four people that are paid full-time just to bug test. That's all they do.

Welcome back to another episode of the Bridge the Gap podcast powered by Revenue Reimagine. Today's guest is Deepak Shukla, who is the founder of Lens Studio where he helps founders grow and go from idea to working SaaS product in 27 days. He's built multiple businesses, scaled agencies, and now focuses on solving one of the biggest problems in SaaS: nothing ships.

This episode's about why development takes too long, how to simplify the product building process, and what it really takes to launch something that people actually use instead of launching shelfware.

Deepak, welcome to the show.

Yeah, happy to be here and excited to get into it. Thank you for the intro.

Of course. That's his walk-up intro from now on.

Awesome, use it. Take advantage of it. He used to be in radio so he can do that part really well.

Deepak, so this is a super interesting episode for me because of all the AI things that are happening out there right now, and I think this evolution of where you guys and what your company is doing is super interesting. So the first topic I kind of want to jump on is: why most SaaS never ships. You work with tons of founders who have great ideas, but what actually stops it from launching? Like, where do you see it getting stuck before it launches?

Yeah, sure. So I think one of the biggest issues is product judgment. Even before AI coding, the easiest thing to do was to either overbuild or not build before you found product-market fit. I think there are a couple of pockets for why founders have problems.

Number one: there's a surprising amount of founders who are not the user of their own product or are not power users of their own product. So then they don't really have as deep a knowledge in mind of the actual tool. That's the first thing.

And the second thing, of course, is that even where they are or have some semblance of usage, there's still not necessarily a wide enough insight into the different types of avatars.

I often think that it's a little bit like, and it still hasn't changed to a degree, what developers used to request before AI coding was: give me a spec of exactly what you want to have built. The whole point of that was really being asked to think deeply about who's going to use it, how they're going to use it, what problems you're going to solve.

What's happened now is that part, which was necessarily laborious, has been compressed because now people prompt something into the LLMs and think, great, that's done all my thinking for me. But there are so many additional layers of discernment that means you end up building something for an LLM, which in the end recycles the first couple of pages of Google and gives you the insight as to what it thinks it should be.

So you end up getting a lot of what I call products that don't really work that well, and that's before you even get into the actual testing and all of the stuff that follows. So this has just been my experience of it so far.

Yeah, it's fascinating. You can AI code applications. I think the front ends are fairly good. It's more the middleware, the middle space, the back end, how you're doing storage, how you're doing persistence, all that kind of stuff that is struggling.

We work with a lot of founders and I think over our careers what we've seen is products get to like 75, 80% and you're with the founders and they're able to really well articulate what the product's supposed to do, how it's supposed to work, what the ultimate goal of it is, and they're very good at convincing people of their vision. Really good founders have this good vision. The challenge becomes: how do you take that vision and sell your first million, two million in ARR, and then take that and articulate it to a sales team that can actually execute and sell on it while building the product to 100%? Where do you see the problem?

100%. If you take Pareto's principle, 80% of the value is derived from 20% of the product. The irony is that 80% often comes lost in the last 10 to 20% of the build because otherwise people build fundamentally generic products. And people don't factor in that the cost of change is significant.

So there needs to be such a demonstrable difference if you're building something. At the basic state that people maintain is that they don't care in general when it comes to doing anything. So unless I'm driven by significant pain because there's a fundamental breakage within the tool that I use, and in that world there are multiple alternatives anyway, there needs to be something that's significantly better. And that comes in that last 10 to 20%.

Now with AI coding, you don't get that from the LLMs, right? Because they cater for the app. Unless you get to such a level of prompting, but even then, a simple example: we were building a task management app and what the LLMs couldn't provide for the user is: okay, great, so now we've got a subtask. Do you want subtasks to become main tasks? Because sometimes people will put a load of tasks into one section and decide that, oh, actually that's an independent part in its own right.

Now, also, if you're bug testing, does each subtask need to have an image attached? Because there are going to be lots of screenshots you apply. And should that open in another tab or should it open in the same tab? And should you rename them? Because then you get 57 screenshots that say IMG45, IMG46. The LLMs aren't going to tell you that.

The other problem with LLMs, and listen, I love a nice AI-coded app. I code some stuff. I'm certainly not at the level that you are, but the problem that I see is when it comes to integrations.

Listen, I have no coding skills whatsoever, right? I could build a cool app that I could certainly hook up to HubSpot or whatever tool I want. I could do that initial hookup and all's great, the fields map, everything's wonderful. We'll just say HubSpot for example. HubSpot changes something with their API. My application now breaks. I'm not a coder. I don't know how to read code. I try to prompt it, but it doesn't fix. That's the biggest problem I see. And when you're building cool stuff in a silo, that's cool, but when you are shipping these to actual customers and then something breaks and you can't fix it, like you've got a really big problem at that point.

Yeah, yeah, yeah. I totally agree. Integration can often break down. A lot of people don't appreciate the world of post-launch stabilization as well as continued integration over time.

And what I'll often find also is that they don't think about it. You need really aggressive bug testing almost at a full-time level to test across browsers, across devices. And people don't necessarily understand at a development level that we will do it to a degree, but you need someone who's going to do this.

People talk about Playwright and Lambda and none of these tools replace human testing when it comes to actually testing. What about iOS? Android? What about iOS on Apple? What about Android on Chrome on Android? What about Internet Explorer versus Opera versus Firefox? You've got to do the same testing. And that's the understanding of the level of testing because you've got your HubSpot example. What if you're using HubSpot in Internet Explorer? Does it change based on the way that they integrate?

Do people use Internet Explorer?

Yeah. Yeah. I'm ironically using an edge case right now for Riverside, which we're recording on. For whatever reason, Riverside does not display my camera on Chrome, and it's not a big enough pain for me to warrant figuring it out. So I go to a different browser. I'm an example of an edge case, right?

You just switch browsers.

Yeah, and I might think, oh, Riverside, you're not fixing it for me. So there are all of these variations that AI coding hasn't solved, really, to be honest with you. And I think that's where I see a lot of frustration comes from some of the founders I speak to because I say, "Hey, there's still a load of boring work that you also need to do within your team or contract us to do, and it's just as exhaustive as the development side." And also understanding that's a separation of almost IQ. Like, you can't expect the person doing the development to also be doing the thinking, to also be doing the testing, to also be doing all of it.

Understand the product judgment because therefore different kinds of mind spaces completely, and where they come in and ask one person to do it. That's where you, of course, get a dilution of everything and say, "Well, you know what? My brain was fried by the time I finished Chrome. I didn't even bother getting to Internet Explorer because who uses Internet Explorer?" You're like, "Buddy, I'm B2B. Everyone in the work environment uses my tool." And you go, "Oh, well, that's another can of worms you've just opened."

So these are some of my experiences so far. I want to shift gears to the 27 days. So you've built an entire model on launching SaaS in 27 days. How the hell is that even possible?

Yeah, sure. So I think the best way to liken it is that with vibe coding and with anything, if you take the premise of having a WordPress template within a platform—whether it's Bolt, Lovable, or Claude Code—you can develop a good, ultimately a framework that you can either remix or clone. Now, there's general things that anyone who wants to vibe code a web-based SaaS app or whether it's mobile fundamentals that everyone would expect: single site, you know, single SSO. You want two-factor authentication. You want CRUD table structure. There might be things that fundamentally apply across the board.

So then if you combine that with understanding there's particular use cases—for example, I wouldn't commit to 27 days if it's a mobile app because I'll say that's outside of what we cater for. I would say when we do 27 days, I cater or commit to that if you're building within a Chrome environment, and I commit to that only with a specific set of APIs that we're familiar with. So LLMs, like AI orchestration, but if you start introducing new APIs, I'll say well, that extends a roadmap and we allow more time subject to API integration because of the stabilization part. I'll say look, integrating it is easy. Getting it to work is quite difficult. Yeah, there's MCP servers and all sorts of things, but you got to get the data mapped properly. You got to make sure it's responding back properly, what format that you want, like the formatting.

Yeah, exactly. So the reality is there's, we spent a lot of time building a foundation. We've understood things that we're better at building within a quick framework and then we apply that model and then we'll say look, when the app is fundamentally self-contained where there's a limited need for AI. I'd also say AI can help build, but having AI integrated is often quite gimmicky. Like, where do you actually need it and how do you need it? Could that be fulfilled, for example, with deterministic logic, which is actually what people use a lot of the time without really needing AI as such?

So there's a lot of kind of caveats that we'll build in, and then given that constraint, we'll be able to build. And what you'll find is that a lot of people, of course, when you take them through the education piece—which we need to do—you'll discover that you don't need half the stuff that you think that you need to achieve the outcome that you're looking for. So part of it is kind of dialing down into ultimately what is buildable within that framework and then saying look, of course, which is the biggest thing now: do you have distribution? And you know, what are we doing to distribute it into the hands of people that can understand whether this is ideal for your customer, or if it's of course a pet project for yourself, then the game's a bit different. But these are some of the principles that I'll look at if that makes sense in respect of how we'll think about what you can build in 27 days and then we'll have our dedicated team of bug testers as well.

So that was one of the things that we began to separate out as I understood that our clients would not—so we have the dev team, we have product judgment, but we have four people that are paid full-time just to bug test. That's all they do all day, to break things, because we tried the automated way. It just didn't work. It just did not work. So that's been a big thing for stabilization because the big letdown moment I experienced—I spent maybe about 300K pre-vibe coding in failed development with partners and contractors, and for the last 10 to 15 years I had this world of experience, and the one recurring theme that stuck in my head was that I was always disappointed.

When a developer would get excited and say hey, I've shipped it, and I'd want that fantastical experience, and then something silly would break because the bug testing hadn't been done appropriately. I was like, I don't want to be me a couple of years ago. So that was what made me think: how can you create that aha experience? And that was where the need to just have dedicated bug testers came in, even if we're a small team.

You said, "I see you've shipped it." And one of the things that we talk about a lot is: when you ship, what is shipping fast versus what is shipping good? What's good enough when you launch a product? Like, what's the balance between ship it now and ship it perfect? Because I do believe there's a fundamental balance.

Yeah, yeah, yeah. No, I agree. I'd say the first thing I believe is that from an aesthetic standpoint, there's this notion that people will accept obviously things that are broken if the core premise is great. I only believe that to be true if you have something that creates an aha experience that's demonstrably different from other tools out there. Otherwise, I do think that people find all manner of reason to be frustrated.

So for me, I'd say look, if you have something that's novel, then you can afford to get away with a lot. If you're going into a space that's saturated, then I think that you need to extend out a little bit. You need to get closer to the conceptual version of perfect. So I think a lot of it, a little bit like the offer—I was asked about what about AI agents for cold calling, and I'd said well, if you're selling something that's commoditized, an AI agent is not going to do it because it's not anything that's really that different. If you're selling something that's truly novel, hey, I'm calling you because I'm going to give you free cinema tickets for the next six months, you plus one, anyone you like. I said, it doesn't matter who's giving me that. If it's an AI agent, I don't mind, because the offer is so damn good.

So I would say that that's kind of how I look at it. I'd say saturated market, sophisticated end user, familiar with tools—the benchmark is higher. Something that's novel and new, the benchmark can be lower because of that. And of course, the underlying thing is that does the core product just work. And again, it also depends upon the model. If you have a self-served SaaS, then there's more development. If it's gated behind a demo and you have a core because the ACVs are quite high, then it's a guided tour type product. Then maybe you can afford to do things a little bit differently. So I do think that changes also depending upon who the audience is. If it's B2B, then the scope changes. If it's like right, we've got a sales process, we get them onto a call, then we show them a demo, so it's all guided, and that's obviously only warranted when your contract values are significant enough to warrant that. But if you're doing direct to customer absent human involvement, then I'd say well, the app needs to kind of speak for itself, which increases the need for sophistication.

Yeah, I love it.

Yeah, it gets a little messy because people want to deploy stuff. I've gotten into this as I've been building some things for us, and you get to a point where things are working but then they stop working or something is broken. And then it's like you're doing other parts of like, you've already moved on to something else, but something else breaks. So from like an individual or as you're building these things out, it's very difficult to focus, I find, on like completing some of these things in the vibe code world. I think having an accountability partner, kind of like what you guys are doing, to make sure that the stuff that is that you don't want to do—like all the bug testing or all of the regression—because like when then you build a new feature or function, like people don't realize you got to go regression test everything that you just built.

Prior to and they don't want to do that. So I do like that.

I agree.

Go ahead. Go good.

No, I was just going to say something that I found to be useful. It took us a little bit of time, but I identified Indian computer science university students are amazing at enjoying regression testing and bug testing. And then we gamify it by giving them rewards based upon whoever gets to 100 bugs found the fastest gets a $50 reward. And then the game of the guys that go in either vibe code, vibe fix, their goal is to get if you get it down to below 50, you get a $50 reward and you just need to flip-flop through the tools. So every day we've got a WhatsApp group. Actually, then there's a Google sheet attached to it, but they're like, "Right, I found six bugs. Right, I found nine bugs. Do you have the screenshot? Do you have the arrows in it?" And that has now been more effective for us than any other environment because I thought I need to hire someone who enjoys this kind of work and who gamifies it. And that's where I found computer science or some kind of engineering type of person. There's things that they miss and there's product judgment that maybe isn't quite there, but for what I call the drudgery aspect of it, fantastic, brilliant. That has helped stabilize stuff more than other people that try and get bored.

I love that. And if I would give the people that are vibe fixing, if they keep it below 50 and they don't let the bug finders get above 100, then I'd give them $200 or something like that.

Amazing. Yeah, cool. Cool. Cool. Cool.

So you talk a little bit about replacing the tool stack, you know, and replacing the paid tool stack with custom-built apps. So what do you believe is driving that shift? And because I have a hypothesis that actually CRM will not really exist. CRMs are just glorified databases that you can stick a vibe-coded application on the front of it and get exactly what you want. But I'm curious your perspective on it.

I think that generally speaking, our goal with building our products initially was to replace tools that we pay for. So simply and to look at what I call infrastructure tools. So infrastructure holds. So calendar booking is never really going to go away. I think, even I mean, of course I could always be wrong, but I'm of the mind that people would always schedule meetings and as much as that can be done with AI to a degree and they can interface with each other at some level, people want to custom manage their bookings to understand based upon what's happening, you know, in real life. So that was the incentive by looking at tools that we pay for that we have been paying for for years now where our spend is upward of, you know, for Calendly I think that we use and then we use PaperForm and then we use like Calendly, PaperForm, and there's a couple of others I forget now like HubSpot and Semrush. I was like, how difficult could it be to vibe code these because we're spending several thousand dollars a month in the end? And I thought, well, the journey is worthy of the reward because that could then replace our tool stack and the product knowledge is already there because we're power users because we've been using them for several years. And the ability to get the ultimate bug testing as well as product judgment is there because of the employees that we have as part of the other companies. So that was kind of the incentive, in terms of even if I fail from a commercial distribution standpoint, I win if I can get it to a place where I can comfortably replace tools. So that kind of was the idea behind it. And I think then that was what became an incentive to say, well, we should then just, you know, put these out for distribution and help others build based upon similar premises.

I think to your point what's interesting, you know, what's—I was once told this by someone else, that you know, in the advent of new markets, so AI agents, vibe coding, we always forget for example about the base of the pyramid. So when I talk about the base of the pyramid, is like, you know, debug, do your research. There's economies in places in the world that are still just getting access to the internet. There's places that still have 4G that are going to become businesses that have a world away. And there's also that world of all of the people that can't be bothered to build stuff and just want to pay people to do stuff. To say maybe I could do it, but I don't want to do it. So I think that, you know, for a certain group of founders or companies which are primarily tech digital native and technology led, they're going to build tools. But for all of the other industries, like if I'm in manufacturing or if I'm in construction or if I'm in real estate or if I'm in hospitality and my job is outdoor and physical, I don't think within that space, if I think of me being that avatar, I'm going to feel that I want to build something internally. Maybe if I'm at a big enough stage, but otherwise for all of the SMBs, there's this world of space where I'll say, "Look, I just want to pay someone else to build exactly what I want." So I think that to your point, custom development is going to be a lot bigger in a way, but I still think there's always going to be a place for all of those types of avatars who don't want to, you know, get to vibe coding or whatever it may become. So I'm quite excited about this era because now for people that are historically not development centric, but it means that those who have a great sense of product judgment, you can build products that you've not previously been able to articulate to others. And even when we speak the same language, there's a whole lot lost in translation. Part of course, like, this is what I thought that you meant. You know, you ask for a donkey, you come out with a giraffe that looks a little bit like a donkey but more like penguin. You're like, "This is kind of what I want, but not really."

Keep your smart ass comment to yourself, Dale.

You know what's coming. You know?

I know what was coming next, and I don't want to hear it.

When you look at like, I want to piggyback on, you know, replacing paid stacks with custom-built apps. Like, where does it make sense to build versus buy?

I think that it makes sense to build when you have an internal infrastructure that's got the bandwidth to build. I think that a lot of people will try and build, but then they'll underestimate the challenge with build. We'll see a lot of flashy statements that come out about saying, "Hey, cool, you can build everything and replace it," but there's that whole world of stuff that we've been discussing. So I'd say that what will happen is that some people will try and build, then they'll discover it's harder than they thought, and then they'll return back to saying, "Let's buy." And probably say, "Look, can I buy it cheaper?" And the logical answer is, of course, yes, because it is easier than it was before.

The place where the hard is, I think, has changed slightly, of course. But I would say that unless you have an internal readiness to really invest time and IQ into it at almost ownership level, then you're not going to build anything that's potent. It will—I think there's levels to which things can work. Let's say that. So if you are looking to replace something, by—if it's deeply embedded within your workflow and the product in and of itself is sophisticated, and the logical thing is that if you're looking to build something, logically it's not incredibly sophisticated because the more sophisticated it is in the end, the tougher it is. Like, you can't just go out and replace something that easily. On the surface it seems like you could, but once you get into the bones of it, you realize, "God, this is still really, really hard. These guys have spent years building tools for this market and they understand the product and all of this type of stuff." And the problem with AI is that it'll always have a thousand and one new ideas for how you can make your tool better. And I think—

Yeah, yeah, yeah. So then everything becomes overengineered and—

So and that—go. Thank you because that's literally—because we have time for one more question before we go rapid fire. That was my very last question. You've said publicly that you're anti-overengineering, and I think what AI is allowing people to do is very much overengineer, right? Make it perfect. How do I make it better? And however you want to prompt that. Like, I've been trying to prompt it to make Dale better for years. It doesn't work.

Where do founders get perfection wrong? Said differently, where do you want perfection and where do you not want to overengineer?

I think that people want perfection based upon the aha moment. So the first 15 seconds is where perfection exists with TikTok, with reels, with videos, and what do you know, it exists with product as well. Oh, I just log in and the primary premise of the tool, it just works.

That part—the first 15 seconds—is important, I think, from a perfection standpoint. And as simple as landing page, I sign in, I do the thing, which is create with AI or generate this or set up my calendar, and within a minute I've got a calendar link that I can use and send out to people, and it just works. That part I think we need to get perfect.

What happens is that people try and overengineer so much around it that you get this bloated interface that you look at. And don't get me wrong, we're talking about dealing with the monkey mind and temptation. And I have the same problem, you know, just because I give the advice doesn't mean that I strictly follow it. I screw up all the time because you get excited. You get dopamine like, "Oh wow, I could build this and this is great." And then you realize, "God damn, you just wasted a week and a half of like building stuff you need to now unbuild." I've done that.

>> I have too. I have too.

>> The monkey mind. Adam's got a very loud monkey.

>> I'm a squirrel. I go all over the place.

>> All right, let's shift gears and let's go into some rapid fire as we wrap this up. I know Dale would like to keep chatting about this for the next hour because he is a dev at heart. And I'm sure he's going to want to pick your brain.

>> Yeah, actually after this I carved out some time to talk to him. Deepak, what's one thing founders overbuild too early?

>> Features, widgets, things that are cool to have, nice to have, away from core product.

>> Harder problem: idea or execution?

>> Execution.

>> What's one SaaS trend that you think is overhyped?

>> SaaS will die is something that I'm hearing and reading about. That's just absolute nonsense, I think.

>> Oh come on. Jason Lemkin is not saying that. He's saying everything's dying. Okay?

>> Cool. Friends here at Bridge the Gap.

>> What separates builders from talkers?

>> Builders are prepared to do the boring work.

>> Yeah.

>> Those who tend to talk less often do and achieve more, in my experience.

>> What's one tool that everyone should replace immediately?

>> Good god. Um, I never got that question. Yeah, you got me there. I mean, for us it's, but it's difficult for us in our team. It's actually powerline dialing software. It's a really painful industry. We have a lot of teams that do outsource calls and we've had loads of problems with it, but that's not a great wide answer. It's specific and niche, and I think the subtext is find very specific problems that you're aware of and try and solve problems for that.

>> Awesome. Last one as we wrap up: dream vacation destination.

>> Oh good god. Um, Tokyo. I've not been. I'd like to go to Japan and check it out. It's one of those on the bucket list.

>> You and me both. You and me both. Deepak, thank you so much for joining the show. Where can people learn more about you, your company? Selfless promotion time.

>> Yeah, sure. So if you want to build with us, then lensstudio.co. And then if you want to learn more about me, then just my website, dpatrick.com. Both those are good.

>> Awesome. Deepak, thanks so much for joining the show.

>> Thank you, sir.

>> Thank you.