How to Validate an AI SaaS Idea by Building It in a Weekend — with Richardson Dackam

Hey, what's going on everyone? Welcome back to Mastering Tech Growth. Every week we chat with industry leaders to bring you big ideas on how to grow. I'm Mike Sirius, and today we are asking one big question. Can you really validate and build a SaaS product using AI in a single weekend. Joining me is Richardson Deccam. He's built a full ecosystem around one goal: helping founders build faster using AI. He runs Shortcut to Mastery podcast, writes a popular Substack on AI-driven app development, and teaches thousands through his courses and masterclasses on Gumroad. Richardson, it's awesome to have you on here today.

Pleasure to be here.

We love to kick off with this one. When I say mastering tech growth, what comes to mind?

Mastering tech growth. I will say in the age where we live in right now, I will say probably AI because, um, everything that we touch right now, I mean, AI touch almost every single thing that we're doing now and it's going to keep growing in that direction. So I think if you want to build faster today, you have to get familiar with the tools that allow you to build much faster at an exponential speed almost. And then I think AI is, can enable people to do that.

Okay. So if you would choose from all the things that influences tech venture growth, so that can be like sales, that can be marketing, that can be hiring a good talent or using tools such as AI effectively innovating, if you allow to choose only one, from your point of view, what is the most important factor that influences growth? Growth in terms of building an application fast or just the business growth, just a tech venture business growth on paper, you just growing. So, you know, revenue is growing, people are growing, market share is growing, everything is just growing.

I think iteration. So someone trying to do something, they're testing if it works. Talk to the customer, fix things and go back. So the quicker the iteration, the faster the growth. I think that's why like startup like, you know, Cursio have grown so fast or Windsurf because they talk to customer consistently.

Yeah.

Try to identify what they could fix quickly and they don't wait. A lot of time startup that die quickly tends to wait or take a long time to do things. And I wonder when you run out of budgets or run out of cash flow, you know, and then it's all—

So we're basically saying that Facebook, or now Meta, was right when they said move fast, break things effectively, you know, just have, just ship, ship, ship, ship, get that feedback, make that feedback loop as short as possible.

Yes, I think they were right, but you probably watched the story with that That lady that was building a Blurred startup and then she was moving fast, breaking things. So I think it works in some context, in some startup, but there's some areas where you might not be able to move fast and break things like health, where you want to have more of a slow pace of moving. But I think in general, in tech, the faster you move, you know, you should expect that things are not going to work as you want.

So does it depend then on the maturity cycle of the business to some extent? Like if we're saying, if you're just starting, you probably want to move very quickly. You just want to shift things, get that feedback. But once you get that traction and potentially, you know, like you find a market product fit, then you, maybe you shouldn't think of moving fast. Then maybe the quality becomes more important.

That's an interesting point. I think generally in tech, you could always move fast. I think the reason why bigger company moves slow is because there's too many decision points and things start to move slow at this stage. But I think there's a desire to move fast for people internally. It's just, you know, asking questions, asking permission is what slows down big companies. And that's why startups always have an advantage over big startups. So I'm not sure if it'll be based on the size. I think there's always an and aim to move fast, but then different system and the size of your organization can affect you in terms of how fast you are able to move.

Yeah, I love you. I love you.

Yeah, you probably experienced that with your own podcast, growing your own podcast, how moving fast changes based on how many staff you have or something like that, right?

Yeah, you're absolutely right. And as well, I work for enterprise right now. Well, it's a career progression, I would say like this, Richardson. So I did startups for a very long time. I have a lot of them just failing, effectively a lot of lessons learned, you know, couple of them did well, you know, I sold couple of them and effectively right now I'm in this sort of enterprise environment, very big companies, thousands of developers, very big projects. And you're absolutely right when it comes to decision points, there's so many moving parts or connection nodes and when you need to push something out, So many people need to get involved, so many green lights you need to get, and then development itself is not as fast, especially if you are a regulated market. You need to have regulators looking at the code, getting approvals and things like that. So the bigger you become, the slower you move basically, right? It's almost like a law of physics or something like that. Like, you know, if the ship is huge, you know, it's not going to be a speed car, right?

Even in nature, that's why dinosaurs, you know, like they weren't all that fast, right? The bigger they are, the slower they are.

Exactly that. So, so there's a definitely disadvantage with the startups, which is very enjoyable, you know, very enjoyable phase in any business is that beginning, that startup-ish phase, especially if you like speed, if you like creativity and just, you know, getting things done, pushing them out. So let me ask this, Richardson, when you work with new founders, Uh, what's the moment you usually see them get stuck? Is it the endless idea testing, planning, or something deeper, like a fear of getting it wrong in public?

I think there's a couple of failing points. One big one is just the idea. Uh, you know, even like, even once you allow them to find an idea that is worth doing, oftentimes they just freeze either because they don't understand how to validate the idea or they don't understand how to execute it. So they start questioning what kind of tool they should be using, what kind of platform they should be using. So they get this decision paralysis of how do I validate my idea? Should I start to sell to customer before I build it? Should I build it? And you know, there's different literature out there that one recommends you to try to sell your idea before you try to build it. And another that says, oh, you should build first, have a prototype. So there's also that confusion. That is a paralysis that they have where they don't know which one is the right message. What I always recommend is just start with the minimum idea that you can build. Like think, what's the one pain point that you think you can build easily and try to see if there's any way that you can validate that someone else has done that before, or if customers have talked about it. There's platforms like G2 where you can see what customers are complaining about, or Capterra. You can go on Reddit, and now with AI, you can even question AI about what are the pain points that people have with my idea and give AI the role to actually validate your idea. So this is something that I consistently do. I will like write down, give a role to my AI so that it can validate an idea for me. And I'm not sure if you're familiar with, have you heard of BuzzAbout? I think it's BuzzAbout.ai.

No, no.

So it's, it's a platform that allows you to essentially, you can ask questions to the AI as if it was your customer. So, and then it will go on over social media and ask questions and try to understand what people are thinking in different social media and come back with the answer. There's another tool like that called GummySearch that does that on Reddit.

Yeah, no, GummySearch. Yeah. I use that quite often. Yeah.

Similar, but BuzzAbout is for all the other platforms like YouTube, you know, LinkedIn, all of that. They combine all of that social language and then they just tell you what people are thinking about on those platforms.

Okay, we'll definitely add this in the show notes. So effectively we're saying there's a platform which looks at the whole socials, the comments, the content, and you can have a chat like you would be having a chat with ChatGPT and go like, hey, I need some pain points that I can help people to discover, not to discover, but cover. And effectively what you're saying, what you're saying is that you would want to take one pain point and you would want to build something to address it and then try to position it and see, uh, you know, if that actually resonates with the market like that, that is your process, right?

Yes. But usually before that, I like to follow like the value formula. I wanna make sure that the, that the pain point will deliver enough value for someone to actually care about it. Because if I could pick one pain point, but no one's willing to pay for that pain point, I would essentially just waste my entire time building a product for a pain point that no one is willing to pay for. So I think considering what people are willing to pay for is like so crucial if your goal is to make money with that startup. And then a lot of startup founders miss that. They say, oh, this is a really big pain point, but no one is willing to pay for that.

Yeah.

So also sometimes there are, um, there are, I guess, painkillers— sorry, vitamins disguised as painkillers. For example, when I was working on ZonGoat, I bought this app that allowed people to validate that properties can meet local regulations, right? Like, crazy tech could scan any property in the US and Canada, and you can find if a property is valid for cannabis or for any other type of use.

Yep.

And it sounded like a painkiller for most real estate people out there, I was like, because they had such a huge struggle finding property and sometimes it would take them weeks to months. But once they had the product in front of them, you will think that they will desperately try to use it. But then I realized that it wasn't really a painkiller. It was more like a vitamin that was enhancing how they deal with the problem, but they weren't desperate for that solution because they had other things to focus on. So sometimes you have problems that are disguise as, as painkiller, but they're actually vitamins.

I love how you put this over here. So, uh, vitamin, make sure you're not giving some of a vitamin, make sure you're giving them an actual painkiller, right? So it's like, I'm just imagining, right? If I have a, um, a flu, right? So I will want some medicine, right? Cause I'm feeling shit. I just like, I need to get better cause I have no energy. I need to be in bed and all that stuff. So I just want the medicine. That's a painkiller. But once I recovered and I'm feeling good, I don't need that painkiller. Maybe, you know, I'll take some vitamin C so I can just, you know, protect myself. Like, but that's, yeah, that's not my priority. Like, you know, maybe I buy it, maybe I don't. It depends on season or my mood or something like that. But the painkiller is like, it's unavoidable, right? So how do you know, like, how do you know that you're actually creating a painkiller, you know, to your point of, of you building something and that actually not being a painkiller, how does your validation process look right now? To just make sure that you're doing that painkiller approach?

You want to make sure that the solution that you provided is going to help people do something faster, that is going to give them— I think Alex Hormozi is the one that created that, that perceived likelihood of achieving their goal. And then if it can meet those criteria, like making it easier for them to achieve their goal, help them save time, then you can kind of quantify that in terms of how much time are they saving, how much money they're going to save, that, and it kind of gives you a sense of how big of a painkiller it is in their pocket and also in their workflow in general. And you can use AI to figure out what's— what— how someone with that pain point will actually deal with it. You can literally ask AI, like, will this thing solve your problem? And because AI has the entire web in its mind, it can, it can actually tell you what someone in that position will actually deal with or how they will handle that. That pain point once it is solved.

Okay. You are actually a second guest, Richardson, to mention Alex Hormozi's Value Formula. So that's such a popular piece of information.

Yeah, I use it all the time. Even when I prompt for an idea, I always ask AI to make sure that it follows Alex Hormozi's Value Formula because it's like a shortcut, right? Instead of spending a lot of time figuring out which pen is the best one, you can just use the formula in order to make sure that I'm addressing the right problem that actually addressed the formula.

So do you believe from your point perspective, I mean, AI is good enough or is it good enough of a start to sort of validate idea, but we still need to go to the market and, you know, do some landing pages, you know, try to pre-sell it before we commit, you know, commit like real bills, or do you feel like it's enough to get AI and you go like, like, okay, I got my confirmation, I'm gonna now go build that.

Yes, I personally believe that you get enough ICP and then, you know, personal mindset with AI, but you still need to obviously talk to your customer because they're going to interface with your UI and your UX. AI doesn't know that. So even though you might be addressing the right ICP, when your AI will look at your— sorry, when your user will look at your tool, They're looking at your language, at your marketing, they're looking at your website, and you won't need to talk to a real person to get feedback on that aspect.

And do you have approach of how you do that? Is it like, I'll create a landing page for potentially what I'm trying to build and I'll get some feedback on it, or do you just build and launch and go to socials and like, you know, let's chat, I need some feedback. It's like, what's your go-to to source an actual market feedback?

Okay, so I have a couple ways I do that. So one, one most obvious way is to go on LinkedIn and you find people in the field and you reach out to them and say, hey, I built this tool. I would love to get some feedback for you. Now, sometimes people might not always respond to your email or, you know, all of your messages. Even if you go on, you can also go on X or Twitter to find someone. The other way you can do that is actually going on this site called clarity.fm where you can technically talk to experts in different fields. And you can pay them for the session. So say I want to talk to a health specialist, so I can pay them for their time. Let's say $60 an hour. And now I'm in, in a session with that expert that is giving me 1 hour of their time. And I can ask them literally any question. I can show them my startup, show them how it works. When I was in college, I used to go on this site called score.org, which is, if you live in the US, this is a tool that makes it super easy to Reach Out to Experts. I've used it even here in Canada, even though it's meant for Americans, but I've used it in Canada. And you can connect to local retired experts that are— were experts in different fields. And I can just reach out to those experts and then show them my app and get feedback right away. So I find those are like— it's probably like the fastest way to get feedback if you don't know where to find your user. Now, before I work on an idea, I always make sure that I know exactly where my users are because then I'm going to waste a lot of money on marketing to try to find my user. I don't want to pay Facebook ads to find them. So finding where my users are also makes it a lot easier for me to reach out to them when I need questions. An example of that is 8nodes. So 8nodes is my startup that allows people to generate N8N workflow by using just like natural language. A lot of 8nodes experts, sorry, of N8N experts, are on Upwork. They are on platform where they want to sell their service to people to build workflow. So I know exactly where they are, so I can just reach out to them on those platforms and say, hey, can you give me 1 hour of your time? I'll pay you and to give me feedback on the tool that I'm building. So finding where your market is always make it a lot faster for you also to move forward. So it's not just like finding the pain points, also where my market live so that it's faster for me to build this tool. Quickly and to get feedback even faster.

So a couple of things here, Richard, which I love. One is a cheap, free approach. Let's call it like this. Let's just call it like this. We want to be cheap. We have no money. You know, we don't want to invest anything. We just want to know. So we go on socials and we pretty much go, hey guys, can you help us? Can you just give us an opinion about that? And you spread the, you effectively spray and pray type of situation. You just send everybody a message and you expect someone to come back and give you feedback. I'll To be honest, I get some of these on LinkedIn, right? I wouldn't say it's a lot, but I often get someone going like, hey, I built this startup, you know, can you check it and let me know? Oh, I never engage with that. I honestly don't have time. And potentially people would if it resonates maybe as a feedback. But the second one, which is not really that expensive, is to actually offer someone a little bit of money for their time. And their expertise to get the feedback. I actually love that. And literally just a pure coincidence, had the chat yesterday with someone who were looking into my background and they were like, hey, you worked in that industry, you know, we're building product for that industry. We just want to have a chat. And they were like, you know, we'll pay you for your time. That definitely works better because I was like, great, you know, you're going to buy me a lunch. Why not? Let's have a chat. So that's good. So you validating, you know, your idea. Now you mentioned about knowing where your ICPs are. So ICPs being ideal customer profile. How do you do that, Richard Son? How do you know where your ICPs are?

So the quickest and easiest way is asking AI, asking ChatGPT, Cloud, where, where, where can I find them? You can also go on Perplexity and do a deep research to find where people in that, you know, specific industry live on the web. There are different tools that I found. They were— I can't— I don't remember from the tip of my brain, but there were two that allow you to find community. What is the name? Was along the line of Beehive or Bee something like that, but they allow you to find community on the web, like Slack community, School community. So School actually could be a way for you to find also your ICP. Um, in my context with 8 nodes, there's a lot of people that do automation on School. Yeah, I can just go on School and find other automation group. Now it's harder for me to reach out to them there, but you can become a really active contributor and people will start to be curious about what you're doing. So that's something that I'm doing in Greg Eisenberg community. It's like another YouTuber making videos about like startups and so on. So I'm very active in that community, and oftentimes people reach out to me directly and are curious about what I'm building, or they look at my profile and they click on the links. I get a lot of traffic coming from school kicking my own startup that way. So that's a free way.

So that's a community, right? So effectively what we're saying, this is where you're gonna, you will find people, right? So it's like Facebook community, Skool, by the way, Skool is Alex Hormozi's, right? Theskool.com where there's a lot of communities. Slack has communities. I'm sure like you could find communities on WhatsApp. You know, Facebook is still very big with communities. LinkedIn has groups, but I never personally used it. I don't even know if It's still a thing, but there's a, effectively we're saying find where people hang out, right? Like find a group which resonates with your ICP. But once you're in that group, are we saying that everybody in that group is potentially your ICP or do you do some type of like, you know, deeper filtering to find, you know, like a perfect match, you know, maybe an age, maybe ability to spend money, I don't know, ability to have these pain points you're looking for. Is there more filtering that you take down?

Yes, this, this different way I usually do that. So sometimes I can try to reach out to people to like to set up a meeting to just talk about a problem together that we might all be facing. And through that conversation, you can find people that are, that are more fitting for, for your niche, because you can say, for example, can you fill up the form before you join the meeting? Right. And then people can fill up the form and join the meeting. The other things you can do, you can ask validating questions. Like, you know, in public, like, oh, is anyone dealing with this? And then someone might answer, you say, oh, can you send me a DM? I'd love to talk to you about something, or just reach out, oh, I have a question for you. But like, it works more when you come with a, with an angle where you're trying to help them or contribute to the conversation rather than you want them to help you. That's what I found. When, when you go there and just ask them for something that you need, oftentimes people don't really respond to that, right? So I always try to figure out first how I can help them. So I ask general question, is there struggle with that? And I say, oh, I found this great resource, or, you know, I try to help them first before I can validate if they're part of my ICP.

That's excellent. I got one way how I do this. I call it resonation signal. It's a very fancy name to call it, but effectively I go on Reddit and I go to the community, which, you know, likely will resonate with my pain point. And I make a post by saying that I have that problem and I ask if anyone else has the same. So I go like, hey, here's my pain point. Is anyone dealing with the same? What do you, what you guys are doing about it? And then usually people, like if they resonate with that pain, they will be like, yeah, yeah, I got the same. I don't know, you know, I use this tool and that. And if I get a lot of traction in conversation-wise, I'm like, okay, there's a pain over here which potentially could be resolved with the SaaS product or something else. So there's many things we can do about this, right? So we got an idea, we validated the idea, we know our ICP, ideal customer profile, we know where they hang out. So what's next? Do we go build that?

Once you have the, usually once I have, I know my pain point, the ICP, I spend a lot of time doing deep research. I will say usually it takes, it takes me longer to do deep research than building the actual product, right? Because I can build a product over a weekend or over a day sometimes, but sometimes it can take me like 5 days or 4 days to research the idea. And, and I, so I really want to understand the problem as if I knew the customer at a psychological level. So I know why they click buy. Why, why they frustrated about the problem? How does that actually affect their life? Right? I really want to understand their persona. And then I do that in different ways. Sometimes I do role-playing with ChatGPT. So I'm going advanced ways and I take the role, you know, of me trying to sell them the product and I just have a conversation with them and the problem. Or I take the role of a counselor where I just want to understand their pain point and want them to share that with me. But I just do this ways-acting conversation. And then through those conversations, I oftentimes discover things that I never even— didn't even know existed. And I take notes. Then I use those notes to create my deep research on the problem, because I'm going to use all of that in order to test the value formula, to test the— to create my PRD. So product requirement document that I then go into feed to AI to build the MVP prototype. So until I know the customer at a psychological level and the user behavior and all that, it's rare that I jump directly into building. I think the term is called psychotherapy. I forgot, there's a term related to understanding how your customer spends money online. And I think once you understand that, I think it's a good time to start building.

Okay. So when you said deep research, Richardson, is that just a term you mentioned or do you actually mean a research, which is a different type of request to ChatGPT or other AIs? You know, they have a casual conversation button and they have a deep research. Are we saying that this is what you mentioned here or it's just a general process term?

Yes, it's that deep research, but I do it on different area. I'll do it on the ICP pain point. On, on their, how they think about the problem, psychology, competition landscape. I will use the research for that and to really have a holistic understanding of the, of the space. I do that on the markets to understand how the market works, what are the forces that, that affect that market, so that I don't jump into an idea that's going to die soon. And I even do Google Trends to see if it's something that's coming or something that's going to die. I really want to understand it really well before I build anything, because I've, just like you, you know, you told me, I built a lot of startups, a lot of them failed, and I want to avoid, you know, failing on more startups. So one way to do that is spending more time doing the research.

Yeah, I love that.

Understand, you know, this is when I can start building.

Okay, so we're doing a deep research. Um, is there a tool which you believe does better when it comes to understanding your potential customer, which you're gonna target that pain point for, you know, you have multiple tools. You got ChatGPT, you got Claude, you got Perplexity. Then I think you mentioned some dedicated SaaS platforms, you know, to doing this. Like, do you have tools which you know work better or like, or is it just like it doesn't matter? You can just go to talk with any of these global accessible AIs.

For social listening, I find that tools like Gummy Search and BuzzAbout are better because they are designed to listen to social media conversation. But for general questions, it's all about context engineering. So the more context I give the AI, usually the better response I get. I don't have a preference between, you know, Grok, ChatGPT, or Cloud. Yeah, my go-to is ChatGPT. At one point it used to be Grok, but it's ChatGPT right now. And I'll just give it all the content that I found from all my deep research. So Okay. I do deep research on competition. I get the PDF, upload that to one single ChatGPT session that will have all that context to have a holistic summary of what's happening.

And the roleplay? So we feed all of that information and then we do the roleplay. That's as well in ChatGPT?

Yeah, so the roleplay is an iteration that I do on ChatGPT. So once I give it all that context, I go back into roleplay mode because now it has more context about the problem and we can start tackling things differently.

Okay. So the PRD, you mentioned that you feed that into your AI to prototype effectively your product, right? So we're now talking about how do you go from, I have all of that deep research information, so that generated a product requirement file for me. So now I'm going to feed that into AI and go like, build me this, right? Like, so how that stage looks like in practice?

Okay, so I'll take the deep research, make a summary, then I give a role to the AI. I say, you are an excellent software engineer. Sometimes I even start with the role of, you are an excellent prompt engineer, because they allow me to optimize the prompt. And if I optimize the prompt, it's even better quality because it has context of the ICP, and then you can optimize the prompt for building something for the ICP. And then after that, I ask it to generate me a PRD. So I give it all the context and I make sure that for the PRD, I specify a navigable prototype. I never say just generate me the app because what I want to focus on first is the user experience. I say, uh, you are an excellent UI/UX designer, generate me a navigable prototype that I can use, that has, um, where I can test the comprehensive pain point and test the, you know, the MVP in the application. And this way, the app that is going to be generated with the tool that I use, I use v0 for stuff like that, will be fully navigable. So I'll have a login page, but I wouldn't— entering any password will work. So I can see the experience. And I make sure that when I join the PRD, sometimes the PRD doesn't include pages or backend API endpoint. So I always ask it to make sure to include that. The other thing is I ask it to— I'm very specific about what I'm building because it's not just the idea that I'm building, it's also what kind of— how I'm going to build this, right? So I'm usually— I go with Next.js. There's a reason why I prefer Next.js now. I work with Ruby on Rails for like most of my career, like for almost like 14 years, but now I mostly build with JavaScript and Next.js because it's easier with AI. And once I give it all those contexts, then I generate my PRD and it has, you know, uh, the UI/UX the pages, endpoint, and then the AI know exactly what is going to build for me.

Okay, so you mentioned one tool, I think you said v0. Is that like just a tool you chose or is it a tool you chose by trying other tools and you just know that that's better one?

So a mix of both. So I've tried to generate with Cursor, with Cloud Code. I just found that v0 is a really quick way for me to not only generate it but also share, share a link with people. And I think that's really important because when I want to test the idea, I won't have to deploy to an entire new domain. I can have a test domain where I can show to someone and get rapid feedback to improve the experience before I build the full product. I always build the full product on Cursor, so I will remove it from v0 and put on Cursor. But I always start with V0 because of that, because it gives me that flexibility of deployment and also sharing the link super easily. I think bold.new has something similar. Just through experience, I just, I really like the usability of V0. That's why it's my go-to.

Okay, so we got the PRD that goes into V0, spits out the front end and the back end because, because does it actually do the back end as well? Are we talking right now just about the pages?

It can do the backend. Like for example, Next.js is a framework that has, uh, it's a JavaScript framework that has frontend and backend. So oftentimes I will do the backend, but I'm very specific. I don't, I ask it not to generate the database logic, but you assume that local storage, which is the storage that you have in your browser, is used as a database for the navigable prototype.

Okay. So we get, basically we're getting a frontend driven prototype, uh, and, and we're getting a shareable link so we can share, we can get that feedback, which we talked before. From our customers. So at that point in time, what takes place next is like, do you try to sell this and go like, you know, I imagine you have a couple of iterations, but like what's after that? You, you know, like do you try to sell it or do you just go ahead and build it?

So it depends. So some idea of, I've created landing pages or even a form with Tallyform where I literally just have my idea and I just show a screenshot of the idea on X. In different group committees on X, and I shared the link to the form. I say, if you're interested about this idea, go fill up the form. This way I can get early users to sign in, right?

Okay.

So because it was so quick for me to create the prototype, I just created a full prototype and launched it. And then I tell people, hey, like I've launched this app. No, this is what it's doing. Usually I like to make like little video where I show a demo of it. I use Loom for that and I show a demo of how the prototype works and so on. And I get feedback oftentimes in the comments on X. If I post a video on YouTube, it'll be on YouTube. And I also share that in my own community because throughout the years I've learned that building your own community is the fastest way to launch product because I've seen all those, you know, people on X that have a huge following and any product they launch works. Why? Because they have a community, right? They have a big community that they can sell the product to.

Yeah, that's a good shout. Yeah, you basically get your beta list right there, like by building a community, right? You take care of them, you give your knowledge, you know, there's a there's an iron sharpening iron type of situation where you grow by learning from each other. And then if you launch something, it's just like, boom, you know, it's hundreds of people already giving you feedback. So just enables you to move much faster, isn't it?

Yeah. For example, in your case, for example, like, you know, you could, if you had to, you were building a tool for your audience, they would already be your beta list right there because they're familiar with what you do. They know you. They know that you're building product that will help entrepreneurs like that. So they'll be interested to use something like that.

Yeah, 100%.

Remove that barrier.

So I want to take us a little bit step back. I want to ask about idea dying off. So you mentioned that I don't want to build something which dies off, you know, tomorrow or very soon. Potentially I'll look at Google Trends. So I want to dig a little bit more into that. How do you know that it's not going to die? Like what's your sort of green light signals that this is idea which is not meant to die?

Okay, so for that I have a different framework. So I realized that there's like 3 types of ideas. You have an idea that are do-it-yourself, they have ideas that are done for you, and you have the idea that are done with you. And then the difference between the 3 is do-it-yourself is like, let's say a SaaS that you use where everything you're doing on this SaaS, you have to do it yourself. Like an example of that would be like language app, right? Like you won't, even if someone built a language app, even if you do all the marketing you want, if someone is not, doesn't want to learn that language, it's gonna be really hard for them to convince them to learn the language. And even if you have people that want to learn the language, they still have to allocate the time to do it. Those kind of startups are really, really hard to get to grow. So because you need to convince people to use the app, you need to find them. It's just, I found it very tricky. So I tend to avoid this kind of idea. Now you have, um, done with you, which is kind of similar, you know, but, but, uh, part of it is done for them, but they still need that commitment to do things themselves, or you have them do something automatically, but they still need to invest some time to do the other part manually. Now you have done for you idea that like, that are like generator, like app generator, like Cursive, or like, um, or like things that, for example, you You want to convert a bank statement into PDF, you know, tool that allow you to do things for you, very, very fast to grow with. So I like to, I tend to go more toward those ideas because I find them, it's easier to execute, easier to find the customers and it takes less time to actually see if it's actually going to work.

Okay. So, so we're saying Richard's on scale of red flag, green flag when it comes about idea dying, it just basically goes. From the left to the right, where the right is done for you and on the left is, how did you phrase that?

Do it yourself.

Do it yourself. It's like, if I can do it myself, man, like, why do I need you, right? It's like, I'm gonna do it myself, right? So it goes from do it yourself until done for you. Okay, so that's about trend. So what is your take about the SaaS in general? I mean, we're talking about launching a SaaS in a weekend or prototyping a SaaS in a weekend and validating, right? So I've seen multiple videos in YouTube, you know, from, from people coming in basically going, AI will kill the SaaS market. Like, what's your take on that?

I think, I don't think it will. I don't think it depends what people understand as SaaS, right? Because SaaS is software as a service. AI is also a service, right? So I don't think it's going to kill the SaaS market. It's just going to change how the SaaS market works. You're still going to get subscription. People still going to pay for it, you know, freemium or paid. I don't think it's going to die per se, right? Maybe they mean more like the SaaS market as we know it that is not using AI. That I can understand that argument.

Okay.

And I think that SaaS as a software that you sell as a service that people pay per month is not going anywhere. This is where we are right now, where we're going to keep going, right? We pay for ChatGPT. This is the SaaS itself.

How does it shape though? It's like it used to take us a lot more time to build it, right? It's now faster, right? So we can build, we can do better, we can ship features which people want much sooner. People can take our products, give it to AI and say, make me a copy. So they can come in in the market and compete with us. Probably very quickly as well, but very, you know, very small amount of efforts. And then it's like you add another couple of years and then AI pretty much can code everything. You just go like, hey, I have this pain point, give me a product. Boom, it's up there. It's like with all these advancements, how do you like foresee all of that? You know, I have a pain point, I need a software to solve this. How that sort of like evolving?

Let me ask you a question. I'll respond that, but do you think someone can do your podcast as well as you do?

I mean, there's many podcasts which are a lot better, so I would say yes, but I get what you mean. So you mean there's a flavor of personal branding or a flavor of a brand which exists within the product, which people likely will choose instead of others doing exactly the same?

Well, for example, one example is like my uncle is a university professor at Princeton. And he was saying that, um, that, oh, people are going to— like, why people are going to need teachers? They can just ask AI now. And what I told him is that, well, no one knows what you, you know. So your experience, right? AI is all about input-output. The quality of the input determines the quality of the output. So with his experience, the kind of questions and requests he's able to ask are much better than someone that doesn't have his experience. So he's always going to get a better output because he's going to ask better questions. Is know the space better, right? So even if you were to make a course, the course that he's going to create for his students is always going to be better than someone that has no experience making a course, creating, um, a course for people, for the same students. So there's, so there's that angle. So you have your own experience that, that, uh, essentially increase the quality of your input. So, so two people can have the exact same idea, but completely different experience and background. Different execution.

Okay. I see where you're going with this. I mean, AI in general is a historical piece of information acquired. You cannot look in the future. You cannot think like we think. And as well, it's probabilistic by nature. So it just sort of guesses what's the next word and its output. So yeah.

I would say it's more like your own input, the way you're going to formulate the question, request things. No one can, can copy that. Even if someone is an excellent prompt engineer, they still don't have your background, your context, your experience to ask those questions to the AI. So all the output always going to be different. So that's, that's, I think that's like where there's a huge difference. So I'm never scared of like someone copying my idea with AI because, you know, execution is extremely hard and they don't have my experience building, building SaaS. And then, you know, so. There's always that difference.

I mean, the execution is so highly underrated with people who don't have experience actually building startups. Like, you know, you meet these young founders and they, you know, I got this idea, I don't want to share it because you can copy. I'm like, dude, like no one cares. Idea is not a problem. Like execution is where everything is. It's like you can have thousands of ideas. It's just, ability to actually get that idea into a business is where the whole, you know, skill is. So let me ask, let me ask this, Richardson. Do we have AI hype then?

Probably, but like, I think you can have the hype, but it's still, the hype is still real, you know what I mean?

So the hype is real, we're saying the hype is real. Do you think it's a little bit overhyped when it comes to the value we're getting from AI, or it's just on point? Like it deserves the hype it's getting.

I almost feel like is not even on point. I think, I think most people don't realize how big of a differentiator this is going to be. Okay, you just have to— I just recently watched an episode with, uh, Jensen, the, the CEO of NVIDIA, who was saying that his, his, uh, expectation of like GPU, the kind of thing that needed to generate them, all that is much, much bigger than he expected, right?

Yeah.

So someone in the industry that had a lot of experience saying that this is way crazier than he expected with his own wild expectation kind of shows you that it's moving a bit much faster than we even think it is.

Yeah, I love actually listening to Jason. I mean, his, he, yeah, his conferences are great. I love how he positions AI as well. And then I recently watched Jeff Bezos, you know, coming from retirement and enjoying yachts and beaches, you know, talking in a conference and someone asking like, what's going to happen in the next like 5, 10 years? And he's like, I think in like 10, 20 years, we're going to have data centers in space. And everybody's like, what? And he's like, look, like solar energy over there, no clouds, no blockages, constant, right? And then, and why not? You know, we'll need to train AIs and, you know, where else? Like, you know, from monetary perspective and just like a pure ROI perspective, like it just makes sense. And he's like, once we go up there, you know, again, the speed of acceleration of capabilities of AI, you know, continues basically exponentially going up and then you're like, oh my God, I just, I just need that just a little bit imagination, you know, to see the world in big changes, right?

This is something I love about Jeff Bezos. Like, um, so Blue Origin goal is actually to build the next like AWS in space. Are they gonna like, if they achieve his vision, they'll end up building something like the AWS of building space company and maybe space infrastructure, uh, that infrastructure, infrastructure in space. And I like this vision because you're removing all of the stuff that hurt the Earth, take advantage of the solar energy in space, which makes sense. You have no, like, you know, barrier or anything like that.

Yep.

And you have so much infinite space to create things like this. Exactly. I love that vision, and I think he's on point with that.

Like, it's very— as well, like, 10 years, I'm like, oh, I'm still gonna be alive to see this, you know, Star Trek coming together. So that's gonna be awesome. Right. Let's go back to an episode, Richardson. So we drifted a little bit, but it's a great chat. I love these. So when you were building your product, so you got 8Notes, you got Git Glance, you got Checkmate, all of these basically built over the weekend, right? With your process, which we discussed. I want to ask this question. It's like, how did your first and second and third iteration look like? So the very first one we discussed over the weekend, I got it in, got the feedback. Now I want to build. More. How does the second and the third look like when it comes to that repetition?

Sometimes it can be just a little, just a small iteration. Like sometimes it's removing things rather than adding. I've actually documented Eight Nodes built day by day. So on my XFeed, you can see like where it was at day 1, day 2, day 3, all the way to, I think, to day 20. So you can see like the iteration. And I do that sometimes with my product, but, uh, sometimes, sometimes you don't even see a visual change on the product itself. Sometimes it's behind the scenes, it's like in the backend that I've changed something, changed the architecture, changed the approach. And then whenever I do iteration, I always debate between removing versus adding, right? Because oftentimes I remove more than I add actually, because I realize that, oh, I shouldn't have added this feature. It's distracting to the user. They're not focusing on, it's not really focusing on helping them solve their pain point. And so I try to figure out as much what to remove as it's even more than what to add. And I try to be very careful with what I add. So I would say very small increment, sometimes that you can't even notice in the UI.

But does your process remain the same for the second and third iteration? Meaning that you do the same, like, hey, you know, here's more pain points. So I'm going to take a second pain point and then I'm going to basically go literally through the same process, validate, you know, test, get feedback, and then build? Like, is the second and third iterations the same as the first one?

So it's probably different because it's— I'm sticking to the same pain point, but I'm— but now my goal is to figure out how to best address that pain point, technically to figure out the product-market fit, right? Figure out, uh, or even better, the market-product fit. So where I really want to understand like where, where I need to align the product to really, um, resonate with the market. So now I guess I shift more with for with languages, uh, testing, figure out, reach out to more people to get more feedback. Uh, I monitor the interaction on the app to see how the usage is growing, if the usability is growing. So I think, I guess now shift more in a tracking mode where I want to track the metrics and making sure that they're going upward in the right direction. Like daily active user is like one big one. I want to see how many user activity. On 8node, I check number of threads, average number of threads, because it tells me how many people have created multiple threads to create different workflows. But then I realized that, uh, someone might not need to create multiple workflows with 8node, right? They, they wanted one thing done really quickly and they went there to get it done, right? So based on that, I shift things a little bit. I try to find what are the metrics that are more likely to drives me toward increasing product adoption. The other thing is where I focus on. So I like to really think about my customer segment, technically the innovator, early adopter. I like to only focus on them. So I don't even care about the late majority that are going to come after, or I think the one they call it the Neverland, that you're never going to get them anyway. I always focus on the first one. People that tend to be more willing to try my product and people that are more willing to adopt it early, you know, be willing to use a product that has some bugs. So that's why I always leave a beta on the site because I want them to know that you'll see bugs. Don't expect the experience to be great because I want feedback from this group of people as much as I can. Because if I can build a great product for them, then I'll be able to build it for the late majority after.

Okay. So you, when you build stuff, you're very into, hey, I did this once, I did it twice. Now I want to make sure that process is sort of documented. I want to see if I can automate that process and then, you know, create something which is just repeatable at scale. You have a couple of things which you shared on your social. So I want to ask about SCAP protocol, which is like Skill Adapter Protocol. Can you like talk us through like how did you create that and how that actually helps, you know, execution.

Okay, so, so SCAP was an experiment. I wanted to, to see if there were a way for me to give ability to AI so that it could use those abilities to do its job better. Because I was, because I was using browser automation at the time, and then I realized that there's not real autonomy. And then it's really frustrating when you ask AI to do something and then it gets stuck, it doesn't know what to do. Doesn't know where the button is. So I wanted to figure out if there is a way for me to give them enough context so that they know exactly what to do when they're stuck for the job. So I tried to approach it from, from this perspective of training an employee. When I have a staff, the way I train them, I will, I will technically tell them, um, here, here are the things that you need to work on, here what I don't want you to do, right? Um, technically all the context that they need to know in order to understand the job, right? So when I was designing SCAP, I was like, how can I make that for AI? How can I give the same context for AI? So I went through different iterations, feeding it different things, and it works to an extent where I was able to give him an ability to create an entire Trello project for me. But now you get into the inconvenience of like, you know, AI not being fast enough and slow. So that one was purely an experiment. Because I wanted to see if I could build an AI that was more autonomous than the average AI out there. So just an experiment. I don't use that on my own projects. I use some concept of it, like context engineering. That taught me a lot about context engineering. So I use that aspect in my own projects now.

Does the context engineering actually help you to get better results or get more speed?

Yeah. So In a way, because now I understand how AI uses context and the importance of a context window. So I try to always make sure that I give enough context. I won't take too much of the window so that the AI still have room to operate and use the remaining context window. Because the fuller the context window, the less quality you get out of AI. Like for example, when you code on Cursor, like they now show a context window in it that's like when it's above 40%, 50%, I tend to reset the context window. And by resetting, I mean like creating a new window just to make sure that the quality stays really good. So that's what I learned from that experiment was how to manage my context window and how big of a difference giving an AI context of Abolchi works. Let me say one more thing about the way that it works. So the way it works is that it thinks about how an Abolchi relate to a UI component. So that's how Skill Adapter protocol works. So it takes one skill and see how does that relate on the UI. So if the AI, for example, manage a project, what does that mean? Does that mean you need to move a tab? Does that mean you need to click a button? So you correlate skills to UI component, essentially.

That's very cool. When you discuss with founders, other people, ability to build SaaS products over the weekend, right? Does anyone go like, ah, you're going to be making shortcuts and everything's just going to be messy. It's going to be like a throwaway code. Like, you know, it doesn't work. I've been doing software engineering all my life. Like that's bullshit. Like, do you ever get things like that? What's your take on that?

There are still some people out there, like some software engineers that believe that AI is not good enough yet to code. And then I'm always completely amazed by it. And I— there's always two things that I think about. I'm like, one, you haven't tried AI enough to know the difference, or two, you just don't know how to use AI to get those— the result you want. And often it's always one of the two, because once you've used AI and you know how to use it, you feel like it's a superpower. You're much faster at doing almost everything. I know there's a study out there that say that a lot of companies that were using AI didn't see as much productivity than they expected, especially in web development. So they end up actually addressing more bugs and reviewing more things. But what I realized is that oftentimes they don't know how to test with AI. And testing with AI is not as intuitive as people think. People think that you just say, write me a test, and it's gonna write you a test and test it. But AI has a tendency to find shortcuts. So if you write you a test, it's gonna make sure— write tests that maybe pass but don't actually cover your implementation, or it's gonna try to look for fallback that make sure that the test pass. But in the code, but then you still have issues in your code. So a lot of time people face all those difficulty. They don't know how to test with AI. AI keep, keep, uh, having this death spiral loop of not executing what they want because they're prompting correctly. They're not giving the right context engineering. And then they give up and they say, it's not good enough. I'm going to still coding on my own. But I think it's a mistake because it is really, really fast and powerful.

So we're basically saying an actual ability to extract tangible value from using AI tooling comes with experience and actually learning how to use those tools well.

So you have to use it first and then learning how to use it well.

So if you just take it and you go like, oh, you know, like couple lines, you know, why you're not building everything for me? That's not the approach. Like that's a new skills you're developing. So you're becoming a builder, you know, rather than a coder. And you actually need to learn to use those tools properly, prompt them properly, understand things like context window and things like that. And then you can expect that efficiency boost.

Yeah. That remind me of, you know, like oftentimes when people want to show you that AI is not good enough, they say, oh, I asked AI to tell me a joke and the joke was horrible. I say, how did you prompt it? And they say, oh, I just say, write me a joke.

Yeah.

And I think, okay, well, didn't have a role, didn't have a context. And I said, let me show you how I'll do it. And I'll say, you are this comedian, you've studied this kind of comedy, you understand this kind of culture, now write me a joke. And then now suddenly the joke is much better. It's like, it's all context.

Yeah, 100%. Yeah, that's a very strong, very strong shower of intuition. We had on a podcast Jonathan Musk, who teaches people how to prompt with AI. And we went into, you know, like what is a good prompting techniques and everything you just said is on point and going into AI and going like, hey, can you solve my problems? Like, can you read in your mind, man? It's like, it's not gonna know if you guide it well though, it does perform quite well. So I wanna run this concept by you, which is called micropain. Right? So I did some digging around validation on Reddit and people talk about this, this is, you know, quite often is that, you know, you find a good micro pain. Did you ever heard of that? And, you know, if so—

I haven't heard about the term before.

No.

Are you saying like just like a pain that is smaller than the usual pain or how does it work?

So effectively it's if you see a micro pain, you can build a micro SaaS. Like that's the concept, right? So, yeah, so it's effectively, it's like, you know, whatever is the pain, you not necessarily need to find a huge pain, which requires a huge product, a lot of investment infrastructure and, you know, customer discoveries and stuff like that. But you just try to cover the micro pain with the micro SaaS. And as a result, AI is brilliant for that because it's, you know, it's quite a small product and you can just sort of launch it over the weekend.

I've heard of micro SaaS before in that context. Like that makes sense. Um, there's this guy that built a tool that allows accountants to convert, I guess, bank statements in any format, and he's making something like $40,000 to $60,000 a month with that.

Yeah, it's basically that.

Yeah, ideas like that. Like, yeah, for sure.

In the hacking type of situation where people just look at these, you know, you still have to pay, but the payment will be so low, you know, it's going to be something like, you know, a cup of coffee a month, you know, $2, $3, $4, something like that. But it's still gonna be a, you know, a micropain. It's still something you would be happy to pay these couple of bucks for. And then they, you know, they launch it at scale and then, you know, it becomes, yeah, it becomes thousands. Okay. So what I effectively looking with this is like, you know, how would you actually go about validating micropain and if there's any difference with you know, a pain, pain, but I would assume is the same process would apply. You still need to validate it. You don't want to just build it even if you can build it over the weekend, right? So to—

I would say that I, I, I, sorry, I would say I don't always build like startup expecting them to be million. Sometimes some of my ideas are a problem to solve my own problem that are technically micro SaaS. I don't think they have a big market, but I know they have a niche. So I think just niching down also is good, right? Niche is in the riches. Like they say.

Yeah, that's pretty much the same thing. It's like niches, micro pains, you just go down and down and just very, you know, very precise offering, which is very easy to articulate. It's like exactly that. And then it's actually quite easy to build with AI now. So I got this as well, a quote to sort of land everything there. So across multiple studies, including research from MIT, Stanford, Microsoft, and independent analysis from Merton Cerberus, which is a huge companies, AI-assisted developers complete up to 25% more tasks, automate half of their repetitive work, and gain measurable speed in testing and deployments. The data shows that AI workflows don't just accelerate coding, they make structured repeatable development possible at scale. And I want to add, ask this, Richardson, when you do your things, how much of everything we just discussed you actually have automated?

Testing is automated. And sometimes people don't think about it like as a workflow per se, but I think it's a huge part of development because once I have my tests, then I can just ask AI to build a feature and it's going to run the tests, then run the audits. And I have much more, a bigger guarantee that the feature will actually work as I expect. Also, I think if you have an idea and you cannot reduce it to a workflow, then you don't know your idea good enough. Workflow allows you to break it down into steps that take an input and then an output. So you really think about something come on this side, goes out on this side. So even the idea of converting your idea into a workflow can, can not only allow you to launch an MVP faster, but also to test if you can really build an MVP for your product. So maybe that should even be the MVP test. Can you turn your, your idea into an N8N workflow or now Agent Builder workflow with, since OpenAI just released Agent Builder. Because if you can minimize it like this, then not only you really understand your product really well, but you know how to make it, the solution so simple that anyone can use it at that small scale.

Is that how your mindset works? Like, you know, can I make this into a system? Can I make this into a workflow? Or is that something which comes later when you build stuff and go like, okay, now I need to make it in the workflow so I can automate it?

I always think in system because it sometimes makes me do things much easier and much faster. So for example, I've been building this language app right now. I started building it for myself. So what I tend to do, I write notes on my phone of words that I want to learn in Japanese. And then once I have those notes, I want to memorize those words in Japanese, right? But the problem is right now there's a tool called Anki that allows you to add words into it and then use spaced repetition learning, which allows the words to be in your long-term memory to recall. So I wanted a way to automate that. So I started thinking about a system. I'm like, okay, how can I make it automated? And I was like, okay, I can have a copy-paste system. I can just paste the word, use OpenAI to create the flashcards, and then use the spaced repetition system, right? So each system has its own node. So I started to think about it like that. And I can see like the path of the user journey. And once I have that, I'm like, okay, so I can build a prototype very quickly because all I need is those 3 steps, you know, the page to put the words, the translation with OpenAI and the output. So I actually built this startup last weekend and then now you allow me to do all this translation and then letter by letter, add more layers and more layers. Now he has like 10 different languages and then Now you can also like have a scoring and it gives you recommendation, but it's all layers to layers.

So how much did you learn of Japanese by now?

Well, my Japanese was about like N4, N3 level, but I tend to learn a lot of words through that. I've learned maybe like since last week, probably like just 20 words because I just was just playing with it. Okay. My niece actually use it for learning Spanish. And that same day when she came over, she learned about like 10 words and I was really proud of her. Like, she says it's better than Duolingo. So I was like, that's a pretty good phrase.

Put it on your like social proof. My niece told me it's better than Duolingo.

Okay.

I love that. All right. Let's do some rapid questions, Richard. A minute or so to answer. What's the one no-code tool every AI SaaS founder should master before touching code? The one.

No-code tool, I would say something like, uh, v0, I would say would be a good one to master because then you can build your prototype really quickly. I think it will deliver a lot of value for people. Okay.

How do you decide if an idea deserves a We Can Build?

I want to make sure that, uh, that it has one single pain point that people are willing to pay for. That, uh, where I can build a feature in less than 3 steps.

Okay. What's the first thing you do if you would be launching a SaaS today?

It's deep research, really trying to put my mind in the head of the customer to really understand how they think about the problem. So I spend all my time doing that.

Did you ever cross-reference your research with an actual customer eventually to go like, oh damn, AI was on point here, or? You know, it was a little bit off.

Well, oftentimes when I interview customers, I realized that it was so on point all the time. So I got to the point where like, I really trust it now because every time when I cross-reference, it's always like right on point.

I'm scared at the same time.

I'm surprised that I knew about those problems.

Scared at the same time, it's like, man, you got your own brain. What's your go-to hosting or deployment stack for the weekend projects?

So usually I deploy it on v0, like, um, they have their own service, which is Vercel. But then once I have it on, if I build it separately on Curse or something like that, I use Netlify. So a lot of my apps are on Netlify and some other ones are on v0.

Is the Netlify because of the public link or is that some other reasons?

Because it's free. So I have so many apps and it adds up, right? I have like so many apps and Always looking for ways to save money on costs like, you know, domain as well. All right.

What's the first workflow you automate in every project?

Testing now.

Testing.

Yeah.

So when we say testing, we mean end-to-end testing or frontend testing or unit tests or like what type of tests or all the tests?

So we're talking about the Wall Street, so like unit test, end-to-end test.

Okay.

Technically, like Anything that covers how the implementation, I try to automate that right away. So I go with like test-driven development where I write the test first and I cover all of those aspects. And this is something that I've been exploring like even more recently to figure out how to better test that. And especially with AI. So it's a bit different than the regular type of testing, but very similar.

Okay. Uh, what's one AI tool? Or workflow that surprised you by working better than expected?

One that I would say, I think testing. I changed my mind on AI testing because I had, you mentioned Checkmate before. I built Checkmate because I didn't believe in AI testing. And then recently I went deeper into it and then now I'm surprised because it actually works. It's actually working like I expect.

Okay. Do you have any course or educational piece about that? Because it feels like, you know, you spend some time, we need to educate the market on that one.

Yeah, so on my blog at Blueprint Weekly, so I have my most recent post was about my founding with testing and I'm working on a video course where I'm going to explain to people how to do it.

Okay, that's excellent. What's your take? Should weekend founders think about sales on day one, effectively before they build or after validation?

I think both because sometimes when you validate, validating mean getting paid on the process. I think it depends on what startup you're working on. I don't have one rule. Sometimes I break the rules. So like, yeah.

Yeah. Okay. What's a task every founder wastes time on that you have completely automated?

Validation is one of it. Because I validate, I do a lot of my validation with AI. Um, the other thing is obviously generating the navigable prototype. So I don't do design, I don't write the front end myself. That whole process is automated for me now. So once I gave it my PRD, it's a fluent thing. And then I'm even building an app now where other people could use, where they just put the idea and I help them through the whole process. So I think that whole thing for me is fully automated.

Nice. What's one AI SaaS niche you wish more builders would explore? Basically, do you know a good niche where people can build some stuff?

Yeah, so there's a niche where you need to verify the AI confidence. So AI tend to be too confident about what it says, but you need to verify whether the AI say is true is actually true. And I call the tools that do that, I call them Speck Oracle. So Checkmate is actually doing that. And I think this is an area that people are ignoring because it's beyond hallucination. It's just making sure that the AI said what it said it did. So if you can verify that, like verifying that what AI said is actually true, I think you are tackling a niche that a lot of people are underestimating that is going to affect a lot of people in the future. For example, accounting, any field where you need to verify the claim by AI, are going to be a big deal in the future because once you can verify that, then you can have the guarantee that the result is correct, right? So anything like accounting, health sensitive data are going to require to dive into that area specifically.

Okay. If you had 100 seconds to explain your entire build system, how would that sound?

Oh, I would say Idea. So ideas first, idea researching, validating, prototyping, talking. I guess, let me think about it. So I will say the, sorry, idea, validating, uh, prototyping, then launch because I want to ship as fast as I can. And then after that, um, I would iterate the same loop again, you know, because I need to validate now the customer, uh, feedback. And then prototype the feature and launch. So that loop.

At any point in time, you would use, you know, like a marketing or like ads to push the product out, or do you look for this natural, you know, pull, which happens if you, you know, find the market fit?

That's a great question. That's something I should mention before, but I think distribution starts even before you build anything. People start distribution too late. I think you— distribution is like a long-term game. You always need to invest in distribution. And if you invest in it early, let's say you start blogging about your problem, then that's also another way to validate because people can give you, you know, feedback in terms of engagement with the problem that you're talking about, in terms of the traffic that you generate. And also once you have that audience, you can always present your product down the road. So I think distribution is a long-term game. You should always doing it. Even if you don't have a startup, you should always think about distribution.

I love that. Right. So a lot of golden nuggets, Richardson. Thanks for sharing everything. If people listening go like, damn, I want to learn more, where they can go and find you?

So on my site, richardsoncam.com, or I'm everywhere at RichardsonDX. So you can find me on X where I share a lot of my ideas and document my journey in public.

Excellent. And for everyone tuning in, I appreciate your time. Drop your questions about AI workflows. And SaaS validation in the comments and go to mastering.techroad to check out our community. And as always, guys, until the next time, stay safe and see you online.