Build less before you know more 🧪 Sophia Matveeva

This is why prototype testing before you code anything, or even before you vibe code anything, is so important. Because even if the idea is perfect, it's very, very unlikely that your first product is going to be any good, basically. What you need to do is you need to speak tech rather than do tech. So if you're a right-brained person, you're really good at talking to people, you're good at sales, you're charismatic, you're the right-brained kind of business founder. If you try to make yourself into this left-brained coder person, you will fail, basically. You should definitely learn what developers do. But if you don't have that mindset, if this is something that you find really boring and unpleasant, then you're essentially never going to make yourself be that good at it. Non-technical founders, do not sit there by yourself vibecoding your entire product for ages. What you vibecode by yourself is probably going to have lots of security issues and probably 99.9% likely to not be releasable as a commercial product. Do not think you can do the whole thing yourself.

This week's Millennial Master is Sophia Madhverba, founder of Tech for Non-Techies, who teaches business people how to understand and build with technology without becoming developers themselves. Her own experience taught her that knowing how to code isn't the same as knowing how to build a useful tech product. AI has made the building part much easier, which makes testing what people actually want even more important. In this episode, we talk about what non-technical founders actually need to understand about tech, why you should test an idea before you start building it, And where vibe coding stops being enough. Sophia, welcome to Millennial Masters. Where are you joining us from today?

I'm joining you from Dubai.

Okay, we're back in the Middle East. Before, you needed designers and proper money, and you had to bring a lot of technical people on board just to make a few screens move about, even for a mobile app. But today you can make something convincing in an afternoon with vibe coding and other online solutions. Is, in your experience, this making founders better at tech? Testing ideas because they don't spend so long in developing the first MVP or demo?

I mean, it should, but it doesn't, sadly. So it should—

To the point. I like it. Yeah.

It should because these tools are there. There's no excuse. You know, when I first started, I had to literally pay, it was £35,000 to a designer, like to go through these for 2 sprints. Now, You can basically pay $20 and create a prototype in a couple of hours, even less. So it should, but people don't do it because people either they don't know that it has to be done. So they don't, they don't know about this process. They don't know about prototype testing, or even if they do, I've seen it's basically a discipline thing because it is also an emotionally difficult process.

You know, you create something, you really believe in it and then you don't want the rejection. Yeah.

Yeah. So they should, but they don't necessarily.

So it's also easy to waste 6 months on a bad idea like that if you don't do your testing. The AI product can look super polished on screen and the founder will still not have any idea how it works in the background and might want to make a small change and it would derail the whole project or break it. Have, have you experienced that with the...

Yeah. I mean, unfortunately, we, we see this all the time. So what we often see is that non-technical founders believe wrongly that they can create the whole thing using basically vibe coding. This, for a non-technical person, is not true. Now, a developer using Claude code is very different to me and you using Claude code. Because, I mean, we've, I'm sure we've all had experiences with AI when basically the output it gives us is nonsense. I remember I asked ChatGPT to give me my bio and it just, it made things up. I mean, it was great, but it wasn't true, but it sounded very real. So we all know that AI hallucinates. Now, if you are a developer, you can spot the mistakes and you can get rid of them. If you're not a developer, you don't know whether this is good code or bad code. So our recommendation and like my very strong feeling in this, because I see founders just go down the wrong route for ages, is build the prototype, test it with 5 people, get feedback, build another prototype based on that feedback, test it again. But when you are actually ready to make a commercial thing that you're going to charge money for, that you're going to raise money for, like, a serious thing that you go out with to the market as your finished product, you need to have developers. And yes, those developers may be using tools that are also available to you, but they know what they're doing. So just because AI now exists, it doesn't mean that there's no room for proper developers.

And so you said, Sophia, you raised money, you hired developers, and then from what I've read, you realized you had no idea what they were talking about. When did that hit you?

Oh yes, this was, this was absolutely awful and it was completely unexpected. But when I look back at it, I'm like, oh, of course that would have happened. So, you know, at business school and, you know, when for the entrepreneurs listening to this podcast, you're listening to lots of shows about entrepreneurship, you're reading books, you know, you're getting inspired by people and they talk about like investors and fundraising and kind of accelerators get you to pitch to investors. And I kind of just completely ignored. Like how you actually build the thing. And so I raised money and I remember when I spoke to my first developer hire and he was talking about building the backend on Ruby on Rails. And I was just like, I don't understand these words. Like they sound like it's in English, but I have no idea what I'm supposed to say. And I was thinking, well, I'm his boss, so I'm probably supposed to give direction. Like, what am I? What am I supposed to do here? And my reaction to this was, okay, crap. I don't know what these guys are talking about. So I need to learn. And there was a lot of pressure, I think, and a lot of people, this was like 2016, that time when there are lots of, you know, people need to learn to code, go to a coding bootcamp. It was like that era.

That was meant to be the future before AI.

Yeah.

Yeah, exactly.

And I remember thinking, well, I've got this MBA, so now I have to learn to code. Like, all right, fine. Like, damn it. I don't really want to do that, but okay. And so I signed up to, I remember I did a computer science course from Stanford online. I signed up to a Python course, which I just hated. And I would do these courses and I would realize that like, I'm not, it doesn't really help me because, you know, at one point I remember I spent 3 hours coding a little blue square. into a little black square, which, you know, I'm a CEO, like I have developers, like I have investors, I have actual serious stuff to do. And there I am turning a little square into a different color. And I would go to the developers and I'll be like, look, look at my masterpiece. They were sort of like, well, what, you know, what are you going to do with this? You know, you're not going to sit here and code with us because we are doing something far more complicated. So what was the point? And I realized—

Developers like to say that, but it's not always the case, right?

Well, to be honest, this is where I actually agree with them. And this is when I realized that this whole, you know, you must learn to code, like, dictum wasn't, you know, it wasn't actually good advice. And I hustled my way into writing for Forbes magazine about my journey as a founder. And that's how I interviewed lots of people who were non-technical leading tech companies. And that's when I really realized that what you need to do is you need to speak tech rather than do tech. So if you're a right-brained person who is, you know, like you, you're really good at talking to people, you're good at sales, you're charismatic, like you are, you know, you're the right-brained kind of business founder. If you try to make yourself into this left-brained coder person, you You will fail, basically. Yes, you can learn. You should definitely learn what developers do. But if you don't have that mindset, if this is something that you find really boring and unpleasant, then you're essentially never going to make yourself be that good at it. And so if you're the business founder, you need to speak tech. So you need to learn how to work with developers, learn the language that they use, learn, learn the jargon, understand how a tech product? Like, how does an app go from idea to a scaled product? Like, what are the risks? Who's involved? Why do you need a front-end engineer and why do you need a back-end engineer? Do you, like, is a full-stack developer a good idea or not? How has AI changed what developers do? Like, you need, if you're genuinely going to be a leader in a tech business, you need to know the answers to these questions.

But Or have a technical co-founder.

No, even when you have a technical co-founder, you still need the answer to these questions. Because if you are going to be in a leadership position, if you're the CEO, you can't just be like, yeah, this thing that my entire business depends on, I have no idea what it is and I'm just leaving it to somebody else. You need to be able to collaborate with them because at the end of the day, Technology is there to create a product that solves a problem. On the business side, you really understand the problem and you know how to monetize that problem. The technology is the enabler of that. And so the ideal situation is when you can translate the business need to a tech strategy. For this, even if you have the best technical co-founder, you need to, like, you need to bring your business. knowledge, they need to bring their tech knowledge, and you need to be able to speak in a language that you both understand, which means you need to learn to speak their language and they also need to speak your language. So for all of the listeners who are like, oh, I'm a developer, I get all of this, then my advice to you would be, okay, that's wonderful. Learn the business side because basically that's when you become unstoppable.

That was one of the things that I wanted to mention. You mentioned about how a CEO should speak developer tech language, but it also, it should also be the other way around.

Yeah, absolutely. And from what I have seen is that there are essentially 2 types of developers. And yes, this is a big generalization, but it's in general, this is how the world works. There are the developers who love the actual work of engineering. And then there are developers who actually like doing the management and the strategy. And usually these are kind of different mindsets and different talents. So the person who wants to be the chief technology officer is usually the person who doesn't want to sit by themselves and just write code. They actually want to think about, okay, what are we building? How is what, you know, how is AI changing what we're going to build? How does the business vision, like how, how does my technology strategy align with the business vision? So it's a different kind of job. And so if you want to be in the C-suite as a technical person, you need to understand business. But if you don't want that, like, if you're just like, you know what, I am, let's say you're a hardware engineer, which is like the, you know, hardware developers. That's like the deepest, some of the deepest tech. If you just love doing that and you barely interact with the business side and you're really happy with that. Stick to it. I mean, you're probably not listening to this podcast, but if that's, if that's what you're into, then carry on. But if you want to be in a position where you are talking to investors, where you're talking to customers, maybe where you're actually leading the integration of your product with somebody else's, like with a bigger business, then you actually need to understand business terms and what drives business outcomes.

And we're going to get to that in a moment, but I wanted to find out, Sophia, when you started realizing that you didn't understand as much the tech side of the business, you've done your courses and your training, what was the default position you took then? Was it micromanaging by any chance?

I tried. I mean, I didn't micromanage, not because I didn't try, but just because I didn't know how to, which makes it even worse. So I was attempting to micromanage people who were doing work that I didn't Understand, which is like the worst possible thing. Like you shouldn't micromanage in the first place, but if you're going to micromanage, at least, you know, know, know what you're doing.

You can't manage what you can't understand.

Yeah. So kind of when I was first working with developers, my, essentially I was kind of going like, are we there yet? You know, like the annoying kid at the back of a car going like, are we there yet? Are we there yet? Because I was like, whoa, why, why is the backend being taken? Like, why is this? Why does this take so long? And It was really during these conversations that I learned from my developers how to work with them properly. And, you know, I learned that some things that look very simple, some things that look like a tiny change to the user actually require a lot of work on the foundational level in order to make that tiny change. And I'm actually really grateful to the developers that I was working with that they patiently explained these things to me. And I think it was because we, we had this good relationship that essentially I learned from them and they learned from me. There was this kind of curiosity, but I find that a lot of non-technical founders, we don't know what we don't know. And if you're not super lucky to work with people who are like generous and kind and supportive, then you're, you know, you might end up in a position where you end up losing your team. Because they're basically like, well, this person doesn't know what they're doing and I can't be bothered. Whereas I was like, yeah, I don't know what I'm doing. So please teach me. Which also requires, you know, you not to be like, oh yes, I'm the boss. Therefore I know everything. When you're a non-technical person and you are leading a tech company, there has to be some humility that, okay, I know my side. Like I brought in the money. I understand the problem. I understand the investors. And I understand our customers, but what you guys are doing, I don't understand. And we have to have basically like, I have respect for you and you have respect for me. And we have, and together we are building something.

When you're looking back, was there a particular area that you spent money building before you had enough evidence that people wanted it? That brings us back to the CEO side, testing your assumptions and the business problem. With potential users or customers before you start building?

I think you always have to do that. And this is one of the benefits of actually going through an accelerator program is that they literally force you to go and test customers. Then we did the Google Venture Sprint method. Essentially, it's to test your idea and get feedback from your target market within 5 days. So we at the time worked with, you know, a brilliant design agency to design a prototype and a prototype is basically like a test version of your product. It's, you know, if you're making an app, it's a bunch of screens that don't contain any information. So it's basically kind of like just static screens that are linked to each other. So they created a prototype based on what we saw in the market. And then we tested that prototype with 5 people. And this is the magic of the Google Ventures method, because once you get feedback, according to their research, feedback from only 4 people uncovers 85% of the errors in your product. So, and, but they always say, okay, get 5 because we're living in a culture where people bail. So we'll, I always recommend get 5, but generally by the time you are doing the 4th interview. You almost know what the person's going to say. And we did this twice before we created, before we actually started coding anything, because when you first create a product, even if you've already done all these market studies, even if you were already like, you already know people want it.

Mm-hmm.

When you create a product, inevitably, you know the problem quite intimately. And so you're basically creating it with this knowledge.

You know the problem quite intimately.

So you basically, you're, you're creating your own view of how this problem should be solved. And the problem with apps and websites is that you have very little, like on an app, you have very little real estate, right? Like it's a small screen. So there's, and nobody reads instructions. Like none of us read instructions for new apps, right? So. It needs to be whatever you're creating, even if there is a huge need in the market, even if, you know, even if you've discovered something that everybody sees that it's a huge pain and they're willing to pay, the likelihood that the first ever screens that you design will be comprehensible is basically low. So you might have a great idea, but you present your prototype to people and they're like, I don't get it. Or, you know, they get 50% of it and This is why prototype testing before you code anything or even before you vibe code anything is so important because even if the idea is perfect, it's very, very unlikely that your first product is going to be that, be any good basically.

But you can also easily choose 5 people to give you the initial round of feedback. And they're always going to tell you that your idea sounds good or that they would buy you. buy your service when that's not the case. You can easily be biased in your selection.

So selection is important. And so my advice is usually, you know, don't ask your friends or your parents because depending on your relationship, they might either say wonderful things or awful things, no matter what you do. So, you know, choose your target market, but also this is a really important point that you bring up, Daniel, is that You actually need to learn how to do user interviews. So if you're listening to this episode and you're like, okay, I can create a prototype with AI right now. Yes, you totally can. It's not going to take long. Like you should definitely do that. And then you're like, okay, and I know 5 people. I can just, I can just message those people. Okay, great. Do that. But before you speak to them, please learn how to do user interviews properly. And actually on the Tech for Non-Techies podcast, I have an episode on how to do this. But the general thing is that you need to be an anthropologist and not a salesperson. So like, imagine that you are going to see a tribe that lives like, I don't know, in the middle of nowhere in a rainforest, and you're an anthropologist. You are going there with no judgment. You're just going there with interest to see how do these people, you know, how do these people live? What do they do? And if you were to give them something that they've never seen before, you are just there to observe how do they react to this thing that they have never seen before. And if they say to you, what is this? What does it do? You always say, what do you think it does? And this is—

Don't give, don't feed them the information.

Yes. And this is so counterintuitive because as creators, as innovators, we want to be like, look. It's amazing. And even if we don't say it, our entire being is going like, please tell me you love it. Please tell me you love it. And most people want to be nice. You know, most people, like most of us are people pleasers. So most of us are going to be like, yeah, yeah, it's great. Sure. Yeah, I can, I can see someone using it.

So how do you know when somebody wants your product or they're just being nice?

Well, so if you learn how to do user interviews properly, you will have a much better chance of getting the truth out of people because there are questions, like there are literally questions that you need to ask them to uncover the truth. Like one of the questions is, tell me what you don't like about this product. And you need to ask them this negative question because you need to assume that there is something that they don't like and you need to make it safe for them To tell you that there's stuff that they didn't like. Another thing that you should definitely say is, I am testing the product. I'm not testing you. Because another reason why people get, you know, why interviews can kind of lead to false positives is people feel embarrassed when they don't understand how to use something. And they think—

So they don't want to look bad. Yeah.

Yeah. They think I should be getting it. And the fact that I don't understand it is because I'm stupid, not because the product is badly designed. And so when you're doing a user interview, literally repeat it several times. Don't just say it once, but repeat it throughout the process. Your feedback, your honest feedback would really help me because I am testing the product to see whether it is comprehensible, to see whether people would use it. So I'm really testing the product. I'm not testing you. And then that way, if you emphasize that They would help you by telling you what they don't understand or what doesn't resonate, then people are much more likely to actually tell you the truth.

That's an interesting point. And a lot of people skip the user interviews and the real-world testing when putting your demo or even the concept in front of somebody can easily tell you whether they want or they need that service or the solution. that the product or business is bringing will actually work. But let's say you found the product or the service that people wanted, but then how can the founder know that it can actually be turned into a business and people will pay for it? There are many things people might want, but will not pay for.

So first of all, this is definitely something that you need to work on in your user testing. So when you first create a prototype, not only are you asking, would you use it? But you should also understand willingness to pay. So in our program, we have a foundational program on tech for non-technical founders. And this is literally the process that we take them through. So yes, we help, we basically teach you how to make a prototype using AI. We teach you how to interview people. And then we also teach you how to really interpret that feedback. And what we often see, so there's this pattern that when we have young people going through the program, you know, people who are basically undergrad students. Often they want to create solutions for, you know, people like them, other undergrad students. So what do undergrad students not have? Money, usually. So we often see that people who are at college are creating solutions that all of their friends would use, would be really popular at the university, but that have absolutely no business potential. So we often see that and It's a really good idea for them to understand this at the beginning. We've often seen founders saying, oh yeah, yeah, people would use this. We found out nobody will be willing to pay. Okay, now we need to pivot the business model. Now we need to figure out, can we get corporates involved? You know, maybe the idea is just never going to work. Maybe they understand why, you know, they think, oh, this app really should exist and everybody agrees. And then they understand, okay, this is why it doesn't exist because The use case is there, but the business case is not. So you can actually, you often can just get, get this info right at the beginning, but also it's not 100% foolproof, which is, as you know, Daniel, entrepreneurship is risky, right? It's a kind of high risk, high reward space.

It's all about risk.

Yeah. So yes, my aim is to help people de-risk as much as possible. So test as much as possible. You know, don't spend your life testing because you actually need to create things, but test to de-risk. But at some point you do just have to be like, okay, you know what, we've done the prototype testing, we've done the user testing, we have to release this product. Yes, what we have is a hypothesis and yes, it is possible that it won't work, but we've done enough testing to believe that it will. So let's give it a go and see what happens.

But how do you then challenge your technical team without pretending that you know how to do their job? Sometimes they can be very relaxed with the timing. And even in my experience, we'll say things take way longer than you would expect them to be, or an external consultant or developer will tell you, actually, no, this is not 6 months, it's 6 weeks worth of work.

So first of all, MVP, so minimum viable product, your first version is always going to be later than you thought. So the timeline that developers give you is always going to be more optimistic than it should be. So if you have delays in your product, it's very annoying, but I have literally never seen a product ever released in time. That's number one. Number 2, the assumption The assumption in your question is like, how do I challenge them? It sounds like it's a bit of an adversarial relationship. And so if you're going to have a colleague in any field with whom you have an adversarial relationship, that relationship is not going to yield good results in general, right? So the first thing is actually not technical is find people whom you trust, who you believe are doing their best, and whom you fundamentally trust. If your spidey sense is telling you that, I don't like this, like if you're just like, if you're getting that feeling, trust the feeling because there'll be somebody else who you don't have that feeling with.

That might be already too late in the process. You might've hired your developers already. You don't know that.

So if you did that, then you need to understand why things are taking what they're taking. So literally say to them, why, why wasn't this feature released? So essentially, why did you give me this estimate, but now you're giving me this other estimate? That means some piece of news must have happened. So either you estimated it badly, which happens, like either you basically were just completely wrong, which happens sometimes, but most often when it's kind of like you're, imagine you're You are renovating your house. So builders give you one quote and one set of times, but then they start like opening up the tiles in your bathroom. And then they discover that there's a, I don't know, a hole in the wall. And there's like, there's some, something rotting that, I mean, we've all been in these situations. And then all of a sudden they say, okay, unless we do something to this wall, the entire house is going to collapse. And thank God we found this out. And all of a sudden, The timeline and the cost completely moves, right? Like we've all been in this situation. The same thing happens with developers too. They start doing something, especially if it's an existing product, like if you're creating new features for an existing thing, then they start doing something, then they realize—

They will always blame the old code or whoever built the first part.

Yeah. Or to be fair, if you are building something completely new, You don't know exactly what it's going to be like. There's time pressure because you're like, we told investors we would release in Q1 and it's like the end of Q1. And you were just like, okay, let's just release.

Time pressure, runway.

Yeah, exactly. Like, let's release this half-baked thing. And then you release the half-baked thing, you raise more money, and then you're like, okay, we're building new features, but our foundation is like Really shaky because when we had no money, we just had to release something to get the next funding round. So this kind of stuff happens. And the way I'm explaining it to you, it's very comprehensible. Like we can all understand it, especially in like the building context. So when you speak to developers, basically ask them, why, why is the current timeline so different to what we expected? Did something come up? How could we tell? Like, could we, could we have foreseen? That this was going to come up. If you are really not getting anywhere and they're not trying to explain anything to you, get an external pair of eyes. Like you don't need to buy another—

And that's when it becomes complicated. Yes.

Well, so you could literally not necessarily get another developer to redo the thing, but get somebody who's literally just going to review what they've created and review what they say about where they're getting stuck. Because maybe they're getting stuck for a very legitimate reason, but they don't know how to explain it to you. And because they don't know how to explain it to you, it looks dodgy. Or maybe it really is dodgy and they're basically, you know, making silly decisions because they don't know what you're doing.

So what's then a question you ask developers now that the Sophia who started her first company wouldn't have even known to ask?

So I ask, so. I asked about what the estimates are going to be for specific things. And I asked about trade-offs. So let's, I'll give you an example. In, we had a consumer app and in this consumer app, our users, lots of users said that they want to have a video feature. And, you know, I came back to the developers and I said, guys, let's have this video feature. And I'm really grateful to, for what my CTO said. He said, well, we can make this feature. But it would mean that the team is only working on this for about 6 months. And are you happy with this? Because this is going to take a lot of time and a lot of changes for like that you don't see. If you believe that it is worth it, then we'll do that. But you need to know that everything else is going to be on hold. And that was a really useful conversation because that made me realize that like, yeah, this feature is more of a nice to have. And these other things are much more important. And, you know, let's park that until we raise more money and we can have a team dedicated to this specifically. So what I would recommend to people is prioritize. So go to your developers with a list of things that you want. And for yourself, understand why you want them. Do you want them because they'll help you raise money, that they'll help you retain users, they'll help you make more money, or is it just because it's like quite cool and quite fun? And you know, if it's cool and fun, that's a legitimate reason, but just be honest with yourself. Go to them with your list and say, look, these are the things. What is low-hanging fruit here? Like, what can you do in a week? And what is difficult? Because if you end up in a situation that 3 of your things can be done in 2 weeks, and they're actually the things that are going to help you monetize or help you grow most, obviously focus on those. So what I'd recommend to founders is bring your features, prioritize them, and then have that trade-off conversations with your developers and that trade-off conversations. That's really where you are, where business and tech are working together in a perfect symbiosis.

So I want to ask Sophia, what happened to NT? Because the public story gets quite detailed through the building and growth years and then a bit quiet.

So I shut that company down during COVID So I'll tell you what the company did to give you more context. So essentially we had a consumer app where users, primarily women, could take photos of stuff that they wanted to wear or stuff that they wanted to buy and get feedback from professional stylists and the community. And it was really clever because essentially you could take a photo, but the only people who could write comments were professional stylists that we had vetted. So, you know, if you were basically, if you looked terrible, you would never get in Trolling, but you could also get votes from the community. So people could say yes or no, like yes, buy this bag or no, don't buy this bag. Or we could have voting. So you could put up 2 photos and say, okay, here's this dress with these shoes. Yeah. And we were the only product that went behind the, behind the dressing room curtain. This was solving a huge problem for retailers because retailers and brands can market to you and they can understand your behavior basically everywhere apart from the dressing room. The dressing room is like, that's the private bit.

So retail was your main potential customer. So that happened at a time when retail was not being able to function. In that tradition.

Not only that is that, so we had user revenue, we had B2C revenue and B2B revenue, but our users, you know, think about when, when is it that you want to look really nice? We found out that it's, yeah. And we found out that it's basically to do with sex and money. So when, when women were getting ready to go on dates or parties or, you know, anywhere that Like there'll be an opportunity to like maybe meet somebody. They wanted to look nice. Or when it was a work event, like a job interview, an important presentation, a client, like a big client meeting. And during COVID like everybody was sitting at home in their leggings, like crying into a bottle of wine. So our usage completely went down and our retailers also, you know, they didn't need consumer insights because they were like, well, we know what our users are doing. Everybody's sitting at home.

So in up to 10 words, say, what did you learn from that experience that directly changed how you built tech for non-techies?

10 words is I don't have investors anymore.

Yes. Well, that's my next question because you raise money for one company and then bootstrap the next. So which experience changed you more as a founder? We all learned the lessons.

Look, my view is that some companies just require funding. Like you, like DeepMind, you know, you couldn't, you couldn't build these models with like without deep, without great funding. So it's good for them that now they are part of Alphabet that has infinite amounts of cash. But throughout my entrepreneurial journey, I have seen founders create big scalable businesses that look like they got VC funding, but when you actually dig deep, they didn't get VC funding. And that, I would say, is the harder path because, you know, funding is like gasoline, right? Or like fertilizer for plants. Like it just makes everything grow. When you are not, when you don't have it, you basically have to hustle more and there is more stress. But then you decide what's more stressful. Is it more stressful to have investors who are like, Constantly ask me questions that maybe you don't have answers to yourself. And you're like, I don't know. I don't know how we're going to figure this out, but we're here now. No, I'm not saying that I'll never take money, but my view is that if you don't, my personal view is that if you don't have to, or if you don't see an investor who, you know, you adore, like if Richard Branson said to me, hey, I love what you're doing. Can I invest? I'd be like, absolutely. Don't even care about the valuation. But if you're raising, like, basically don't think that you have to raise money in order to build a large scalable business. You really don't.

When do you think a founder should stop putting their own money into something they still believe in? That's something that I have lived through as well. You can have hope and belief in your product right until the end, but when you look back, you know, there were signs. And points where you should have looked at it differently. So I'm hoping you can spell it out for me, especially in this bootstrapped scenario.

Well, so the question is, are you making money? So if you are making money and you already have a track record of like that product is making money or that service is making money, and there hasn't been a major exogenous event like COVID that has just completely shut everything down. Maybe you have a dry spell, but every business goes through a dry spell. Like if it's a dry spell because I don't know, it's summer or it's just kind of a random 3 months where you're not signing any clients, that's normal. But if you already have proof that people are paying for this thing, they're paying above what it takes you to make it and nothing in the business, nothing in the economy, nothing in the world has changed to basically change demand, which is tricky nowadays. It is, but I'm talking about big exogenous events like, you know, COVID or the Iran war. Like, yes, it is tricky. It is tricky because we're having more of these exogenous events, but they're very obvious. Like you can really tell, or, you know, maybe it's a huge change in regulation. Like when Trump came in, a lot of DAI consultancies basically had to completely pivot. Because, you know, the government, the government decided they had a different policy. But if you, if you don't have like this big exogenous shift and you're just having a dry spell, you know, sometimes you have to just do what you need to do to survive. And that means, you know, maybe you're taking a loan, maybe you're putting in your own money.

And say you've gone past through all of these and you actually built a generally better product. But you've said that you can build something better and still lose. So how much better does something have to be before a customer will actually bother changing what they already use and having that friction before they get something better? Very rarely you'll be the first to a solution to a particular problem nowadays when a lot of things have been done.

Well, So the sad news is that you can have a really good product that is still brilliant and still lose. So I don't actually think it's about just improving the product. Like the examples that we can think of is Spotify versus Apple Music. You know, a lot of people actually think that Spotify is a better product, but Apple Music is part, you know, you're in the ecosystem. Another example is Snap, so Snapchat versus Instagram. So Snap as a company is much more creative. And so basically, you know, the Meta teams steal Snap's ideas.

They've always done that.

They've all, yeah, they've always done that and they will always do that. Now, where are the users in general? They're in Meta, not in Snap. And it's not because like Snapchat is new, right? Like Evan Spiegel could have said, could, it could have been believable. I don't know, 5 years ago, just when you were saying like, we're still new. Now it's, it's very clear that it's probably never going to catch up. And it's not because their product isn't better. They have a more creative team. They come up with innovations that everybody else rips off, but the company, like there's the product and the company, right? Meta, the company is a better company. I'm not saying like morally better, but better in terms, like just from a business sense. They have more users, they have much more money. And so essentially they are much more likely to win. Like I wouldn't want to go up against Meta. I think TikTok are the only people who could win.

So what are the chances then of creating a better product and still losing? Is that 30/70 or is it the old 50/50? It's not a roll of the coin, is it?

It depends on the industry because for example, look at enterprise sales. There've been, there's been a lot of unhappiness amongst founders who are now creating AI solutions, you know, that would like replace SAP or replace Oracle in big companies. And the mistake that they make is that I have a better product. It is cheaper and it solves the problem better. So you should switch to me and they ignore the fact that This, in this old company is entrenched with the client.

People have done training courses to learn SAP, to run, to work in that business. Yeah.

And so unseating SAP, even if you have something that is basically magical, I don't know how, like, I don't want to say it's impossible, but it's going to be really, really difficult. And so this is why often, you know, for the people who are working in large companies, you're often using software and you're thinking, oh, this is terrible. Like, Why? Now you know the answer that the business is not just about the product. It's about the sales. It's about the relationships. It's about all the investment that the client has already made in training the team. And so if they were to switch, it would have to be something incredibly, incredibly compelling.

What have you completely changed your mind about since you built your first tech company? And that was before the AI era. Versus how it will work now. And then what mistake do you see these non-technical founders making now that reminds you of your mistakes 10 years ago?

To be fair, it was much more complicated and much more expensive. So I used to believe, and because it was true, that you really, you needed to either have a technical co-founder or to raise money to basically pay developers from the word go. Now, I still believe that you do need to pay developers, but not as early as you used to. Because now you can actually, as I said, create a prototype, test it and test it enough and create enough of a kind of a fairly big test product that when you go to investors, you say, look, I've tested it with the target market. I've tested different facets of it. I've tested willingness to pay. And everything looks good. Now I need to hire, you know, instead of a development team, I need to hire one developer. You know, I need to have one person who is going to use Claude code to create something that is fairly simple, you know, whereas before you would have needed to raise money to get a whole team. Now you are still going to need a whole team in the age of AI, but you're just going to need it later. So the general rule is you still need all the stuff, but you need it later. And because you need a big team to push that product out.

So you can validate your idea and have an MVP out earlier, but once you're going through your scaling part, that's when you need to bring in the developers rather than from day one. So there's less risk in the early days.

Yeah, less risk from the early days. And even when you do actually start hiring developers, you don't need the whole army from the word go. You might. You know, I've seen startups get away with one fractional developer, you know, one part-time person who is basically using Claude Code or using AI to build them a product. And because they're not working that much, you're not paying that much. And so you can scale up much more, basically slowly.

So linked to that then, is there a mistake you see these non-technical founders continue making? Yes. That is, which one?

Non-technical founders. Do not sit there by yourself, white coding your entire product for ages, because what you white code by yourself is probably going to have lots of security issues and probably like 99.9% likely to not be releasable as a commercial product. So when you want to—

That's your demo, not your final product.

Exactly. Do not think you can do the whole thing yourself.

So then one final question, Sophia. If it's so much cheaper and quicker to build a product or a service, especially tech and software, the hard part has not stopped there. It's reaching your potential customers. And there, there has been no AI and no development that would help you get people's attention quicker. Once you help people through this build stage, what's your Advice for the next step?

Well, look, there is AI to help you reach people quicker, but Mark Zuckerberg charges you a lot of money for it. So the problem, you know, now there's more competition on the product, on the invention side, which means that essentially there are more people trying to reach consumers or more people trying to reach businesses. Who does that benefit? That benefits the tech platforms. Right. So, I mean, honestly, Meta's algorithms are super, super excellent. Like advertising on Meta has recently got so much better. Targeting has really got much better, but it ain't free. So the, the competition now I would say is in marketing and brand building and in sales. That's, I mean, it was always there, but I think it's even more difficult to win that fight now just because there are many more entrants.

Thank you so much, Sophia, for sharing all these insights. A lot of people, even if they have a tech background, they still forget about testing and validating with users and getting something out there and speaking to people before it actually goes public. So I think that will be my main takeaway from this episode.

Thank you, Daniel. It has been a pleasure.

Thanks for tuning in all the way to the end of this episode. If you enjoyed it, please share it with someone you think would get value from it. And don't forget to subscribe on YouTube, Spotify, or Apple Podcasts so you never miss an episode. For the best way to stay in the loop, head to millennialmasters.net. That's where you'll get all the latest features and new episodes straight to your inbox every week. Catch you next week.