# The Cost of Launching Software Without Human QA | Deepak Shukla

**Guest:** Deepak Shukla

_Published 2026-05-27_

[Watch on YouTube](https://www.youtube.com/watch?v=3UA6U1J2-iY)

## Summary

In an era dominated by AI workflows and rapid development cycles, relying solely on automated bug testing is a critical mistake that can quietly ruin your product launch. Deepak Shukla, founder of LemStudio, reveals why the convenience of automated tools cannot replace the nuanced perspective of human quality assurance. He emphasizes a golden rule for all software development: the person writing the code should never be the person responsible for testing it.

Beyond the necessity of human QA, Shukla introduces a streamlined framework for taking a fully functional SaaS application from concept to market in just 27 days. He breaks down the rising trend of "vibe coding" and explains how companies can strategically build custom applications to replace their most expensive, bloated software subscriptions. This approach not only cuts costs but ensures tools are tailor-made for specific organizational needs.

The episode also dives deep into the psychology of product development, warning founders against the dangerous trap of over-engineering features before establishing true product-market fit. By incorporating a dedicated team of human bug testers and avoiding siloed development, companies can stop timelines from dragging, eliminate post-launch user complaints, and confidently ship reliable software.

## Discussed in this episode

- Automated testing tools inherently lack the contextual understanding required to fully replace human quality assurance.
- Developers possess blind spots regarding their own logic, which is why code creators should never be the sole testers.
- A structured, focused framework can successfully take a SaaS application from initial idea to public launch in exactly 27 days.
- Building products in a silo without continuous feedback leads to disconnected features and wasted engineering resources.
- Custom "vibe-coded" applications can be strategically built to replace expensive and heavily bloated software subscriptions.
- Founders often fall into the psychological trap of over-engineering product features before validating true product-market fit.
- A dedicated team of human bug testers is the ultimate secret to preventing widespread user complaints post-launch.
- Relying too heavily on AI development tools without human oversight extends launch timelines rather than shortening them.

## Episode highlights

- **0:00** — The hidden cost of automated bug testing
- **4:15** — Why developers cannot test their own code
- **9:30** — Breaking down the 27-day SaaS launch framework
- **14:45** — The rise and practical reality of vibe coding
- **19:20** — Replacing expensive SaaS subscriptions with custom apps
- **24:10** — The danger of building products in a silo
- **31:05** — Avoiding the psychological trap of over-engineering
- **38:50** — Integrating a dedicated human QA team effectively

## Key takeaways

- Human QA catches contextual nuances that automated testing misses completely.
- Never allow the developer who wrote the code to test it.
- You can successfully launch a functional SaaS app in 27 days.
- Replace bloated software subscriptions with your own custom vibe-coded applications.
- Validate product-market fit before over-engineering complex, unnecessary product features.

## Transcript

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 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.

But 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 none other than 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 SAS product and get this 27 days. He's built multiple businesses, scaled agencies, and now focuses on solving one of the biggest problems in SAS. Nothing friaking ships. I'm trying to watch my language. 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. Deepac, welcome to the show.

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

Yeah, of course.

It's his walk up intro from now on. Awesome.

Listen, use it. Take advantage of it. That's the only thing he's he used to be in radio so he can uh he can he can do that part really well. Deepac um 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 what your company is doing is super interesting. So the first topic I kind of want to jump on is like why most staff never ships. So you work with tons of founders who have great ideas, but what actually stops it from launching or like what like where do they where's the most place you see it getting stuck before it launches?

Yeah, sure. So I think that one of the biggest I mean it's what's interesting is that vibe coding today is actually widened that gap that the biggest issue I think to a large degree is always product judgment. So we talk about product judgment is that even previbe coding the easiest thing to do was to either overbuild or not build before you found let's call it product market fit. So I think there's a couple of pockets for why founders have problems. So number one it's there's a surprising amount of founders who have 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 I think that my my experience of it 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. So I I I often think that it's a little bit like and it still hasn't changed to a degree. What developers used to request previbe coding was give me a spec of exactly what you want to have built. And the whole point of that was what you're really being asked is think really deeply about who's going to use it, how they're going to use it, what problems we're going to solve. What's happened now is that that that 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's 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 so you end up getting a lot of what I call just products that for 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 I find it very fascinating. You can vibe code applications. I think the I think the front ends are fairly good. Um it's more the middleware uh the middle space, the back end, um how you're doing storage, how you're doing persistence, um all that kind of stuff that is is struggling. Um, 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, like what is the the ultimate goal of it and they they're very good at convincing people their vision, right? So really good founders have this good vision. The challenge becomes like how do you take that vision and you sell your first million two million in ARR and then you take that and one articulate it to a sales team that can actually execute and sell on it while building the product to 100%. Like where I see where I've seen in my career the problem has always been they that that last mile is super important from a value impact perspective. Is that what you see as well?

100%. I think that the the the you know that if you take Parto's principle, you know 20 80% of the value derived from 20% of the product. The irony is is that that 20% or that 80% comes lost

10 to 20% of the build because

otherwise people build fundamentally generic products and people don't factor in the cost of change is significant. So there needs to be such a demonstrable difference if you're building something. Again thinking about the phase that well the basic state that people maintain is that I don't care just just 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's multiple alternatives anyway there needs to be something that's significantly better and that comes at that last 10 to 20%. And now with vibe coding, you don't get that from the LLMs, right? Because they cater for the app and unless you get to such a level of prompting, but even then a simple example of it is we were building a task management app and what the LLM's couldn't provide for the user is like, okay, great. So now we've got a subtask. Do you want subtasks to, for example, 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 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. And I said, the LLM's aren't going to tell you that, buddy.

And the other problem with LLM, and listen, I love me a nice vibe coded app. I vibe code some stuff. I'm certainly not at the level that Dale is, but the problem that I see is when it comes to the integrations, like listen, I have no coding skills whatsoever, right? I could build a cool app that I could certainly hook up to HubSp 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. Like that's the biggest problem I see. And when you're building cool stuff in a silo, that 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.

Yeah. Yeah. Yeah. I 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 you need really aggressive bug testing almost at a full-time level to test across browsers, across devices. And and and people don't necessarily understand at a development level that we we will do it to a degree, but you need someone who's going to do this. And people talk about Playright and Lambda and none of these tools replace human testing when it comes to actually testing. What about iOS Android? Oh, what about iOS on Apple? What about Android on on on on Chrome on Android? What about Internet Explorer versus Opera versus Firefox? You got to do the same dang testing. And and that's the the understanding of the the level of testing because you've got your HubSpot example, Adam. What if you're using HubSpot in Internet Explorer? Does it change based upon the way that they integrate? So

people use Internet Explorer.

Yeah. Yeah. Yeah. I mean I ironically I'm using so I'm an edge case right now for Riverside which we're recording on because 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 then I go I'm an example of an extra

right you just switch browsers. Sure.

Yeah. And I might be like oh Riverside you're not fixing it for me. So there's all of these variations that you know VIP Cody hasn't solved really to be honest with you. And I think that 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 to be doing the development to also be doing doing the thinking to also being doing the testing to also understand the product judgment because therefore different kind of mind spaces completely and where they come in and ask one person to do it. That's where you of course you 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. So let's um I I want to shift gears to the the 27 days. So you've built an entire model on launching SAS in 27 days. Like how the hell is that even possible?

Yeah, sure. So what um I I think the 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 new lovable or claude code you can develop a a good ultimately framework that you can either remix or clone now there's general things that anyone who wants to vibe code a web- based SAS app or whether it's mobile fundamentals that everyone would expect single site you know single SSO you want um two-factor authentication, you want uh 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. So 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 LLM's like AI orchestration but if you start introducing new APIs I'll say well that extends a road map 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. Yeah. Exactly. So, so, so I mean, you know, the reality is there's we we we spent a lot of time building a foundation. we've understood things that we're 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 said also 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 and could that be fulfilled for example deterministic logic which is which is actually what people use a lot of the time without really you know needing AI as such. Um so so so there's a lot of kind of caveats that we'll build in and then given that constraint we'll be 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 dial dialing down into ultimately what is buildable within that framework and then 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 Adam if that makes sense in respect of how we'll think about you know what do you what can you 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 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 because we tried the automated way. It just didn't work. It just didn't did not did not work. So, so, so, so that's been a big thing for stabilization because the big letdown moment I experienced it because I spent maybe about depending upon who you're I spent about 300k previbe coding in failed development with partners and contractors and I had for the last 101 15 years and I had this world of experience and the one recurring theme that stuck in my head was that I was always disappointed.

Here's something I keep seeing with sales teams I work with. Generic sequences don't work anymore. We've all gotten so good at turning out the noise that even your own buyers are ignoring you. The problem isn't your reps. It's that your sequences are static and your signals are somewhere else entirely. That's why our clients use Nooks. And the thing that stuck with me is that their sequences actually stay fresh because the signals update them automatically. Right buyer, right moment with no manual babysitting. If your outbound feels like it's shouting into a void, go check them out at nooks.ai. AI back slashbridgeidge the gap

when I when a developer would get excited and say hey I've shipped it and I'd have I 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 I don't want to be I don't want to be me a couple of years ago. So so that was what made me think that you know how can you create that aha experience and that was where the the the need to just have dedicated bug testers came in even if we're a small team. So you you said, "I see you've shipped it." And one of the things that we talk about a lot is when you ship when you ship, what is shipping fast verse 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 the the the first thing I I believe is that from a from a 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 demonstratively 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 the the the 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 I liken it to a little bit of um I was asked about what about AI agents for cold calling deep 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 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 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 no novel and new, the benchmark can be lower because because of that. and and and and of course the underlying thing is that does the core product just work go and and and and and again it also depends upon the model if you have a self-s served SAS then there's more development if it's a gated behind a demo and you have a core because the ACVS are quite high then it's a guided tour type product then then then maybe you can you can afford to do things a little bit differently so I do think that that changes also depending upon who the who the audience is if it's B2B I then then the scope changes if it's like right we've got a sales process we get them onto a call then they we show them a demo so it's all guided uh and that's obviously only warranted when your your your 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 um

I love it

yeah it's And it gets it gets it gets a little messy because people want to deploy stuff. I've I've gotten into this as I've been building some things for us and uh you get to a point where 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 to focus I find on like completing some of these things in the vibe code world. of 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 when you build a new feature or function like people don't realize you got to go regression test everything that you just yeah built prior to and they don't want to do that. So I do like that.

I agree

as we um Yeah. 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 co 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 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 and that has now been more effective for us than any other environment because I thought I need to hire for someone who enjoys this kind of work and who gified and that's where I found computer science or or some kind of engineering type of um there's things that they miss and there's product judgment that maybe isn't quite there but for what I call for me or for you the the drudgery aspect of it. Fantastic. Brilliant. That has helped stabilize stuff more than more than other people that try to get bored.

I love that. And if and I would give the people that are vibe fixing, if they keep it below 50 and they don't let the the bug finders get above 100, then I'd give them $200. Like Yeah. Something like that. Amazing. Yeah. Cool. Cool. Cool. Cool. Um, so you talk a little bit about replacing the tool stack um, uh, you know, and and replacing the paid tool stack with customuilt apps. So what do you believe is driving that shift? And because I have a I have a hypothesis that actually CRM will not really exist like CRM are just glorified databases that you can stick a vibecoded 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 the our goal with building our products initially was to replace tools that we pay for. So simply and and 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 I 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 for you can book me I think that we use and then we use paper form and then we use like you can book me paper form and there's a couple of others I forget now like HFS 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 ultimately 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 the kind of 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 so so that kind of was the 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 I think to your point what's interesting you know what what 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 the kind of 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 um you know for for for a certain group of founders or companies which are primarily top 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 I 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 crypto coding or whatever it may become. So I'm I'm quite excited about this era because now for for for people that are historically you know I'm not development centric but it means that those who have a great sense of product jud judgment you can you can build products that you've not previously been able to articulate to others uh and and and and also 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. Um, I I

You know what's coming. You know,

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

Um,

when you look at like I I want to piggyback on, you know, replacing paid stacks with customuilt apps, like where does it make sense to build versus buy? I think that it makes sense to build when you have a internal infrastructure that's that's that that's 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 about saying hey cool you can build everything and replace it but there's that there's still this 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. Um, the the place where the hard is, I think, has changed slightly, of course. Um but I would say that unless you have a internal readiness to really invest time and IQ into it at almost ownership level then you're not going to build anything that's that that that that that is 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 you if it's deeply embedded within your workflow and the product in and of itself is sophisticated and and the logical thing is that if you 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 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 and I think

Yeah. Yeah. Yeah. So then everything becomes overengineered and and

so and and that go Thank you because that that's literally because we have time for one more question before we go rapid fire. That was my very last question is you you're you've said publicly that you're over anti-engineering 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.

Um 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 the the aha moment. So the first 15 seconds is where perfection exists with with with Tik Tok with reals 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. And and and 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 that 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 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. So, so there you go.

I have too. I have too.

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

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

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

yeah, actually after this I I carved out some time to talk to him. I Deepac 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 SAS trend that you think is overhyped

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

Oh, come on. Jason Lumpin is not saying that he's 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. my experience has been.

What's one tool that everyone should replace immediately?

Good god. Um,

I never got that question.

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

Awesome. Last one as we wrap up. Dream vacation destination.

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

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

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

Awesome. Deepac, thanks so much for joining the show.

Thank you, sir.

Thank you.