Transcription
Okay, Tim, so do you think AI will replace programmers?
No, but I do think people that know how to use AI will replace those programmers that don't. Okay, can you elaborate?
Yeah, I mean if you're learning to program now and you're not utilizing AI at all, like I mean you've seen it, for example, you're building your entire startup, you're not even a professional software engineer, you learned to code for maybe a few months, and now you have a full app, you're making money from it, you have tons of users because you're fully locked in on AI, like even further than I'm using it as a professional Dev. So if you're not keeping up with this and utilizing these tools, then honestly, you're just screwed going forward. Like you have to adapt to it and you have to learn it as fast as possible.
But why do you think there's so many traditional developers that are refusing to use AI?
I think that's like any field, right? Everyone's always a little bit resistant to change, especially when it means you have to learn something new, you have to grow, you have to get better and better, you have to get out of the kind of traditional norms or patterns that you're used to. And if you've been coding for 20 plus years, you've already gone through so much change, and the change now, it's just so insanely rapid that you're going to try to resist it as much as you can. I mean, even for me, for the first bit, I sto—I didn't even want to use AI, and then like I have to use this thing; if I don't, I'm just going to get left in the dust, right?
So two years from now, do you think there will be more developers than is today or less?
I would lean towards more, but I think in a very different way than we view developers today. There's going to be a lot of people utilizing these AI models. You're going to have people like you who are just learning AI as opposed to purely learning coding, and I think there's going to be a lot of jobs around that and a lot of kind of low-code, no-code type developers as opposed to pure, you know, sitting down writing tens of thousands of lines of code a week.
Yeah, I guess the value of that is decreasing, right?
Exactly. Yeah, and I was actually just at a Salesforce conference the other day, and what I saw there is like there's a lot of people that are developers but not in the traditional sense. They're building using all of these tools that companies are coming out with, but they're not really sitting there writing line by line. They don't even necessarily know how to do that, and they're still extremely productive. But you've got to adapt, and you've got to learn these new tools, right? If you just stick with pure, you know, writing lines of code, no AI assistance, nothing like that, I mean, in a few years, that's going to be obsolete, I would say.
I want to touch on one thing you said: that your immediate reaction was kind of negative, or like, "Oh," yeah. I think a lot of developers have the same. But how did you overcome that?
Yeah, I think it's just kind of waking up and just facing the reality, right? Like as much as we might not like it, it just is what it is. And if I think back, I mean, I've only—I'm, you know, 24, I've been developing 10 plus years, and I even think of how development has changed in that time period. I've had to constantly learn new things, constantly adapt, not at the same pace as now, but it's been like that forever. It's just now the innovation is going so quickly. A lot of people that aren't kind of quick learners or quick to adapt, you know, that's why they're—they're falling behind. So I think that's the negative reaction because they just have to learn so quickly, and it's constantly changing week by week, right?
I guess that's like any technology in history, right? There were certain countries that banned the printing press when it came out, but obviously that was a bad decision. I guess for people watching this who have that negative reaction, I would say like, either you do a bit of discomfort today or a lot later on, right?
100%. And like, way more than a lot, you know what I mean? Like you're just going to be completely displaced at that point or or moved—moved into another field. You're going to have to use AI; it's just a matter of how you use it and how quickly you can learn it, right?
So let's say like two, three years from now, what do you think like a typical interview will look like at a company? Do you think like they'll just give them a laptop and like build something?
I think there'll be way more emphasis on like high-level problem-solving, system design, um, some of the concepts that AI is not as good at—maybe it will get better at in the future—but I think it's more so like, we give you this problem, how would you go about building it, whether that's using AI, whether that's using this or that tool, rather than your traditional LeetCode style interview now. I mean, already that's getting like, let's call it deprecated. Some companies are still using it, but a lot of companies are realizing this just isn't valuable, and forcing people to memorize, you know, LeetCode style questions for three months before the interview just doesn't determine whether or not they're going to be a good developer.
I mean, this reminds me of like the type of people at school, right, that, let's say math, they just memorized 200 different math problems instead of actually learning how it works. I think in developers, there's a lot of those same people that want to brute-force it instead of like actually learn the underlying concept and learning how to solve problems.
100%, especially coming out of things like computer science CS programs, right? Most students, I mean, especially if you've gone through the whole traditional education system like—like it was in Canada and probably many other First World countries, you're just used to playing the game of school, passing the test, getting past the exam. You can learn all of the theory, you know, data structures and algorithms, so when it comes to actually building something and sitting down and creating something from scratch, so many students are just completely lost. So I think that's really what's going to be tested more and more. And personally, I have like a small mentorship group, I have some students in there, and that's the number one thing I see lacking: is that real-world problem-solving ability. They're all really good at the theory; they have crazy high GPAs, but they just can't actually build something.
Right, real quick, I have to tell you about the new feature we added to Vect AI called Infinite Thinking 2.0. This is an advanced AI agent that you can give an objective to, and it will autonomously start working on it. Let me show you. Help me design and launch a Facebook ad campaign. It will start by creating a plan of action, and then it will autonomously start working on that plan by itself, and if you enable Yola mode, it will even take the actions by themselves, such as create tasks, browse the web, updating tasks, updating user context. It can do a lot. So if you want to have access to Infinite Thinking 2.0, as well as the world's most powerful AI productivity tool, go to v.ai and give it a shot. And the best part is you can get started completely for free, so go to vl.a.
What's the difference between the, you know, average student and the ones that like pick it up and go get a six-figure job?
Yeah, I think the ones that pick it up really quickly, like they just adapt so insanely fast, right? They can learn on their own; they can go out there, and they can problem-solve. If they run into a roadblock or mistake or an error, it doesn't stop them in their tracks; it's like more of a reason to keep going. Like they're—they're stubborn, is what I would say, whereas the ones that kind of get stuck, it's like they run into any kind of roadblock, any kind of issue, they don't have that initiative to go forward and fix it themselves, and they need that hand-holding, right? They need even someone like me or their teacher or their friend to tell them what to do. They don't kind of go out of their way to solve it.
That makes sense. Yeah, I think initiative is the like one of the most important traits, right? Because with AI, there is like less and less what you can't build, right? Maybe like you cannot design a new kernel yet, right? But like 95% of software you can build, and each year it's more and more. So like let's speak on that initiative: do you think people can become more agentic, or is it like—like an inherent trait?
I would say so, but I think again it comes with practice, right? Like you need to just do it a ton. People forget that the only way you get good at something like software engineering or programming or even using AI is just going through the motions like hundreds upon hundreds, if not thousands of times. Like you yourself say you have, you know, 600 plus hours in Cursor. I'm sure those first 50 hours are not the most productive; you're not getting much stuff done. Most people never even get to that 50-hour mark, right? So you need to really persevere and put in the hours. And if you think of it, 50 hours, 100 hours, 150 hours, most people have like a thousand hours in Counter-Strike or something, right? Like imagine you applied that to a real-world skill. Like both of us have—what could you actually do? Uh, and that's personally how I started thinking about it when I really dove deep into development back in University. Rather than playing Fortnite, you know, I'm going to focus on coding, and here we are.
Yeah, but even like the first 20 hours, right? Like people who are only the AI coders, even if they put 20 hours into Next.js, Python, whatever, those first 20 hours, I think there's so much perceived friction, right? But when you actually do it, it's like, oh, it wasn't that bad.
100%, especially if you don't—if you know you're not going to need to write all of it completely from scratch, and you're more focused on how do I take this and apply it immediately to my project. If you can go into these type of tutorials or guides with, "Hey, I want to build this type of app," I'm learning it for this reason, you learn it a lot better, right? And you kind of grasp all the important piece of information that you're actually going to immediately apply, which is—I mean, I'm sure how you've kind of built your startup, right? You only learn something when you actually need to immediately use it in the project. I mean, that's all the coding I did in my life. Like I never just did like, "Oh, I want to do—land the high-paying job," right? Or like something random. It was like, "I want to build this; it requires code. I'm going to learn C. I'm going to learn, you know, Java to Minecraft plugins," like whatever I was building, I learned that to solve a problem. I think that's a big difference. I think maybe you would have a different advice, but I would say like if someone wants to get started, choose a project and like build that.
100%. I think if you're starting completely from no knowledge at all, it's probably helpful to go through some kind of guide or at least get like a lay of the land, like some initial context. Like you hardly know to use your computer, which I think a lot of us take for granted, should probably know how to like navigate an editor, like open a file or run something. But beyond that, again, like you said, those first 5, 10, maybe 20 hours, then it's like, okay, I need to build this thing. Let me go learn this specifically so I can use it immediately to build this project, and that's how you learn the best. And that's why a computer science degree typically fails most students because you don't do that at all.
Okay, so in 2025, would you—if someone is like exiting high school, would you tell them if they want to be in software, right? Go to college or no?
I think it depends. If you're not going to go into hundreds of thousands of dollars of debt, if you don't live in the US, for example, if you have free school, I'd say you might as well do it. But the one thing you have to remember is whether you do the degree or not, you're going to have to learn a ton of stuff outside of school. So if you do do the degree, it can help you, like you can get a lot of really important theory down that will make you a better developer objectively, but only if you do that additional work outside of school and you build projects, and when you come out you actually know what you're doing. I personally dropped out of my computer science degree because I got what I found was, you know, 90% of the important information in the first two and a half years. I'd already landed a job, and then I was like, okay, let me just build stuff. That's the next step. And also, I think like people undervalue the education you get in the job, right? Now I'm hiring developers; I would much rather hire somebody who has been working four years in startups instead of four years in school, right? Because that person knows like, okay, production is down, we need to lock in, we need to fix it, right? Person knows how to use Git. So many CS grads don't even know how to use Git.
Tell me about a man—I know it's crazy. There's a certain type of people who just don't take that much initiative or aren't going to do it on their own. So if you know, like maybe you're a little bit lazier or you really need like a super solid curriculum and structure, then maybe that's a reason to do a computer science degree, to force you to learn these type of things. Not that many people are capable of just like loading up their laptop and creating themselves this, you know, 12-month road map and learning how to code and, you know, learning AI agents and all these types of things. So that's where a computer science degree can be helpful, but if you know that you have—you're kind of a self-starter, like you'll go do it anyways, then I don't see really much value in doing the CompSci degree if you don't need that structure, right?
Yeah, I think the reason why there's so many like unemployed computer science grads is like they got into software for the wrong reason, right? This—like the last two decades was everybody like, "Become a programmer," and they think like, okay, I'm just going to go four or five years, and then I'm going to get like a 300K job guaranteed, and they just think like, okay, it's coding, it's easy, and they don't do that extra work that you describe. And I want to touch on the most valuable skill, which I would say is for the future: ability to learn fast, right? If people think that the last two years or even like the last year in AI was fast, they—they have no idea what's coming.
Absolutely, man. I mean, even sometimes I watch some videos on your channel; I'm like, dude, how do you know this already? Like this came out like six—six hours ago. Like I feel like I'm behind sometimes even though I'm, you know, more of like a senior developer. So absolutely. I mean, I think it's always been the case if you're a software developer that you need to learn quickly, but when you're on the cutting edge of technology and you're building things like the AI tools that other developers are using, which is kind of ironic, you got to be even further than everyone else, right? Even if you're a nurse today or an accountant, like you still need to adapt really quickly, faster than you ever have before, but it's a whole another level when you're a software developer, and again, like you're on the bleeding edge of technology where you're seeing things change literally day by day. That's where the money is, you know? It's not like people can learn like a 5-year-old framework, 100% expect a seven-figure salary. That, you know, the value is like solving the novel problems that nobody yet solved.
For sure. I would also say, I mean, there is definitely demand for like legacy programmers in certain situations where, you know, you know, the government, for example, isn't adopting AI agents in, you know, two weeks, right? So there are companies that still need, you know, your traditional software Dev, but that doesn't mean that you can't still level up your skills by learning all of the new stuff, right?
Okay, so for people watching this who say like, okay, I'm a bit behind, you know, they feel like, okay, I need to learn more, what would you recommend them?
Yeah, I would say first of all, just like stay up to date and stay in tune, whether that's following a channel like yours or newsletters or just kind of scanning and just like, you know, seeing what's actually out there rather than being scared of it and, you know, tuning out and just sticking with your normal 9 to 5. Like you have to track at least what's going on at minimum. And I think once you start doing that, that's just going to give you that push internally to try to mess with these new frameworks, learn these new things. Like we said, most of these new things coming out, you can learn them and start using them in minutes, right? It doesn't take tens upon hours to learn these different things. As someone who teaches software engineering online, it doesn't take me 30 hours to learn a new framework before I teach it online, right? And you know, mess around, have some fun with software engineering. Like one of the best things you can do is just work on fun projects that have no practical use case that are just enjoyable, right? And that's how you kind of, you know, keep that passion alive. I would probably start with like, you know, your basic programming fundamentals, even though you might not necessarily need to replicate those, you know, line by line, just to get some underlying context. So watching, you know, like a 5-hour tutorial series, you know, chopping it up, 30 minutes watching, 30 minutes kind of playing around, uh, and then once you get at least some fundamentals and you're like, okay, I can at least kind of read the code, I understand this language. In this new world, it's time to just jump into AI tools and use those like as your personalized tutor. Um, I personally love just going on ChatGPT or Claude or something like that and asking it, you know, "Make me a roadmap for the next five hours on like how I should learn this," or "Give me some exercises or some quizzes so I can practice or validate my knowledge." Like really utilize those tools, especially again if you're just kind of a hobby programmer, and pick something that you want to build and start focusing energy on doing that. Now, if you're more serious, then I would definitely recommend, you know, go through a structured program or a course or, you know, spend a lot more effort kind of develop a road map, even if you want to do this completely self-taught for free. But as just a hobby programmer, that's probably where I would go.
Yeah, for sure. I think uh, for—for the hobby, right? For the beginners, AI can solve the blank page problem. Like a lot of writers face this issue where you have a blank page, right? Whether it's Google Doc or actual piece of paper, and you don't know how to start, right? With anything you want to learn, AI is the best at this. Like let's say you're learning math, and you're sitting with a tutor, right? You ask him—"I don't understand this." You ask him a second time. There is that human pressure that you will not ask three, four, five times. ChatGPT, Claude, whatever, you can ask it 100 times; it doesn't care. It will answer each time, and it will explain it specifically to you, different analogy, you know, "Explain like I'm 5 years old," whatever. So I think learning is actually one of the best things people should do with AI.
100%, but again, like you have to take the initiative to even ask the question, right? So for us, maybe it seems easy, but so many people just won't even go that far. But like, just open up a browser tab, have it as a bookmark, leave it in the background, pay, you know, 20 bucks a month, whatever, for these Pro subscriptions. They are absolutely worth it, and don't be afraid to ask it as many things as you possibly can. You can even ask it how you should ask it a question, you know what I mean? Get it to teach you how to use it. And if you do that, you'll see like so many tasks on your day-to-day life, even writing emails, things like that, you can just outsource to these AI models, and they handle specifically like, you know, really specific, well-defined tasks extremely well. It's more the vague stuff that, you know, maybe they can lead you in the wrong direction.
It's funny you mentioned this, like even sending the first prompt, and even before that, going to ChatGPT, Claude, or whatever, right? This is—so many people don't even get there because they have that perceived like friction that it will be so difficult. And when I was last year in Vietnam with one of my friends who's a successful guy, like he's an entrepreneur making six figures a month, and you would think like it—it is like just the beginners that, you know, don't—don't have that.
Sure, no, most people, even like the successful ones, even the business owners, they have that like new-thing friction, you know? When something is new, they have that like old perceived, "Oh my God, it's going to be like two hours to set up," like, no, everybody watching this can go to ChatGPT, Claude, Perplexity, whatever, and get an account within like two minutes.
For sure, and even start on the free plan. It's like all the apps have great free plans, right? But like just choosing one, paying 20 a month, that already will get you so much farther than all the people who lack the initiative.
Yeah, for sure. I mean, people don't like change, right? Like humans just love to stay in kind of their natural habitat; they love to just keep the same habits and routine. I mean, that's how we're designed, right? So as soon as you start throwing out all these AI tools, you say, "Hey, by the way, we're going to completely change your workflow, and now first you're going to go do this thing every single day," uh, you know, it's hard to adjust to. It's only if you've used it a few times and you immediately see the value, like I know you have and I have, then it allows you to kind of make that mental shift and go, "Okay, I'm going to start using AI and outsourcing." I don't know about you, but I use it like hours every single day for literally anything that I can think of. I hardly even Google search anymore. I have some like pain, or I think I'm sick or something, where do I go first? ChatGPT. It's just a way faster way to get information; it's not always correct, but it's, you know, a similar um, accuracy as you would get from Google, just significantly faster. So you can really take advantage of this even outside of coding.
Yeah, people always say like, "Oh my God, it's hallucinating," but like Google isn't always correct either, right?
So 100%. Real quick, if you want to start your own AI business, make sure to join the New Society in the classroom. We have modules on how to build an AI startup, how to build your first AI agents, advanced AI tutorials, copy-pasteable templates and presets. For example, this AI startup module contains the exact way I built my own startup, Vectal, to making five figures a month from day one, choosing the idea, starting the project in Cursor, building the backend in Python to all the way to today. Here's another example: the templates and preset section in here, you can find all of my prompts and instructions, all the AI agents I've built in my videos, as well as the code and copy-pasteable pre-built automations you can deploy yourself, and much, much more. So if you're interested in all of that, as well as a community of over 700 people at the cutting edge of AI, make sure to join the New Society. The link is going to be below the video.
Now you mentioned humans don't like change, right? I absolutely agree, but if you think like historically or evolutionarily, why the human species succeeded: it is the ability to adapt, right? We adapt more and faster than any other animal on the planet.
I guess that's like a positive thing that people should remind themselves, like, no matter how difficult the next, you know, the transition to the post-AGI world will be, humans are excellent at adapting.
For sure, and we've seen that, like you said, throughout human history. I mean, that's why we exist today, right? And even you think about some crazy times that have happened in the last few years, I won't name the exact situation, but think about how quickly we adapted to that, right? You go from, you know, living outside, seeing all of your friends, to within two weeks you're just completely used to this new world that's existed, and then same thing, you know, progress a few years, and all of a sudden this thing's gone, and again, we adapt insanely fast. I think about times in my life where I've gone from like a broke University student to now making a bunch of money online, and that adaptation is so insanely fast, like it's within the matter of weeks or days, right? So you can do that with AI and with learning as well. Uh, it just seems intimidating at first, but once you start using it, it's—it's a no-brainer.
Yeah, it's funny that like people who aren't there, they would think like you feel great all the time, and it's like, "Oh my God, this money is—" Like, no, you adapt so quickly; it's like the normal resets, right? It's like if someone is broke, doesn't have a car, buys a car, within a month it's like, "I have a car," it's completely normal. The level of happiness or fulfillment is like exactly the same. That's literally what just happened to me as well, you know? I just got a new car, and same thing, it's like now I'm like, okay, it's fun, but like it's a novelty after, you know, the first month, and you hearing the noises and all that kind of stuff. But what you're referring to is just that human baseline, right? Like humans are designed to be at a certain baseline when it comes to, you know, kind of dopamine and happiness and all those things, and you can spike it up and down, but naturally you're always going to return to that baseline whether you're super broke or super rich or learning really fast or falling behind, uh, and it's a really interesting phenomenon, especially when you see a lot of change happen in your own life, and then you realize that you feel pretty much the exact same way you did, you know, X weeks, years ago when you had that—when you didn't have that perceived accomplishment.
I guess that's why like voluntarily doing the hard things every single day matters so much, right? Because like if you put yourself through a tough workout or 60 minutes learning a new programming language you don't know anything about, after that like you put yourself down, and you will be happier or like more fulfilled, whatever your baseline will be higher because you voluntarily took the hard path, right? And I think in the people like your students, people who want to learn programming, a lot of them just want to do the easy stuff, right? There is the concept of vibe coding, right? Personally, I would consider myself a vibe coder, using Cursor, just describing in plain English to build software. However, a lot of the vibe coders get stuck at this exact point. Like any sense of friction, the first error that Cursor or Claude cannot solve, it's like over, and they quit. So I think like this is probably one of the biggest habits or like the biggest mental shift people need to make is that when something is hard is actually not bad; it's actually good.
100%, and I mean that is like kind of the definition of a programmer that you just gave realistically: solving problems, running into bugs as a programmer, like, you know, especially now with AI, we can just sit there and literally watch the AI model write code when we actually need to step in and use our—
Skills are tested when a bug happens, or when an error happens, which is very common, especially once you get into larger-scale software. So, if you do actually want to be a software engineer—as frustrating as that can be, and I’ve thrown my fair share of monitors and keyboards across the room when I was younger and getting started—that’s what really levels you up. That’s what brings you to the next level, and that’s where you learn the most. When you run into that frustrating bug that takes you a day to solve, even when you’re using AI models, and you eventually find the solution—through my 12-plus years coding now, I can’t tell you the number of times that’s happened. And also, the number of bugs, even from 6, 7, 8 years ago, I still remember the exact solution because of how intense it was and how frustrating it was. I will never forget that particular thing because of how much effort I put into solving it. So that is a very good point you’re making. As a VI program, especially if you’re just getting started, you can avoid a lot of the basic errors, but there’s still a lot of stuff that will come up where you’re actually going to have to know what you’re doing and step in there and solve it.
I mean, I had exactly this happen to me during Christmas; I was like five days stuck on a single bug. AI couldn’t help me; I was asking all different models, and the only real solution was just getting my hands dirty, getting in there, opening the Chrome Dev tools, really learning how to debug the front end. I think before that I was naive, like, “Oh, anybody can build a startup,” whatever. I was like, “This is the difference between the people who make it and who don’t,” right? That first difficult error that ChatGPT will not solve will really show you if you have it in you or if you don’t, 100%. And I always tell people, like, as a programmer, and I’ve been doing it for a long time, I’m confident I can build you anything—literally anything you ask me to build, I can pretty much guarantee you I’ll be able to build it; it’s just a matter of how frustrating it’s going to be and how long it’s going to take me to make it.
So when you ask, “Are we still going to have programmers in the future?” Yeah, absolutely, because we need people that have those skills to do those things. They’re going to have a different set of skills than the programmers traditionally, you know, four or five years ago, but they’re still going to actually know how to code. They’re going to understand the frameworks at a deeper level, and they’re going to be able to dive in there and solve the bugs that inevitably come up when you’re just prompting in natural English, and the AI is doing what you ask it to do, but you haven’t asked it to do it correctly, right? Which is usually the number one mistake. Absolutely. So also, everyone sucks at first, right? This is like when you’re watching, like, I don’t know, a professional football player play; you don’t see when he was three years old kicking the ball, missing everything, right? Same with programmers. Like when people watch you, you say, like, “Okay, 10 years of experience, you know, millions of subscribers,” like it can be intimidating, but if they watched your first hour at the computer, they’d be like, “Oh, like maybe I’m even better than him,” right? But the difference is those hours and not quitting. And I think there’s part of me who thinks, like, okay, that’s, you know, like built in, you were born with it or not; part of me is like, you can learn it. What do you think?
I think it’s definitely a combination when it comes to things like tech and software engineering, especially let’s say the past two years where you maybe didn’t have AI as much of a crutch. I think you have to have some natural level of intelligence to be good at it. I’m not going to sit here and lie and say everyone can be a fantastic software engineer. And if you look at things like the average IQ of software engineers, like it’s above 120, right? So that is, you know, you’re talking about the top 15, 20% of the population that can really succeed in this field; that’s just the reality of it. Could you do well with a lower IQ? Probably, but it’s just going to take you a lot more work. For me, naturally, I can learn things quite quickly; now also comes from practicing that skill and doing a lot, but even as a kid, like in school, I wouldn’t say I was gifted or anything along those lines, but I could definitely pick up topics faster than classmates, learn things, adapt really quickly. So some of it is kind of inherent, but also requires the work on the other side. You can be super smart and have no work ethic, and you’re just—you have no chance, right? So you have to have both of them, but I definitely would say there is a little bit of kind of that intrinsic, maybe you’re born with it, or at least it’s trained, I’d say more in kind of early childhood where you’re exposed to problem-solving and you’re kind of allowed that creative freedom. I, for example, was given a laptop when I was like 10, 11 years old, taking it apart, putting it back together, building Minecraft mods and stuff. Had I not had that experience, who knows where I would be today, right? A lot of that is just being tech-savvy, right? Like even just playing video games; a lot of that translates to being good at programming because you know how to install a program, you know what to do when it crashes, you know to update your drivers, whatever. A lot of those things people take for granted, right? Obviously, you have to transition from the video games phase to doing something useful, but just that having those tech skills, like having those fundamental meta-skills, is very undervalued, right? Absolutely.
And even just being able to type as well; that’s like one of my biggest regrets as a kid. I never properly learned how to type, so even today, I mean, I would have to relearn and, you know, give myself like arthritis to properly learn how to type at 100 words per minute, something along those lines. And I saw this—I used to teach kids at a summer camp, between about 9 to 13 years old, how to code in raw Python, not scraps, like actually writing Python code, and I would take for granted the fact that they don’t even know what a semicolon is, right, or a tilde, or a colon, or indentation, or a tab for spaces. Like there’s things like this that people forget; you don’t just know intrinsically. And if you’re analytically and you’re just comfort and efficient, your MBCs, you know how to type and paste on a keyboard, you would be surprised how many adults don’t even have those basic computer literacy skills. And like you said, if you play video games, if you’re installing mods, if you’re jailbreaking iPhones, if you’re hacking ads on YouTube, or whatever you’re doing as a kid, you start to build that kind of core confidence, which leads itself really nicely into becoming a programmer.
You mentioned typing fast, and I think this is one of the most underrated skills to have. Like I would highly recommend everybody watching this spend like an hour a week improving your typing speed. Right? For me, I was typing with four fingers—these four—for the longest time, right? Maybe from the age of like six when I first started using computers to like, I don’t know, 15, 16, 17, but I knew I needed to learn to type with 10 fingers, and it’s like, it’s so frustrating, right? It’s like learning anything new; I quit multiple times, but I persisted, and now I can type like 120 words per minute. And it’s kind of hard to realize the value of that because anytime—like, sure, you can speak to your laptop, right? But not in all situations. Like if you work at a cafe, you cannot like speak to the cursor, right? Maybe someone else is speaking, and it’s not picking up. So the value of typing fast is, like, I think one of the biggest productivity hacks that nobody talks about, especially now when we’re in this prompting era, right? The ability to take what’s from your brain and put it into the computer is literally, you know, a—what is it—like a superpower, right? If you’re typing at 120 words per minute, you’re pretty much like at the stream of consciousness when you’re typing, right? Anything that’s at the forefront of your mind, you can pretty much put it into the computer, and you’re at pace, at the speed at which you’re thinking. But if you’re only typing maybe 60, 70 words per minute, which is more like what I type at, which might be surprising to people, you’re not quite there, so you’re still top 10%.
Yeah, it’s still—I mean, obviously, I code on the computer every single day, so even with my whatever ridiculous typing style that’s been adapted over years, you know, that’s how it is. And also, when you code versus typing natural language, it’s a bit different in terms of, right, like the speed and how you would do things. So my typing style adapted to be able to press a lot of your foreign keys that most people don’t even know the names of—parenthesis, right, colon, stuff like that—so I can type very quickly in that environment, using the arrow keys, getting in between brackets, you know, not having to take your hand off the mouse, stuff like that. But when it comes to prompting, for sure, if I could type two times faster, I mean, I would just be two times quicker in terms of getting my thoughts to the screen, right? Also, what you mention is super important is the real-time speed, right? A lot of people just do the tests and races, and they have like 150 on the test, but if you put them into a code editor, say, “like write a function,” there’ll be like, you know, looking like this. So it’s not just the speed test score; it’s actually in your practice—like, do you need to look at your keyboard? Do you need to check where each button is? Do you need to switch between languages? Like those all add up. Yeah, and that was—that would be the value in memorizing syntax is that you can type it at the stream of consciousness.
So, for example, I just did a mock coding interview with my mentorship group; we did a coding interview with someone, and then after he pretty much failed, I said, “What, I’m going to show you guys how like an experienced programmer solves this.” So I hopped on the computer, you know, I solved the problem in 5, 10 minutes, and just typing nonstop, right? I didn’t use any AI coding assistant tools because it’s like how you would do it in a real interview, and it’s just typing at the flow of consciousness; whatever I think just gets happens on the computer instantly because I’ve done it so many times, and I know for all the students in that group they were like blown away. I’m like, “This is what happens when you actually know the syntax like the back of your hand, when you’ve actually typed 10,000 for loops or 10,000 functions, which is probably not an exaggeration at this point.” You can write like that where it looks like you’re writing in English pretty much because to you coding is like English, and you’re just translating an algorithm that you’ve come up with into code on the computer. Now, do you really need to do that nowadays? Probably not as much, right? Because even if you’re coding, you still have all of the assistants in the tab. But being able to just navigate the editor very quickly is a huge skill. And there’s a lot of weird kind of typing patterns you could do; for example, whenever I open a bracket or parenthesis, I always close it immediately, tab inside, or you know, arrow inside of it, start writing, so you never miss things like that that you pick up over time.
I mean, what you just said is like people who are not beginners, who are like intermediate, advanced—if they just spend 30 minutes a week learning how to—all everything about their code editor—I think this is also one of the most underappreciated things, right? So many people don’t even know, like, let’s say using VS Code, CER, whatever, they don’t even know all the things it can do. Yeah, they have no—they have no clue. I mean, I—we don’t even know half the stuff you can do in the editor; like there’s so many tools, extensions. I mean, you can watch so many great resources, YouTube videos, guides online that kind of show you how to use it, but just even using a more advanced tool like a debugger—like, I mean, I know you didn’t start in like a traditional software background, so I’m curious, how long did it take you before you started using like a real debugger, or do you even use that nowadays? Like a step-through debugger? See, my back-end developer is trying to force me to use it, but a lot of the times it’s almost faster to not use it, and the reason for that is how I work, right? So I work with Cursor, with typing in English, and if I do like a print statement, I can—the AI can more easily see what happened. With a debugger, it’s more reliant on me now, right? Now what I added into my setup is the MCP tool browser tools, so now Cursor can actually see my browser console, the network tab, take a screenshot of all of that automatically, so that is going to improve my debugging skills a lot, or at least the speed of debugging problems. But you’re right, like the power of the debugger is very, very good because you can see like at any stage, you know, what’s inside of any variable, and all of—like, for a long time, I didn’t even know it existed. So you’re absolutely right. Yeah, that’s the point. I think if you’re doing a lot of front-end code or like basic APIs or something, printing is fine; it’s more so if you get into like much more complex situations where you actually can’t print out the state, right, or you’re looking at like nested object properties or things that you might not even know exist; that’s where a debugger really comes in. Again, a lot of times I don’t even use it either because, again, like you said, a print statement is just faster, but in a more difficult situation where you’re kind of, you know, more clueless on what’s happening, that’s where it can be helpful just to step through. Regardless, there’s so many tools like that—even just knowing how to search in the editor properly, installing the correct extensions, you know, right-clicking, “go to definition,” “go to implementation,” all of those types of things are game changers if you know how to do them. And I always say this: I can tell you how good someone is at programming just by watching them for two minutes in their environment. They open up their computer, and behind them, you know, looking from their shoulder, I can tell you immediately their experience level just based on how fluent they are moving around their coding environment, whatever that may be, and it tells you how many hours they’ve spent there, for sure.
I think, by the way, we’re probably like six months away from Cursor being able to use, or AI being able to use a debugger. Wow. Like it’s only a matter of time before the AI can run the test itself; it’s like, okay, it’s stuck at this position, let’s see what the screen’s saying, what the terminal is saying, okay, the code—yeah, that looks suspicious, let’s put a breakpoint there. I mean, it’s coming; it’s crazy to think. I mean, I believe it 100%, just based on the currently what AI can do. I remember when AI was—you had ChatGPT open in like another window in Google, and you would just copy and paste code over, and then you got an error, and you would copy it over and you tell, hey, like coding AI—what is it? AI code editors haven’t even been around that long, at least working really well. Cursor, I can remember using it what, like not even a year ago, right? That’s been super popular. So imagine what’s going to happen in the next few years, and I totally understand why people are freaking out. Even sometimes I ask myself, “What does the future of development look like?” And the truth is, we really just don’t know, and you just have to stay at the cutting edge and just use these types of tools because if you’re not, like we said, like you’re just—you’re going to get blown away, right? Absolutely. Earlier you mentioned the importance of beliefs, right, that you believe you can build anything, and I think that’s almost like half the battle. People who want to learn something, if they don’t believe they can learn it, it’s like they’re fighting against themselves, and they will most likely quit, right? Let’s speak on that, like limiting beliefs, the value of believing you can build this, what’s your insight there?
Yeah, I would say the only way you can have that belief is if you’ve proven to yourself that it’s true, right? Okay, so when you’re starting out, it’s probably—to believe you can’t just build anything because you’ve never proven to yourself that you can do that. But what you need to ask yourself is, “How can I get to a point where I would have that belief? What could I do that I never imagined that I’d possibly be able to do, where if I had solved that, I would have this next-level confidence?” Yeah, 100%. And I always tell people, like, rather than trying to build like the next startup, like, let’s understand how a function works first, right? Let’s get one thing out of the way where, you know, if I asked you three years ago, you know, where do you think you’re going to be in your software development career, you probably would have no idea compared to today, right? Things like that—just get those small achievements, those small wins, start building that confidence slowly, and then you can start tackling bigger problems. I mean, it’s the same thing with athletes and athletics, right? Like the guys that are pro soccer players now, they probably didn’t believe they were going to be professionals when they’re like five, six, seven years old; it’s only until they started proving to themselves, “Oh, I’m better than everyone on my team, I’m better than everyone in my province, I’m better than everyone in my country,” that you know they get to that point. So I would just say, especially in software development or really any kind of tech-enabled field, you got to prove to yourself that you’re able to do it, and that only happens by solving really difficult challenges and picking something that you have no idea how to build and just figuring it out, no matter how long that takes. This is really good because I think a lot of people pick something too difficult at the start, especially if they’re starting from scratch, and then they quit, right?
Absolutely. The—like, I remember being a kid and just like writing a for loop or while loop, whatever, that just adds one and prints it out, right? And I was like so proud of this, you know, and I gave it green color, and I felt like a hacker. But the value of that is hard to project because it’s like those—you’re building that confidence, you’re building that small experience, right? You know, like how a for loop works, then you expand it into a function, and you build on top of that, right? Now, with AI, instead of trying to build like a full-stack startup right away, just build a few Chrome extensions, right? Like build something super simple that you don’t even maybe need, but will get you that experience: “Okay, I’ve built this, I’ve built this, maybe I can build this next.” 100%. Yeah, I mean, look, you have to start small, and then once you get a little bit more confidence, it is important to pick something of high difficulty, right? You don’t need to make it impossible, and also you can totally change the idea. There’s been many times I’ve tried to code something, realize, “Okay, I could probably figure this out, but it’s going to take me way too long; let’s shift ideas, let’s change this to something else,” right? Totally fine; that happens all the time. You’re going to fail; there’s going to be mistakes, but it’s when you get over those, and like we said, you solve those five-day errors that you start to realize, “Okay, I can do this,” 100%. It’s just a matter of time; how long will it take me to do it? That is really the only factor, and you have to have that belief: “I will be able to figure this out.” Like if I told you you have to build, you know, your startup—I have to clone that, for example—but I told you I will pay you $2 million if you do it in the next year, you’ll probably figure it out, right? If you have that incentive. So you have to kind of build those incentives in yourself and just really push yourself to do it. For me, for example, I’ve had times where I’m like, “I’m not sleeping until I fix this bug.” That’s probably not the best thing to possibly do, but you know, it works, right? It works. It’s like, “I can’t go out with my friends, or I can’t go get drinks, or I can’t do whatever until this thing is solved,” and you usually end up figuring it out. Yeah, for sure. I mean, sometimes it really is worth it getting that done because then you delay to the next day, right? If something else comes… Yeah, for sure. Also, this is the same getting into business, right? A lot of people—they like want to get into business, like, “Okay, how do I become a millionaire?” It’s like, “Slow down; you haven’t sold a single thing,” right? Maybe create a $5 product, $10 product online, get a few sales, right? Get your feet wet before trying to be a millionaire; it’s so crazy how many people try to skip those steps and don’t do like a small win or the basics. But to your point, it needs to be aligned with your grander goal; otherwise, you will just have no motivation or no desire to do it, right?
I love that “millionaire” is now like, you know, if you’re a millionaire, you like just made it, you know what I mean? Like everyone seems to think, “Oh, there’s so many millionaires.” Like social media is just so toxic, even for myself; sometimes I go on there and I’m like, “Man, I’m like failing in every regard” when I watch all these guys with private jets. We’re here in Dubai, so obviously we see insane stuff, but all of it is rented, let’s be honest, of course. But even let’s say it was true, right? It’s just you’re only seeing the flashiest, most extreme situations; you don’t realize like if you’re making $10,000 a month, you’re already in like the top 1% of the population in terms of income, right? Like the goals—start small and build your way up. When I was making $3,000, $4,000 a month as a university student, I felt rich, man—super, super rich. And then you get to this point and you start comparing yourself to everyone else, and you know, it really is the thief of joy when you start comparing yourself to everyone. Like a million dollars is a lot of money, even though today a lot of people argue it’s not. If you’re 25, 26, 30, 32, you have a million, you’re crushing it, and so many people think that’s like just the beginning. No, like build your way up; like let’s get, you know, covering your bills first, making a little bit of extra money, being able to buy a gift for your mom or something, whatever small goals, and then you can work your way to a million. Most people that tell you they’re millionaires, it’s not liquid, and it’s been built over a very long period of time; they didn’t make a million dollars in the past 12 months. Yeah, all the drop shippers make $100,000 a month, right? But then it’s like a 6% profit margin. Exactly. Yeah, to your point, I absolutely agree. When I was 16 and I, like, with my first business, I made $1,000 per month; that’s where I felt the richest, you know, going to school when maybe the teachers were making like $1,500, $2,000 a month, and I was like, like pure profit, right? No employees; I was like, that’s where I felt the richest by far. So it’s almost like the difference—it’s not about the raw amount, right? Like if you’re a multi-millionaire, but all of your friends are billionaires, you feel poor. But if you make like $5,000 a month and you’re in a poor city or whatever where the average salary is $3,000 a month, you feel rich. Absolutely. I think it’s about the perspective, and for me, the money is more about like the freedom that you get from it, right? And honestly, I find the more free you are, the more money you have, typically the more driven you are to go do something, like you have the ability to go and just pick anything that you want, whereas if, you know, you’re grinding—I don’t want to look down on something like a 9-to-5 job—but let’s say, you know, you’re grinding, working at Wendy’s or McDonald’s, like I did when I was a kid. I worked at McDonald’s when I was 17, you know, you don’t have that freedom to go start your business or do all these extra things because you’re working eight hours a day for, you know, $14 an hour or whatever it was at the time. It’s pretty good. Yeah, I mean, it’s good as a kid; like I felt like I was making a good amount of money, but you’re also grinding to do that, right? Now, obviously, you look back at it and it’s different. But anyways, I think it’s all just about the freedom and what you allow yourself to do in the life you live with that money, right?
It’s funny to mention that because a lot of people, like from the First World countries—America, UK, Canada—they even like, they look at minimum wage like $14 and feel like, “Oh my God, so [ __ ],” but like my first job, summer job, two weeks was like $3.50 per hour, damn. So, like, you know, there are countries where it’s way less than that, right? Southeast Asia, it’s going to be like $0.1 per hour or something crazy. So it’s always about perspective. And actually, to your point, a million dollars is a lot, right? For sure. But I think I wonder like when the term “a millionaire” is not going to be anything because I think we’re close to that. If you look at, you know, 100 years ago, where like you had Andrew Carnegie, John D. Rockefeller, and it was like, “He’s a millionaire,” and that carried a lot of weight. Today, I think a lot of that value is because of social media, but a lot of that is because of inflation, mhm. Like I think in 10 years—think about this—a lot of people who are not flashy are millionaires. All you need to do is like own a house, buy it, hold it for 30 years, maybe it’s worth like $500,000, $700,000, then you need something in your 401k, and technically you are a millionaire. So I think we are like the last generation, maybe in the last two—last two decades probably—where the term “a millionaire” even means anything. Yeah, it’s interesting; I think it depends on the source of that million too, right? Like if it’s all held in your house, for example, and you’re 60 years old, then obviously it’s a lot less meaningful than if you make a million dollars in a single year. So I think what will probably happen is there’ll be more granular definitions, or people will start to realize that “millionaire” means like you have, you know, a tech startup that you pay yourself $50,000 a year, that’s valued at $10 million, like all the guys in San Francisco that I just came back from. Yeah, they can call themselves millionaires, but like that’s not realized, right? And are they actually truly worth that amount of money? If…
You actually have a million dollars liquid sitting in your account, especially if you're young and you don't have crazy expenses. That is an astronomical amount of money, even though a lot of people here don't like to believe that's the case. And you know, your high earners won't say that, um, especially for 95% of the places around the world. Right? Go to, you know, Indonesia with that amount of money, or Thailand, or you know, India, or places like that. Like you're you're fine, you're chilling. So it's an interesting point, but I think a lot of people just throw around that term like meaninglessly now, and uh, most people don't know what that actually really means.
And if I hear "millionaire" now, you know, I always immediately have so many follow-up questions: to say, what actually is this? You have a million dollars in a stock account, or what? Like you had a property, like you said that, you know, it's all sitting inside of there, and you can hardly afford groceries because you only make $3,000 a month. Right? Yeah, I mean, a lot of people call some millionaires because they have some like agency that makes like 20K a month, and they say like, okay, if we, you know, annualize, do, do multiple, if I were to sell it, like you're not selling it. Okay, like that those numbers, it's so relied on you, you're basically like a, u, what's it called, glorified employee? Right, like glorified freelancer. So yeah, you're right; if you have a million dollars cash in your bank account, it's huge. Right? If you have like some company that you own a stake in and you can't really sell it, or, you know, in a house and you have family, like yeah, million, million matters what form it is for sure.
Also, I want to touch on like challenging yourself, right? Because there, there is a lot of people would think like it's better to be the wealthy guy in the small city, but I would say the exact opposite. Right? Like I grew up in the Czech Republic, and where I came from, there was, I, I didn't know anybody successful. Like for the first 20 years of my life, I never met a single millionaire, and that's like, you know, millionaire in Czech crowns; like it's it's not even US dollars. So I think moving to Dubai, that's probably for me the most valuable thing is surrounding yourself by more accomplished people. Like, you know, when I went to Vegas to do the Horoi event, just seeing people who like make casually 500K a month, like, and they talk about it, and like Horoi's like chilling, you know, because he makes like 17 mil a month. It's crazy, right? But like that really opens your possibilities; like those are completely normal people, but they're just a few steps ahead of you.
100%. I mean, that's a very similar thing to me as well. Um, you know, in Canada, obviously it's a little bit richer than the Czech Republic, and I definitely did know people that were millionaires, not necessarily my age or in kind of a similar field, but, you know, especially in like late 30s, early 40s, stuff like that, you know, they had a career, they saved a bunch of money. But moving to Dubai, you just see it everywhere, right? And I mean, we're sitting down here, we've had conversations about it, you've introduced me to all kinds of people here. I've met lots of people in Dubai that are making astronomical amounts of money that are kind of hard to even fathom or understand, that are 18, 19 years old, right? And it wakes you up, and it gives you that perspective. Like you said, when I was, you know, back in Canada, I was, you know, the richest person in my neighborhood, right? In terms of income, maybe not net worth, but in terms of how much money you make. And then you move to a place like Dubai, and all of a sudden, you know, you're a small fish in this, you know, huge aquarium, uh, and you start to realize what's possible. I think there's huge advantages to that for sure. You push yourself further; you realize, damn, like these guys can do it, they're not anything more special than I am; I can push myself there too.
But at the same time, you know, have this comparison, and it's like everything that you've built feels a lot more like meaningless. You know what I mean? When I was in Canada, I'm like, you know, oh, I'm like the richest here, this is awesome, this is super cool, like, you know, you feel really accomplished. And then you come to a place like this, and you start comparing yourself to guys making a million, two million, $17 million a month, and all of a sudden, that, uh, it can drive you, but I think for certain people it can also be a hindrance as well. It's a very tough balance, especially in this city of Dubai, with all the bling everywhere. But a lot of people want the ego more than they want the growth; right, they want to feel good more than they want to succeed. Yeah, they want the status, right? I mean, even a lot of people, I always tell people like, if I could be rich and not famous, that'd be way better, like for me personally, than even having to have like this massive YouTube. Don't get me wrong, I love what I do; this awesome YouTube channel, it's much different type of fame than, you know, if you're a vlogger or something. But uh, I would always rather be like more behind the scenes and not people knowing me, where there's other people who are like, I don't care how much money I make; I want 10 million subscribers on YouTube, I want everyone to know my name or know my face. And I mean, look, that that's what drives some people, and that's that's totally fine.
I always think of that when I see like these shorts creators, especially, right? Like people making like some content with their cat or like some couple content, like they might be getting millions of views, but like most of them still need to have a job, right? And then there's like guys who have like, I know guys that are averaging like 100, 200 views per video, and you would think like, okay, this guy surely isn't making money. No, I know guys that are actual millionaires on paper because they have the right audience. Like if, if you have like, obviously this is not realistic, but like if you post a video, 100 views, all of them are billionaires, that's much more valuable than like 10 million views and all of those are kids, right? So it's also that nobody looks at the quality of the audience; everybody looks at the wrong numbers. But then you have all these influencers who are like broke or, you know, shilling shitty brands like Honey because they don't have any other opportunity. Of course. Yeah, I mean, I always ask myself when I see those short videos, like what's the point, you know, like why even bother posting this? But then, like you said, it's purely like an ego, a fame, the fact that they can go online and say, oh, I'm viral. And of course, you know, a few people like that get some extreme situations and, you know, get called out, but it's, you know, one in hundreds of millions of the people that are posting online. So I would rather have, you know, more of a private life, and even that's the kind of content I post on on YouTube; it's very, you know, non-personal, very technical, um, that's what I prefer to do, but we have other people on the other side of things, so it's it's an interesting dynamic. I'm more focused on the bottom line, the gravity, also how many people I'm helping as opposed to just how many views can I get.
Yeah, I mean, a lot of people are focused either on the raw fame, which I think is like the the dumbest thing to do if you have no other objective, or the money, but they don't care about how you get there. It's almost more important, I would argue, how you made your money than how much you made. Like if you, you know, let's say like a scammer, like I don't know, Bernie Madoff or Sam Bankman-Fried, those fraudsters, like sure, they can be billionaires, but then you end up in prison, right? And even if you don't end up in prison, it's like nobody wants to associate with you, right? So that is for sure real, and there is a lot of people in our age group, I would say, that are only about the money and that will like sell a, you know, high-ticket program to somebody who's like completely outside of their ideal avatar, who like most likely will not succeed and like cannot really afford it, just to have that sale. Yeah, it's I think it's a tough balance because those type of people, I mean, they end up making more money, right? Because they're ruthless, and they'll be the, yeah, sure, I mean, short-term, but I would say even in a lot of situations there's people that are like very scummy that just, you know, they succeed crazy, right? Like nice guys finish last, you hear those type of sayings. I think long-term, sure, the more value you provide to your audience, yes, but it it can be a tough balance. Like I don't think it's always true that the people that are maybe, you know, scamming you, whatever, eventually have some, you know, downfall; like they they can continue that their entire life. There's a lot of people that have done that. So as, you know, a creator or someone who wants to make a lot of money, you can like easily fall prey to those kind of traps. Uh, but for me personally, I've tried to always kind of stay true to the core values of like I want to actually provide education; I want to actually help people. Sure, I can just, you know, shill like a coin or something, right? Like make a crypto coin and make a bunch of money, but I genuinely have no interest in doing that, even if you told me today you can make, you know, $5 million scamming your audience on a coin. It's I don't even think about it, right? But there's a lot of people who will take every single chance they get to exploit people, and uh, you're right, we see that a lot here in, you know, on this in this space.
I mean, you're right, like, you know, you could be charging a lot more for what you do; you could be having your crypto coin pump and dump, whatever, but you don't, because you see the value in your audience, in having that, you know, 10-plus-year history of your YouTube channel and the power of the personal brand, right? So let's speak on that. What, what is like the main benefit from your experience of having a large, respected personal brand? Yeah, I mean, there's unlimited. Obviously, I would say the number one, especially if you want to maintain like a professional reputation, which fortunately I have, is just instant credibility. Right now, if you're something like a vlogger, you know that that's a lot different. I'm talking about personal brands in a sense where you're displaying value and skill sets uh, beyond just purely being entertaining. So in my case, you know, I'm very technical online; I have literally thousands of hours that you can watch of me live coding; like not many people can actually say that, right? So if I ever was in a situation where, let's say, I didn't want to do YouTube or I want to pick up some kind of freelance gig, or even I walk into a room with a bunch of software developers, I instantly have credibility; people will instantly listen to what I have to say, uh, and you know, you can kind of reach out to anyone and immediately, you know, provide some kind of value. So it is, you know, kind of shitty sometimes; you don't want to like be flexing your, you know, subscriber count and personal brand, but it is just a way for people to immediately kind of recognize the value that you bring and be open to conversations. So outside of just making money from YouTube, uh, the credibility is is massive, and it's something that even if my YouTube channel were to go away, I still have that entire history, and I can still always point back to that and kind of prove my value from that, right?
Yeah, I love that you said that because this is I think another thing that people should do: just document the process, right? Like when I decided to build a startup, I knew I wanted to document from day one, and you know, maybe now it has like some value, but if it ends up being super successful, that would be priceless. Like, you know, how much would we pay if Elon showed like day one, day two SpaceX, Tesla, like that would be priceless. I would pay all the money he would ask, right? So like I think a lot of people aren't documenting because like, oh, you know, I look bad, I look [ __ ], but like gym transformations are the the bit most obvious, right? Like everybody would wish that they had the pics when they look the worst and then after, but it's the same with like programming. People can show like, you know, record themselves how they're bad or like six months of progress, and then let's say an employer is like, I don't know, if you hire like, look, this was me six months ago, this is me today, look how much faster I look, you know what projects I built in that time. I think that would impress an employer way more than like some, you know, like CV. I mean, I can tell you that like that that happened to me when I was applying for a lot of jobs now. Uh, first, I would say the value of like the documentation, it doesn't matter if anyone's watching it, for that fact; it's just the fact that you have it there, and it's something that you can talk about and you can point back to, especially if you're in something like, you know, an interview situation. Now, for me when I started applying and I landed my first few jobs or first few offers, I got an offer from Microsoft, for example, one from Shopify. And for Shopify, this is actually one where I just like raw applied, just like shot my resume in; I didn't follow any of your ATS scanning type stuff; it was, you know, really bad compared to what I would have today, but I had on there, you know, "programming YouTuber," and I had, you know, 800 whatever plus videos, probably less at that time, a bunch of cool projects, companies that I had worked with, and they told me specifically the reason they brought me in for an interview is because I had that on my resume, and they said that's really unique; we haven't seen that before, or it's not very common, and at minimum we just want to talk to you; we don't know if we're going to hire you, but we just want you to come in because it's it's interesting, it's different. So now again, you know, that's a bigger social channel, but even if you had 3,000 subscribers, 1,500, if you've shown commitment and passion, that's what a lot of people are looking for. And even if it's a blog post, LinkedIn post, it doesn't matter; just doing something consistently for a long period of time is always going to benefit you, and it's always going to be something you can point back to again, even if no one watches it. Go in your interview, you say, yeah, you're asked about my consistency; I've posted a blog post every single day for 200 days on this website. How many people have something like that that they can point back to?
So let's get back to the concept of vibe coding, right? What do you think are the mistakes that vibe coders—AKA people who just type in English and have the AI write a code—what are some of the most common mistakes those people make that the real developers don't? Yeah, I would say really missing like a structure and a plan, um, before you just start blasting stuff to the AI. You should really come up with at least some kind of guideline or some kind of, you know, very basic plan of what it is that you actually want to do. Again, the AI models are really good at handling specific tasks that you describe well, but if you yourself don't know what it is that you want to do, you're going to let the AI move you in all these different directions, and it's really just going to get very difficult to follow along with. So that's the first thing: you need some kind of basic plan. Now, you can have the AI make the plan for you; that's fine, but you need something, and you need it like in a separate document where, you know, like, okay, these are my 10 steps or like the 10 main things I want to accomplish, and then you can start crafting the prompts from there, and you at least have something that you can check, like a a guideline to make sure that you're following. I would also also say just blindly accepting what the AI is doing. Now, it's very easy when you're a beginner programmer to just like, okay, accept, accept, accept, just, you know, go ahead and do this. When projects start getting larger, you really don't have that context that programmers build when they write code for, you know, tens of hours in a code base, so you don't actually really know what's going on. Like I've had this mistake happen to me many times where I just blindly trust the AI; I get it to, you know, create tens of files at a time, make these massive edits, and then something happens where I want to start, you know, changing the structure, making it more scalable, or going into something a bit more complex, and I really don't even understand what just happened in my code base. It takes me a good amount of time to go scan through, read all the files, figure out what's happening, and when there's a hundred files to scan through, it's just impossible to bring all that context in instantly. That's the one downside. Now, anyone who's worked as a professional software engineer like I have, you know that when you write tens of thousands of lines of code and you build a code base from scratch, you have a very deep understanding technically of what's happening in that code base, and when you just vibe code, you lose all of that, and it's good until you get to a point where the AI can't take over; it can't do what you need, right?
Yeah, you definitely need to stay in charge. This is like something that people, because they don't have experience of leading any teams or stuff like that, right? So they outsource it, and like they start asking AI, like, do you think we should add this feature? Like, no, you need to be the product manager; you need to know which features to add, and at minimum you need to understand what each file does, right? Maybe you cannot, like, expl, expl each line of code or each function, but if you, if someone shows you a code, be like, what does this file do? You need to know why this file is needed; otherwise, you you'll just get lost, like you like you said, right? And it doesn't matter if you're a beginner or advanced programmer; if the AI is starting to suggest like, let's create these two new files and like update that file, like, who, you need to know like why are you updating that file, right? That's completely underrated to what I said. So never, even if you're WIP coding, never accept changes that you don't understand, at least why the changes were made. Yeah, again, you don't have to understand every line of code, but like you still need to stay in charge. And I think it's hard to quantify that, but this is I would say one of the main differences between people who succeed and who don't is that the beginners, they just accept everything, and they delegate the direction and the vision for the project to the AI, and the people that make it, they stay in charge, and they're like, tell the AI, no, don't change that file; let's put it in this file; let's stay here; let's add this feature; no, don't add; why, why are you changing that? Stay here. Yeah, and that, I mean, that goes back to like, are we going to still need software engineers? Like, those are the people that have the experience to guide the AI, right? If you're a complete beginner and you go in and you start using Cursor, all of the things you just said sound great, but you don't even know what that means; like you don't even, these files, who's using what; you're just blindly trusting this tool because you don't have any background information, any knowledge whatsoever. It's like me if I go into an art class or something, right? Like I have no idea what the heck I'm doing, so you tell me anything; I'm just going to blindly trust it because that's all the information that I have. So that's why I think it's still as important to have those fundamental skills, and more so at like a higher level architecture, right? Start, start building something large; we talked about this previously; it's great, it works in an MVP environment, but scalability is something that most people don't think about until it's too late, right? Things like, we have a back end, we have a front end, we have these different gateways, we have this database; like most people aren't even, they're just letting the AI randomly pick one. You should at least know like the high-level structure of what it is you're trying to build, and you should make those decisions on the important technology that might cost you millions of dollars down the line if you're a startup founder on what it is you actually want to use. I'm not sure, uh, like how you came up with that for your startup, but should do some, you know, basic research; you don't need to be a software engineer to decide between Python and JavaScript; you can find that information online, right?
Yeah, so to answer the question, I did it by paying for consultants. There you go. So, you know, I paid the best developer I knew at that time for like, I don't know, 150 an hour, 200 an hour consulting, and he explained to me like, this is, you know, the the back end, this is the front end, this is API. I didn't fully understand the concept API; I understood like, you know, you can use open API to get AI work in your code editor, but didn't understand why you need API between front and back, and right. So like this is the ignorance debt that you only realize once you start building something, and I think consultant is honestly like a hack, like, you know, if you could pay, if if I knew you, I would definitely pay you, someone like you to help me like, okay, what should I use for the front end? Okay, you choose this, this, this. Okay, why? Boom, boom, boom. And you can like give me, I don't know, 50 hours of what I would have to figure out in one hour. So that's why I would definitely recommend going with experts, you know, joining some program like yours to learn the basics from someone who actually understands it because because you never know, like you can watch, you know, things, you can ask AI, but it is that those like small details that the person who has those 10,000 hours only knows exactly, and that you, I mean, you don't know what you don't know, right? That's why I always suggest when you're starting out with a new skill, whether it's programming or not, and I do this personally, find someone who is an expert in the field and just give them a few hours of your time because the small nuggets that they'll share with you are just things that you could never even prompt the AI to get, right? Someone that's been doing something 10,000-plus hours, just naturally the way they speak, the information they're going to share with you over something like video, which is personally what I like, just again when you're really starting out at the very beginning, you just get so much important, needed context that's very difficult to get when you don't even, you know, know where you're starting. So uh, absolutely. And in terms of consultants and coaches, I mean, that's why they have so much value, especially for, you know, higher-level people that can actually immediately use those skill sets. What I recommend, you know, paying for a consultant when you're a complete beginner programmer, probably not, but if you have something that you actually want to build and you know this is what I'm going to go do, uh, then it's definitely super valuable. You know, as you stated, I would say like anytime I paid for a consultant in my life or somebody, you know, people like, consultant, okay, that's McKinsey or whatever; no, consultant is anybody who can who has more experience than you on any topic who can help you answer questions, right? So anytime I paid for like that consultant, it was always worth it, right? Even like if you don't say like, okay, this was 10 out of 10, whatever, it's like at least you learned something, right? If you prepare 20, 30 questions and you you just ask them, see like, okay, I shouldn't do that; okay, good to know. Maybe it's it's hard to quantify the value of that, but unless the consultant is like ridiculous, you know, influencer flexor that charges 20K per hour, if you pay like most developers would charge like 100, 200 per hour, and if you, as you said, if you have a project that you want to start, I don't think there's a better investment than paying someone who has that, you know, senior level of experience, say like, what what should I do? How should I structure it? Because the architecture, you know, if you do if you mess that up, it's like that that will be a nightmare to change.
Yeah, I mean, most startups make that mistake, right? Like you just go as fast as you possibly can, and you know, you could argue it's not a mistake, especially, you know, if you're raising capital, you're just trying to get a demo out, but then you end up having to rewrite it, and I mean, that happens for many, many code bases. You know, you get to a point where, okay, we can sustain, you know, 50,000 users, but to get to 1 million, this whole thing needs to change, right? And I've seen that many times within companies, and it's fine, you know, it's a it's a calculated risk they make at the beginning, but if you can avoid that and write it in a better way at the beginning with someone more experienced, uh, it's hugely valuable. In terms of the consultants, I would say you're correct, but you have to go into it knowing what you want to get out, right? Like in your case, you know, you have a list of 30 questions; you want to build this project. If you're just like lost, you don't have any guidance, you like you don't waste your money like paying for coaches if you don't know what you want, because a coach can only help you as much as you want to help yourself. And for me, I always say like, I can tell you guys anything you want, but you got to ask me the question, right? I can try to guide you, and I can try to get it out of you, but at the end of the day, it's up to you to utilize me as a resource. I'm here; I'll answer anything that you want, but it's on you to ask that that question, right? Um, yeah, I'm glad you mentioned that because I think it's the same thing with the AI, trusting the AI too much, right? Like at at the end of the day, you need to be the person in charge of your life; you need to be deciding, okay, I want to build this; I don't want to build this; I want to, you know, learn that; nobody else can do that for you. Maybe you can ask for options, but you have to make that choice. And yeah, I don't know, maybe some people just, uh, don't like to make those tough choices and don't want to be in that leading role; that's completely fine, but if you do want to be that, you have to realize like you, you know, if you do if you trust your decision and then it fails, you at least like, okay, you know, it's my mistake; you take accountability. But if you fail because of someone else's decision, then that that's like a nightmare scenario; you blaming that person is like, okay, you know, but if I did it differently, it's like, no, you have to always decide and make the final decision yourself. So yeah, absolutely right; if you don't know what to do, you know, coach, like they will tell you what they think they would do, not what you necessarily need, so you need to know what you need and then how to get it; that's the consultant or the coach, right? Also, the other extreme, so we talked…
About like people who don't care about architecture, right? Just speedrun through it. But the other extreme is the people that are like solving for problems that don't exist, right? Like, how do I make my app scalable? Like, bro, you have $50, Mr. Like, chill out, right? Like they're studying like the Netflix backends—like that's the other extreme. So can you speak on that?
Yeah, I mean, I I've experienced this many times, and I actually ran a tech startup myself about two years ago where I was like kind of the solo engineer for a while, and then we ended up hiring a team. And at the beginning, as an engineer, you know, you think like an engineer; you don't think like a Founder, right? For you, it's you're the opposite; you think like a Founder, an entrepreneur, but an engineer. So you kind of get, you know, a mix of both worlds. If you're working with those types of people, it's always a balance, right? Like you want to write something in a way such that it will continue to work in the future, but you don't want to spend so much effort building something that just doesn't provide any real-world value. So like you always have to ask yourself, what is the value my users are getting out of this particular feature, or what it is that I'm writing or that my team is going to get in the future? Like, is it worth, you know, an extra 10 hours of my time to really make this, you know, fully scalable? Um, it's tough decisions to make, but it's constant, you know, daily small decisions, um, that you do make that eventually, you know, lead you to the path that you go down.
So that's why, if you've ever worked in an engineering team, there there's constant debate on what to do, right? There's always like a best solution, like an ideal, like what you absolutely should do. Very few times you ever end up actually building that because it's really just not needed for what it is that you have. And it's one of those things: if we get to a point where we do need this, then we'll have the resources and the justification to build it. So there's all kinds of, uh, you know, software engineering methodologies for doing things like this, but it's just you have to debate with yourself or even with AI. And that's something I do constantly, especially if I'm working as a solo Dev. I have a various, you know, I have different options of ways to do things that I know will work, and I'll ask AI, you know, "Let's brainstorm, and let's go back and forth and debate me on these different topics." I'm not necessarily going to trust exactly what it says, but I want to hear the counter-argument to, you know, you know, my approach to see if there's anything that I'm missing. And that's why it's very valuable to work with, you know, more experienced devs that will shoot down your really crappy ideas.
By the way, in Vectal, we just launched a new feature called the Ideas Inbox, and this is a place where you can quickly brain-dump your tasks, such as "buy groceries," "don't forget to feed the dog," and then you can easily categorize them using our AI agents into a task note or just delete them. This is just one of many features Vectal has to offer, and this is exactly what makes Vectal special. We're releasing updates nearly every day, so if you're someone who likes to be super productive, this is the only task management tool you need. Go to Vectal, and you can get started completely for free.
So you mentioned like, you know, it's difficult to know what is that best decision, but this is like all of Entrepreneurship summarized in one sentence, right? Like this is what CEOs are paid for; it's the judgment; it's the decision-making; it's like making the right call, you know, solving the problem in a way that, you know, the average like employee number 200 would never think of, right? And I don't know what is this concept, but I feel like in the recent generations, maybe because they are like, you know, far away from history, where probably in Eastern Europe, where like even 30 years ago there was communism, this would never come up, but like a lot of people our age, you know, from like the liberal cities in Canada, USA, whatever, they think like CEOs are useless; they think just like a random person that appears out of nowhere from the sky is like, "I deserve 20 million a year." Like, no, that person literally built a company if it's a Founder CEO, and the judgment on that person is what they're paid for; it's not their hours, you know, on the computer; it's like they get the inputs, and they make the right decision, right? And again, for the employee number 5,000, it's like impossible to know that. But what you just describe is exactly that: if you have 50 options in front of you that like the incling is like those 49 don't look right, this one looks the best, right? It's often times it's not correct, like, but the best Founders like, you know, Elon, Jeff Bezos, they're correct more often than they're wrong. So the value of judgment—I think this is what most people don't understand about being an entrepreneur—it's like the decision is what you're paid for; that taste, that, you know, intuition.
Yeah, I'm glad you said that, and it's a different way of thinking, right? It's a different paradigm shift if you're an engineer, and I I like that we have this dynamic where like you're kind of an engineer but you're more of like an entrepreneur, so you think slightly differently than I would as like more engineered-focused, more logical, you know, you know, pure thinking on the engineering scale. If you're trained as a software engineer, your like your intuition is going to be to go with the most challenging, just best optimal solution you possibly can build because that's what you know how to do, and that's where your skill set lies. Like that's a bit of an ego coming out as well; you're like, "I want to build this, you know, really challenging cool thing; we're going to have all these features," blah blah blah blah blah. Whereas if you're a CEO, you have to be able to sit there and go, "No, you know, we don't need this. I'm okay if it's 80% as good, and it just gets us there; it gets us to the finish line, you know, three weeks faster," whatever it may be. So as, you know, a startup founder, if you are more from an engineering background, you have to really change the way that you think, and you have to just focus, focus on, "Okay, how do I get something out there as quickly as possible, validate my idea, start growing my team," and then, you know, if you have the resources, if you're more of an established company like your Microsoft's, Google's, now you can build it the best possible way, right? You have the ability to do that, but even in those situations, you still have, you know, startup or lean type teams in those companies that aren't doing that; they're just building it as quickly as possible, getting those MVPs out. So it's it's very difficult though to shift your mind, that balance; like that's that's the game, that's the game of Entrepreneurship, you know? Like, "Do I ship it fast, or do I take that extra day to polish out the features because then the users will hate it; it's buggy, and it will ruin the launch," right? You you cannot quantify that; there is no like math or like code expression that will give you like, "You should spend three days on the feature." Like, it's impossible, right? That's why it is sometimes you need to trust yourself, and you need to go with the decision.
I think a lot of like intermediate entrepreneurs, what I see they make is almost they listen to the user too much.
Yeah, for sure. Obviously, you need to talk to your users, right? And like what I did is I literally—I think to be honest, what what I'm doing, not to boost my ego, I think in two years more companies will do this—I created a Discord server; I put a link in my app, and literally anybody who finds a bug can report the bug, tag my developers, and it's like, if it's happening to multiple people, we will fix it within hours or maybe a day at the latest, right? And training those users also to like, "Listen, you found a bug; that's that's great; you know, it shouldn't exist, but like how did you how did you find it? Like, give us the steps," right? And I I'm still in the process of building that culture, but I'm telling you in two years there'll be so many companies that do this because it's honestly a hack, having a Discord server where the people can instantly report issues or like say what they like or what what the next feature should be; it's such a fast feedback loop. I don't even know how other companies do it honestly.
I actually, to be fair, a lot of companies do have that. I work with a lot of companies that do have Discord servers. Now they're also typically a little bit more established, right? So for you it works really well now because you have like somewhat limited feedback; you don't have thousands of, you know, issue reports a day, I imagine, and you have a lean team, like it's two, three, four of you, whatever, so you guys can just instantly agree and fix something. But if you're, you know, a company of 100,000 employees, right, or you're 50,000 employees, or you're an engineering team of 20-plus people, you have processes that you need to go through, right? And you also, if you break something for certain pieces of software, it's critical, right? Like you can't break something like—for you, if you guys just, you know, ship a feature out and, you know, push it really quickly and it passes staging, whatever, okay, great. But um, there's a lot more stringent, you know, testing and development for for certain pieces of software. What I worked at Microsoft, for example, I worked on on an open-source team, so we actually worked on the Python extension for Visual Studio Code, and this is a massive extension; it's millions of lines of code; it has sub-teams for different sections of the extension, and it's open source. So because it's open source, we get hundreds of, not thousands, of issue reports every single day. In that situation, it's overwhelming, and you need a whole process to triage issues, sort issues, arrange them. So if you're really lean and you're like super startup, fantastic what you're doing, um, but it can be get, you know, a little bit crazy, uh, if you get into, you know, more established software or things that are a little bit more critical than, you know, your your task management thing, where if it goes down someone to be pissed, but like it doesn't, you know, it doesn't really…
I'm glad you mentioned this because this is like, you know, this is the things you don't know what you don't know, right? So for sure, like when I get bigger, I'll encounter things that right now maybe I don't even imagine.
Right, exactly. My point was more in the like getting the feel of what's happening, right? Because there's going to be like one guy that found some esoteric error on his like weird browser, right? Like that's not worth fixing, but if you launch a new feature and within two hours you have like four different users that found the same bug, then you at least have that feel. So even if you're getting hundreds or thousands of bug reports, if you see like the same one—like most of them are going to be one-off, right?—but there are going to be few that like 20 people have, 30 people have; those are the ones that should focus on. If you have that Discord server or like a fast channel where the users can communicate to the developers, and also I think the most inspiring thing is like if someone reports something and then sees it fixed within a few hours, that's like almost better than if the bug didn't exist. Think about that, right? Like if you have a bad experience, like if you lose a wallet and then the taxi driver brings it back, now you're like, "Oh, this is my guy; like I'm using this guy forever." But if you didn't lose that wallet and you know he did everything correct, it wouldn't be like even, you know, you would give him five stars; you wouldn't have that same level of experience. So when people encounter a bug and see the developers fix it same day or even, you know, within a few hours, sometimes I think that's absolutely huge as a user perspective. But my point was a bit further than that; my point was like training the user base to be the testers, right? Like you can find a bug and say like, "Oh my God, this doesn't work!" It's like, "Okay, calm down. If you want us to fix it, tell us the steps, right? What browser are you using? What computer are you using? What exactly happened before that? How can we replicate it?" And this, I don't think—maybe you can correct me—but this I don't think companies are doing, training their users to report the bugs like testers, and then other users also hold them accountable. If someone posts something in a Discord server that doesn't follow, you know, the "how to replicate" steps, it's like, "Bro, they have a lot of on their plate; just like, tell us how to replicate this; otherwise, they cannot fix it." And I think training that user base is insane.
Yeah, for sure. I mean, you built a customer for life, right? If you're in that situation where if you do fix one of those bugs. So what you're doing, I think, is fantastic. I think more startups should adopt that type of, um, what is it, culture in terms of training the users. That's interesting. I've definitely seen some companies like try to do that. I think it's different though if you have a technical audience, which I believe is more so the people you have—correct me if I'm wrong—they naturally can think like that, and they're used to solving those types of problems, right? Where like they know, okay, even if they don't—they're not used to reporting it in this format—"Okay, I get why you're asking me for the, you know, the OS I'm on, the reproducible steps, you know, what time I was on the site, whatever, all these types of things"—but for people that are not technical, um, it's very strange to have to do that, right? They're more like, you know, "This thing doesn't work," and they don't think anything beyond that; they're just like, "This thing's broken; fix it."
Back to your point of like it's easy to build an MVP, right? You can load up Vercel, Bubble, and get something up within minutes, which is amazing, right? Didn't even—wasn't possible six months ago. So I don't want to discredit that, but then it's harder to turn it and deploy it, monetize it, right? That's like building the MVP now is literally like 10% or even like 5% of the work, doing all those boring but necessary things, which, you know, it's nice to like design the website, design the front end, like even like the back end, but connecting all that together, putting the pieces, deploying it, monetizing it, marketing it—those are also super necessary, and those are the things that a lot of programmers like to skip because a lot of programmers just, you know, if if they want to build a startup, they they want to do the building part, but they don't see all the other stuff. What's your experience on this?
Yeah, absolutely. I mean, most people when they get into software engineering or they're just learning programming even like as a hobbyist, they don't even know what like deployment means, you know what I mean? Or they don't even understand that like there's entire roles at companies for DevOps engineers, right? Or even more granular roles than that's for specific deployments; you have, you know, IT departments for security compliance, um, you know, whatever, all of those kind of things. So it's very challenging when you start out because, "Oh yeah, I'm going to build this framework; I'm going to do all of this," but you don't have, you know, deployment in mind. If you're more experienced, you usually will ask yourself, "Okay, how am I actually going to get this out to users?" At the beginning, it doesn't mean you're going to do that at the beginning; like you're not going to, you know, go and write your Docker files and, you know, make your containers and all those kind of things, but you'll at least have it in the back of like kind of your subconscious so that you don't build something that's going to be impossible to actually get out there. I think it really just comes with with experience, and when you actually need to deploy something. Like most people never actually need to put something into deployment as a software engineer; you're usually working in an environment where, especially if you're not at a startup, it's all like all the pipelines are set up; everything's there; you have special engineers that do the deployment; you just write the code, and then magically it gets, you know, sent through the different environments, and the users, you know, touch it. And that's why I think it's very valuable to work at a startup as, you know, an early software engineer, 'cause you get the entire software development life cycle, and you get to touch pieces of the pie that you just never would see at a company like Microsoft. Like, you think me as an intern at Microsoft is ever going to get to touch a deployment pipeline? No, they don't even trust me to like see what it's doing. So, um, yeah. And I'm curious actually what your experience was like with that, 'cause like you said that can be a lot more challenging, and if you do that incorrectly, you can really screw yourself with the deployment, right?
I mean, my experience was, um, kind of easy. I think this this is the like, you know, coming from the entrepreneur backgrounds; like all I do is solve problems, right? Like for the average person, their biggest problem is like, "Oh, my car is like flat tire," the biggest problem of their month, right? Like all we do as entrepreneurs is like problem after problem, and you don't take it personally, right? You like, "Oh, this is stressing me out," it's like, "This is a problem; it needs to be fixed," and then next, right? So what I did is I literally have it documented from day one, but I built the like, you know, more up with Vercel front end; I was like, "Okay, I have the front end now; I need to build the back end." So then I build the entire back—not the entire back end—like the MVP back end; like, "Okay, then I need to connect it together." That was the like perceived friction part, connecting the back end with the front end, but when when I did it, it was surprisingly easy. So like, "Okay, then I had the app running locally, right?" So like then the next step was after I polished bugs, whatever, "Okay, how do I deploy it?" And then, "Okay, I need authentication, right?" So authentication was the next thing that I spent a few days figuring out how to do authentication. I was like, "Okay, I have that, but uh, I need to accept payments, right?" Because I took advice from Levels.io, Peter Levels, who recommends start with only a paid plan, and then once you, you know, you can add a free plan later, so I did did that. I was like, "Okay, then I spent four, five days adding payments." So any problem that was like the next bottleneck, I just solved, and it didn't feel like it didn't feel like anything.
Sure. Now if you're comfortable going more technically, I'm curious like, so you're you're deploying your uh front end with Vercel, I imagine, and then your back end like Render, Go, etc.?
Okay, Render got you. And what are you using for the back end?
Uh, FastAPI in Python.
Okay, nice. Cool. That's a good…
So I have literally like, um, auto-deployment on the main branch.
Yeah, yeah. And is it uh you don't have like any containers set up, right? Like you just have a single server running in Render?
Well, I do have a staging environment, so we push it there; we, you know, put all of our um testers on that. Right now, like this is something I'm actively getting better at, right? More testing before pushing to prod because when you rush it, you push a lot of bugs, and then it's annoying, right? So right now I need to like develop more of a feeling of prod health, like how healthy or stable is the production, and then figure out how much testing needs to be done on dev. And again, if it's like a simple change, you know, like I don't know, app version or whatever, you can push it without much testing, right? But um, yeah, this is something I'm getting better at, but yeah, basically I have a staging environment where maybe like new feature is there for 24 hours; if it's a bigger feature, maybe two days, and then we just push it to prod. But if if it's, you know, there's like annoying issue in production that a lot of people face, we just push it right away.
Yeah, that makes sense. Before your Render back end, like you just have a single server running your FastAPI?
Yeah, there is autoscaler.
Oh, you have that. Okay, great. Yeah, perfect. Yeah, so then you're set up—I mean, that's like a relatively simple deployment in terms of like the kind of things you could be doing with apps, but yeah, you figured it out. So yeah, I mean, look, uh, this is I guess the skill of being an entrepreneur is problem-solving, right? So like I guarantee you I will come into issues further on, but nothing is unsolvable, right? Of course. And that's going back to the value of the beliefs. A lot of people get an error or, you know, some problems like, "Oh my God, Stripe blocked me," or PayPal, you know, declined me; it's like, "No, it's that's not the end," right? Like, for example, I was switching my payments from Stripe to Paddle to handle um Merchant of Record, right? I didn't know that when I launched; it would have saved me like plenty of hours that I need to have a Merchant of Record because if you don't, you need to like do like compliance, all V8, all it's terrible, right? So Merchant of Record, if you're building a startup, definitely choose like Paddle, Lemon Squeezy, something like that. Anyways, when I was, you know, switching to that, I was like, they didn't even have like teams, so I couldn't even add team members to Paddle to handle like the customer support and refunds, right? So most people be like, "Oh my God, it's not possible," and they would do it themselves as the founder, right? No, what I did is you literally emailed Paddle like, "I need my guy access," it's like, "Okay, we don't have a feature right now." I don't care; give it give us this feature; okay, you need to do this extra compliance; we did an extra compliance, and it's like nothing; what happened? We need that; oh, I forgot to add him; was like, "Bro, see, like this is like so many steps," but as an entrepreneur, you train yourself to not take it personally, and you just push the next thing, and yeah, same with YouTube AdSense recently, you know, this I had a major issue where YouTube just took all of it, all of my revenue; I probably lost like five, six thousand dollars because of that, but uh, we managed to solve it, thankfully, and you know, on we go. So I think this is another thing that a lot of developers should figure out is like the not taking bugs and errors personally, right?
100%. Yeah, the perseverance really is what you're talking about, right? And I think I mean that is the core skill of software developers, especially today, is solving problems, right? I mean, that's that's all you do essentially. Now you're doing it with code, sure, so that's why you call yourself a software engineer, but at the end of the day, you have some problem; you come up with a solution; you solve it; it doesn't work; you fix it again, right? And you keep going. And the ones that are, you know, very basic, beginner software engineers, they only get to, you know, step one where they build something; they never get to the point where it breaks and, you know, they need to fix it and solve it. And um, yeah, that that's why, you know, we're always going to need someone with the title software engineer, whether, you know, you want to call it something else, that's sitting there all day doing that because the average person doesn't have the brainpower or the willpower to be able to do.
For sure. Yeah, like I mean, you know, as good as these AI models are, like you have to even—you have to know what to want, right? You have to write the…
Yeah, exactly. You're going to have to do something, even if it's very, very basic. Most people are not even—I don't want to say capable, but not willing to sit there and do that, right? And that's why you're going to always have someone in your organization who will do that for you. And even as me, you know, if I build some new software thing now, I don't want to build it from scratch myself; it's not a good use of my time. I'll hire someone who's a software engineer, not just a random guy off the street, to prompt the AI model to build the thing out, right? Like I want someone with that experience. So I actually want to ask you what's from your experience, because you worked as bigger companies, right? Microsoft, Shopify—what's the biggest difference from how startups work versus how these large companies work? Like if you had to speak to a startup founder, whether it's me or somebody else in the audience, what would be like the one most important thing the startup founders should take away, should do the same way the bigger companies should do?
Yeah, that's a tough question. Just to clarify, I didn't work at Shopify; I just got an offer from them. I've worked at Microsoft and a bunch of other companies more as like, you know, consultant, freelance type stuff. Um, at the big companies, the number one thing you notice is just like the bureaucracy, right? Like I mean, look, it's just how it is in corporate environments. In Microsoft, you're talking about like over 100,000 employees, right? You have orgs; you have teams within those orgs; you have sub-teams. Like you can go look at your org chart, for example, which is what I did one of the first days when I work there, and you can see like 15 levels between you and like the CEO, right? So in terms of just the chain of command and like who you need to talk to, it's just a much more delayed, right? Everything just takes longer because you're going through so many more levels of, you know, people before you can ultimately make a decision. And also the decisions that are made even at a small level have a massive impact because you're dealing with, in the case of the Python extension, over 20 million people using it. So even a small feature that I write, if that breaks, now all of a sudden we're flooded with thousands of issue requests, and you know, obviously it's not a good look. In terms of what startup founders could take from that, I would say one of the most important things is just really dialing in like the life cycle of software development. It's really easy at the beginning to like you said, you're just like pushing stuff, just getting it out there, and it's great, and I think you should do that, but you really want to, you know, keep in mind all of the automations and like the whole entire process. Like development is only step one, right? And then you have testing, and then you have deployment, and then you have feedback, and you have this loop, right, that you go through, and you know, I could explain it better in a longer video, but you want to consider all of those things and just start writing them all in from the beginning, so everything's fully automated, like rather than manually deploying these things out, manually running test cases; like spend the extra few hours and set up those pipelines to have it done for you because it just saves so much time in the long run, and it makes it a lot more professional, right? Now again, I know when you're just starting up, you want to get there quickly; I absolutely agree that you should do that, but as it starts to get a little bit more established and you have more users, you know, take a few days; don't build something new; just focus on optimizing the current system and, you know, ensuring it's secure and that it is just going to automatically deploy and setting…
It's set up in a way such that someone else can come in and start working on it. Because, especially in a startup, you have very high churn typically for employees. At least I've had that experience, and you're growing really quickly. So you want to be in a situation where it's very quick to onboard someone, and you don't need to, for example, train them on the entire repo right, and they can just come in and from day one start being productive.
Yeah, it's for sure like a wave, right? Like you need to release a new feature, but then you need to spend a few days fixing all the bugs even your testers didn't find, and you know, making the app more stable. For sure, um, that's I think another thing of like being a startup; you need to expect that, right? It's not like a—it's impossible to just always find all the bugs, no matter how diligent you are. But yeah, I appreciate that. For sure, we'll dedicate like more time to writing automated tests and stuff like that. Again, I, I don't know—you don't know what you don't know, right? And this is, this is I think actually another one of the best ways to use AI is to pay off that ignorance debt.
100%! You should learn while, like, you should be doing Vibe learning while Vibe coding. And there is this belief that you can only do one, right? And it's usually from like the insecure, you know, programmers that like refuse to use the AI tools, which I don't know, but like you can literally have the AI build something and then ask it two, three prompts to explain what it did, and you are learning as your Vibe building, right? And I think this is real—the real superpower—having, doing both at the same time as your, as the AI is building your, you know, app for you—whatever—learning how it works, right? What does this function do? Why do we need this? Do we really need that? You know, browse the web to see different options. Okay, seems like we really do need that. Explain that second half; I don't understand that. And just the ability to be able to ask questions and pay like optimizing to pay off your ignorance debt. I think that's probably one of the biggest things because I have the belief that you cannot really build like a startup or successful company if you're completely non-technical, right? Maybe if you're a billionaire, you hire like someone, sure, but like if you are a small fish and you don't have literally millions of dollars to hire professional developers, you need to be somewhat technical. So optimizing to pay off the ignorance debt—this is, I think, one of the best strategies.
Yeah, and I mean you're not the only one who has that belief. Y Combinator, for example, you know, famous for tech startups, they only bring uh startups in that have more technical Founders than not, right? So you could have like 50/50, or you have two technical Founders, one non-technical, but they found that typically, you know, the best balance is like two highly technical Founders. And also, I mean, I had this experience; I worked with someone non-technical, and I was working on my startup, and it's very different to work with those types of people because they think about things completely differently, right? Their focus is purely, you know, Marketing, sales, revenue, raising money, and not to say that's not valuable, but in your early days, really the product needs to carry the company, right? Like we can't be talking about, you know, deals and, you know, all this kind of stuff, and we don't even have, you know, an MVP built out yet. So having a, you know, a highly technical team is definitely extremely important, and you know, again, Y Combinator is, you know, a great example of that—that's incubated some of the best tech companies in the world, and that's, you know, a strict rule that they have now for their, for their companies.
Yeah, the product-market fit is definitely the most important thing. You know, people tend to forget that somehow, but um, again, it's a balance, right? Sometimes you really need to go with that flashy marketing feature, but you at least need to understand how complex it is, right? You cannot come in like, you know, these product managers or whatever—they just come in like, okay, let's do that, and then, then the dev says like, okay, that will take at least two weeks. Like, why? Simple, right? It's like if you are—but the thing is, if you are the tech founder, you can see if that dev is bullshitting or not, because that dev might say it takes two weeks, but if you have built a large part of your app, you will say like, why? I've built a similar feature in two days. You know, I did it this way, this way. Open that file, look into that F—it's like, oh, okay, maybe it will take five days, right? But like, this is I think why, as you say, why Combinator, they look for those tech Founders because you need to be able to spot [ __ ] and not just like automatically defer to developers. If he says like, this is going to take a month, it's like, no, I, I literally built a similar feature; it took me four days. And you need to know like when they're lying or where they're right.
Yeah, and I mean, realistically, the only way to be successful is to build an in-house, right? Everyone thinks, oh, I can just—I can outsource this to Nigeria, I can, you know, get all these developers that are, you know, way cheaper. You know, it might work for something basic, but you know, if, if your whole company is tech, like yours in this case, like it needs to be in-house. You, you can't outsource it, even though people think, you know, you're going to save X amount of money. So you need that technical expertise from the beginning, and you need someone who's there who understands and who can delegate. Uh, that's another, you know, kind of thing I'll give you—as you start to get bigger and you have more features and more things to do, the organizational component of it becomes very, very important. So just having even like, you know, you don't want to overload with meetings or things like that, but even if it's like once a week where you guys sit together and you triage all of the issues and you prioritize like what needs to happen for the next week—you set up, for example, Sprint planning. Like there's this whole kind of thing in software development called agile software development. You know, again, you don't need to go hardcore, and you want to always balance it, especially because you want to do things quickly. But I know for me, when our startups start getting larger and larger and larger and larger, and we had some users, all of a sudden there's just more and more stuff to do constantly, right? There's new features we want to do; there's bugs we need to fix; there's new things we want to rewrite, and you have this long, ever-growing list of, you know, technical debt that you need to solve, and you need to constantly be prioritizing that and aligning that with the team. And when you start to grow to more and more developers, you need to know who's working on what and make sure that multiple people aren't tackling the same problems. If you have two or three people, easy enough—you guys chat in the Slack channel, you hop on a quick call. Whatever—you have 10 devs, 20 devs, 30 devs, sub-teams—you know, the organizational component starts to become it a whole role on its own, and it's super important that you have someone leading that and giving direction to the developer because the last thing you want is to have a really good developer that doesn't know what they're supposed to be doing. And as you know, you'll eventually kind of probably transition from, you know, your main dev to more organizing the devs. It's so important that you give them the correct vision and that they know exactly what they're doing so you're not wasting productivity, which is an issue that personally I had in my startup when we started to grow out to some more devs.
Yeah, I think uh, I will run into similar issues for sure. You need developers that, you know, understand the vision, that respect your vision, that respect your decision-making. For sure, um, because as you said, like the, the engineers—they, they think about engineers like would be the coolest, you know, way or most complicated way to solve this, but uh, sometimes like the simple solution is the better, right? And like you need to look—so recently I had this, right? My back-end developer, who's great—super advanced guy—he thought up like what would be the most scalable architecture, which is the correct way to think, right? I don't have that skill set, but then when we were like discussing on a call, it was like 90 minutes. I was like, we can sit here for hours like, you know, discussing what the best architecture is. Why don't we open the database and look how people are using it? So that's what we did. We opened the DB, like, oh, the, the—so like we were designing like multi-agent systems, say like if a user says like, you know, browse the web, create a task based on that, and then update three other tasks so that he can do it, but like then we open the DB, it's like, oh my God, even like the top 10% of users, they're never asking this, you know? They always say like either change, create one task, or maybe like, you know, update one task or browse the web. They never do these like super advanced prompts that we were optimizing for, but then we sacrificed speed for a super simple prompt because we had like a structure JSON where it was a confirmation field, then hidden reasoning, and then the actual answer. But if you ask—if you use AI, both how me and you use it—most of the times you just want an answer; you don't want it to do something fancy, right? Like open the web, browse the web, do deep research, or anything like that. Most of the times you want a quick answer. So when I realized that, I was like, okay, this is why you need, you know, someone as an entrepreneur and the dev to kind of balance it out because if you just let the devs do everything, they optimize for scalability and stuff like that, but then don't optimize for how the users use it. But if you only optimize for the users, then you will run into those scalability issues where you need to rewrite the entire back end. It's like, whatever—that's a nightmare, right? So again, it's, it's a balance, like everything, but yeah, I think I appreciate you saying that because for me, this is a skill I need to learn for sure—as like having more control over what my developers are doing and making sure they don't like run off and do some cool things they think it's like, no, we're doing this.
And as the dev—speaking as one who, you know, is a developer mostly—and if I come to a company, that's my role, right? Code—not necessarily the vision stuff. I don't want to have to think about what it is that I'm doing in terms of like, you know, the overarching task or like the vision of the company. You know, if I'm a solo founder, okay, that's one thing, but in my case, I was working—you know, we had the non-tech guy who's supposed to kind of lead the charge of the vision, what the app's going to be, and then me just implementing it as a developer. You want someone to come to you and say, here's the spec, this is exactly what I need; you go figure out all that complicated crap and build it, right? Like that's what you want as a developer. If you start giving the developer like really vague instructions or saying, oh yeah, maybe we need this, maybe—oh, you figure it out—their brain is context switching between two very, very different things, and it's very hard to be productive and actually get something done. The best devs absolutely suck when it comes to the entrepreneurial stuff. They're really good at sitting down on the computer and coding out solutions and architecting, but if you tell them, you know, make a new, you know, $5 million company, they don't even know where to begin because their brain doesn't work like that. Very, very technical people, engineers—they need direction, instruction, and structure, and you need to provide that to them as like the company founder. And that was one thing I was trying to do with my devs, but also what I was lacking from our founder because at the end of the day, I'm supposed to be the lead dev; I'm not supposed to be focused on, you know, the whole vision of the company. And when your brain is constantly switching between that, it's very difficult to, you know, be productive and get stuff done.
I couldn't agree more. Literally, my experience confirms this, the best, right? Like the best developers, they just like to code, right? They want to spend 10 hours a day programming. They want to see like, okay, what would be the right marketing angle for the demo to launch this on Twitter, right? But like, as the founder, you kind of have to understand all of that—it's like, okay, this feature will take us a week, but it will be really worth it. You know, this feature might take us two days, but nobody cares, right? So like, that, that's the job of the founder. So this—I'm glad you mentioned this—the agency, right? You have no idea—multiple people told me like, oh, you know, why didn't you just hire an agency at the start, right? Like why did you do the coding yourself? I agree; if you need to do something, you need to build an in-house. Can you speak more on that because so many people are like delusional that they think they can, you know, outsource to an agency and they'll build their entire startup, all of their software, and it just comes in—it works perfectly.
Yeah, I would say if you want something very specific built that's not going to change and require iterations, okay, an agency may potentially work for that. If it's just one thing, it just has to meet this requirement, and then it's done. But you're talking about a startup, right? Constant iteration is the definition of startup. You can't be dealing with these layers of communication chains, for example, right? Like that alone is going to slow you down so much. So you're—you have your agency, you have your contact at the agency, you have the dev team of the agency, which you don't even get to talk to—you don't even know their names, you don't even know who's working on it, and you probably don't even want to know that to be honest. And so now, anytime you want something done, you have to communicate extremely clearly to this person. This person isn't critically thinking; they're not telling you, okay, we should do this, we should do that; they're just doing whatever you tell them. So you don't get like an employee-like feel; you don't have any culture; you just have this, you know, random company that any point in time can screw you over if they want to, can change their prices. If you need something fixed, you're completely reliant on them. There's just, you know, every negative you can possibly think of is what happens when you have the agency. The only advantage is that usually it's slightly cheaper, and you know, you don't have to go hire all these devs, and maybe you can initially start doing it faster, but as things start ramping up, it's just an absolute nightmare. I mean, look, we're talking about building a tech company here. You can't build a tech company when you don't build the tech, right? Like you have to build it yourself, in-house. And I mean, again, Y Combinator—famous example of that—they say all of those things. Anyone who runs a big tech company—heroes—all of these guys, even if they're not technical, they've learned from that experience, and they know when you're building something that's going to be constantly changing, you need it in-house, and you need to understand it deeply as a company and have, you know, your culture, processes, all of that around it.
It's funny you mentioned Horowitz because he had that issue. Yeah, I don't know if you know the story, but like he, when he was doing his first, um, you know, software company, he, he basically hired an agency to do everything, right? And then—what you exactly what you describe—they screwed him over, right? They raised the prices; they like locked the code so he didn't have access to the code, right? Yeah, it's not possible. Like, at least it's like—I would rather die, honestly, than to have an agency build my startup. Like, even just imagine that—like, you know, communicating is like explaining the urgency—like, you know, production is down; we need to fix it today. Oh yeah, our development team is on his vacation. Like, no—like, that is just—that is just a nightmare scenario. And yeah, it's crazy how many people think that's possible. And again, maybe if you need like something super specific, like some small automation or like some specific Chrome extension, whatever, it's possible, but like anything more serious, you need to understand it yourself; you need to get your hands dirty. Even if you're not a technical founder, you need to at least understand some basics to hire the good devs to build it for you. For sure. I mean, you just have no control, right? That, that's the main thing—like it's your—the whole thing is tech; it's software—I mean, that's the product—and you have no control over your product, so it's just—I mean, it's a no-brainer, right? You can't do that.
Now, if you're not technical, it's intimidating—how do I build a dev team? How do I do this? And honestly, you're going to have to get technical to some level, as if you want to build a tech company as a non-technical founder, you need to know something, right? Whether you have experience as a product manager, whether you're, you know, learning a little bit of dev stuff, or at least getting the high-level concepts. Any tech company that I've seen be successful, even if, you know, one or two of the founders are not technical, they've adapted, and they've learned some of those skills. They can communicate at the same level with the lead engineer, right? You don't need to have 10-plus years of experience, but uh, really good examples are, you know, a friend of mine has like, you know, the product manager—it's like one of the uh, what is it—non-technical founder you could call it—and then, you know, technical founder worked at Microsoft 10-plus years who's doing all of the coding. The program manager doesn't touch any of the code, but he knows the language; he can communicate, and he can, again, share that vision in a way that's very structured for the engineer to then go out and focus on what they're good at. Also, the engineers need to respect the person who, who says those things, a lot—especially at the bigger companies. I feel like a lot of the times the engineers don't even like respect the product manager, right? They just say random stuff; they join the meeting; they boss everybody around; they have no like concept of how difficult it is. I think this is like one of the biggest dangers of building a startup, especially if you're not like from a senior engineering background. You need to, you need to be like balancing between—sure, you cannot be spending three hours of your time fixing like a UI button, but you also need to like have enough technical understanding of the code base so that if you needed to add a feature by yourself, you could do it. And I think this is like one of the most important things that I learned as building a startup is that, you know, especially as I started hiring because I, I got to like 5K MMR without any devs. So as I start to hire, I need to realize like, okay, I need to control myself from like going to the UI or, you know, fixing like some small bug, spending like two hours on it because my time is not worth that. However, I do need to still understand like what's happening—you know, there are these new files in the last Git pull; what, what are these files? What was changed in these files? And yeah, this is I guess one of the—one of the biggest pieces of advice I could give to people starting their startup is really balancing between what's not worth your time but still ensuring you still have enough technical and that you get your hands dirty, right? Because like you said, like the amount of respect you gain from your technical team when you're able to do that is massive. And the worst thing—the last thing that you want in an early-stage startup is someone who comes in but won't get their hands dirty, right? You don't want this like crazy visionary who like will never actually do anything. A lot of these, you know, like Fortune—like maybe not CEOs, but you know, your like directors, executive type people—like sure, they're extremely valuable to these bigger companies for a reason, right? Because of their guidance and, you know, the decision-making, but when you talk about an early-stage startup, you don't just want someone who's going to sit there and, you know, boss commands and tell you what to do; they need to actually go, you know, down to the floor, right, as an analogy, and do something; otherwise, the team just doesn't respect them, and you're just not going to get the benefit. We made that mistake at our startup—or almost made the mistake—of hiring someone like that who was like director level, very experienced, you know, he's gonna get a bunch of equity, all this kind of stuff, but we started to realize, okay, we bring this guy in now; we need three other people just to implement the kind of stuff that he's going to suggest because he won't do it himself; he's not going to go out there and build these things; he's just going to, you know, give the guidance that's valuable at a point but not super early stage, and that can really mess you up.
I mean, I would say this is probably one of the main reasons why Elon is so efficient—of course, like he's willing to get his hands dirty, sleep on the floor, you know, go to the company, go below the floor, like wire cutters—what—and everybody working for him knows that, right? So it's not like they can just do something and say like, okay, this is going to take two months. It's like, what about that? It's going to take two months, right? And he's going to fly there on his private jet; he's going to fix it in person, stay with them like all day long. And yeah, this is—this is like huge, and I, I don't know—I think it's like a lot of the startup Founders think they like—it's going to get easier or something like that, or like they can get—it's the same temptation as having the agency, right? It's tempting—like, okay, I'm going to hire this agency; sure, I'm going to pay them some money, but like they're going to take everything—it's like, okay, good luck, right? And it's the same as scaling the company—like you might think like at a certain size you just can chill out and, you know, ski in the Alps, but like some from time to time, at least your team needs to understand you have that capability, right? Yeah, like even if it's not worth your time, it is worth your time for the, like, morale of the team to like once a month log in and just overnight implement some feature. Your developers wake up; it's like, what? Who made this? It's like, oh, it's the founder. It's like, oh wow, okay. That's—and like that reminds them of kind of, you know, why you are where you are, right? Because a lot of times, you know, senior devs—oh, I could run this company better; I have these—like it happens, right? It's natural; it's just human nature. Um, they kind of need those reminders—not in like—again, you're not showing off; it's just purely saying like, I'm here for a reason; I'm building this stuff, and this is why you should be listening to me.
I'm curious if we have time—what's your take on raising money as a startup? Because I just came from San Francisco where like everyone and their mom is raising three, four, five million for like pre-revenue, you know, AI tech startups, uh, and it's a very interesting culture—everyone's like, you know, 25, 26, whereas you're doing a completely bootstrap, right?
Yeah, correct. So I'm—this is a nuanced conversation, right? It's not like I'm completely against raising money, but I think—see, to be honest, I, I despise the San Francisco developers—they just raise money; they are not real entrepreneurs; they have no experience in business. Like, how, how do you raise money pre-revenue? That concept is like insane to me. But yeah, I'm open to raising money. Actually, recently I talked to the co-founder of Loveable, which is the fastest-growing startup in Europe, M. So he gave me a really good advice; he said like, push it as far as possible, and then like when you need more money to hire developers or when you cannot like bootstrap it, then raise money, right? Like currently I'm at like 12K MMR—like if I raise money, I would either have to give up a lot of percentage or I would just get like, like, you know, I don't know, 50K, 100K, 200K—like what's the point of that, right? So I'm going to wait; I'm going to push, you know, my self-funding as hard as much as possible, retain 100% of the stock as much as possible, and then hire eventually when it makes sense—when like, okay, I'm running out of money maybe, or the like—maybe some feature clicks and it's like blowing up, and I really need that infusion, but I won't give up like 40%, right? So I, I'm open to it for sure, but I'm not, not in any rush.
I think you're in a different situation though because your startup is designed to make money from the get-go; it's not one of these—I made it like that.
Yeah, of course. I mean, you designed it like that, which, you know, is a compliment. Most startups are designed to capture as much market share as possible, lose and burn as much cash as they possibly can, and then eventually, once they've dominated market share, start monetizing, right? You look at like Uber, for example; you look at Instacart; you look at all these huge startups. But for all of these you mentioned, there's like thousands that didn't make it—of course, I'm not saying that they did—also, I'm not advocating this approach; I'm just saying like in Silicon Valley, right, that is like how startups are typically designed, and it actually hurts you valuation-wise to have revenue. I know it might sound crazy to people listening to this, but you—at 12K MMR—like first of all, that's impressive; that's a good amount of money—we're talking about, you know, $150,000 per year business—but if you go present that to a VC, they're going to look at that and say you're only making 150K a year, whereas if you have nothing, the possibilities are endless of what it could be or what you could make. So I actually had a friend try to raise money recently, and she said what hurt her the most is that she had about 8K uh, MMR, and because she had that, the company was like, h—you know, we're going to wait a little bit, kind of see what it gets to, whereas if she was pre-revenue, then the poss—you know, she can sell it—oh, we're going to have us—going to be this—and by the way, the valuation she's looking at is a $10 million valuation for a $600,000 investment. So just your K MMR. Yeah, but now that she didn't get that because of the 8K MMR, but that's what she was originally looking at. I know it sounds insane. I recommend at some point in your life, go down—I need to update my bio as like multi-millionaire—no, but I'm saying like literally you should just—if you have some time because you're in this startup world—yeah, take a trip to San Francisco and go in some of these office spaces and talk with some of these guys purely for just inspiration and like to understand what's happening. It's different if you're in Dubai, but these guys are raising literally pre-revenue—they have an idea and they have an impressive technical team—that's it—that literally—that's it—and they're raising these $15 million valuations, taking two, three, four million. Um, it's insanity. So yeah, I don't know—I think like I'm not going to rush into it; I would do that for the experience for sure, but…
Like, uh, honestly, I want to work with like Mark Andron or Peter Thiel, people who actually could give me solid advice. You know, like there's like thousands of people who could give you money, but most VCs are useless. So I think like, if you don't have revenue, you don't have product-market fit. If your startup is growing in revenue, there is a sign of product-market fit. So yeah, I mean, if you cannot self-fund, maybe you need investment sooner, but personally, I'm going to, you know, hold it out.
Yeah, yeah. No, I agree with you. I think what you're doing is great. I'm not advocating to go, uh, raise money; it's just an interesting world in this, uh, kind of startup culture, and money just gets thrown around like crazy. And also, like you said, you know, as soon as you raise money from a VC, all of a sudden you're downgraded to an employee. Like, I would retain 100% of the voting shares. Yeah, but I mean, even if you can raise on a SAFE, you can raise on whatever; as soon as you take someone else's money, there is a slight mental shift, at least from what I've seen from most people, where, you know, at least you're going to have to check in: "Oh, what did you do this week? How much did you get done? Oh, why are you—no, why are you paying yourself this amount of money? You should be paying yourself this amount." Again, you still retain control, especially if you're raising on something like a SAFE, but the dynamic changes, right?
For sure. Yeah. So last thing I want to ask you: tell us more about your coding program, because you literally help thousands of people go from beginner developers that are like, you know, 100K could get hired at—
Yeah, for sure. So first of all, what I always say to people is that, you know, you don't need to pay me; I have everything completely free online. If you want to do it more quickly, the best way to do that is to go through a structured program, right? Doesn't need to be mine, but mine, for example, it literally covers literally everything you would need to not just become a junior software engineer but actually stand out in the market—all of those niche skills that most devs don't actually get. The way that it works is you go through a software fundamentals course, which is taught by me. Uh, it's many hours of content; it will take most people four or five months to get through, which is just the reality of learning all of these skills. I'm not, you know, promising you're going to finish it in two weeks, like a lot of other people do online. And then you actually go through a specialization program, taught by an expert in one of the three specializations that we have: so front-end, back-end, or DevOps—three different people, all big YouTubers as well. Uh, you get those specialized skills, and then we help you craft your resume, apply to jobs, all of those kind of things. So that's one program that I have. Um, yeah, that's—you know, with people are watching, go watch a few videos on YouTube. If you like those videos, definitely upgrade to the program, of course. Yeah, there's a bunch of free videos in there, too. You can check—everything you have more free videos than anybody on the platform. Yeah, literally, I have like what, 1,300 free videos or something. So, uh, yeah, if you don't like my teaching style, you'll know pretty quickly, but if you do, then obviously you can hear my voice for hours—about hours in the course.
All right, man. Thank you for coming on the podcast, team. It was a pleasure.
Awesome. Thanks so much. Would like to see.