How To Build A Startup As A Non Tech Founder

For those of you who don't know, the Founder Institute is a very large incubator. We have operations in over 110 cities worldwide, and what we do is we help you to take the first steps of launching your dream company, helping you find co-founders, helping you plan the business, helping you do all the things you need to do to launch your dream company. Right now we're actually recruiting in dozens of cities worldwide, so if you're on that process of building a startup, you may want to go to fi.co and see if you can join a program near to where you live. In terms of my background, I'm a serial entrepreneur. I've started 9 separate businesses. Most of them have done well, creating over $2 billion of shareholder value. I've been through the rigor of launching a business. There have been times when I've been more technical and there have been times when I've been less technical. So again, back to the topic today, how to build a startup as a non-technical founder. You might be struggling to get your startup off the ground and figuring out how to build it and you don't know if you have the skills to do so. So what do you do? Do you take a training program? Do you find a co-founder? How do you figure out what you need to do? How do you figure out what needs— how to do it? But, you know, in my experiences, non-technical founders can be great. You know, I would consider, as I said, myself non-technical multiple times in the past, and that's been awesome. For me building businesses, just as right now I'm more technical, and that's also been helpful. So we have a special guest today. I'm going to bring him on screen right now. Let's see, Wei Ding Lu, are you there? Great.

Hi everyone.

Can you say something so we can track you down?

Yes, can you guys hear me well?

Okay, maybe I can't hear you, but I'm having a technical difficulty hearing you. Say it again.

Yes, can you guys hear me well?

Let me try a separate earpiece. Ah, that's better. My earpiece malfunctioned on my side, and that even looks somewhat cooler. Welcome. So why don't you give us a brief background on yourself, and then what we'll do is jump into some structured questions about being a non-tactical co-founder. Please introduce yourself. Sure, awesome.

So hi everyone, Wei Ting from CodeMentor here. Just like Adele, I'm sort of technical, sort of non-technical. As you know, software is eating the world and learning how to code is becoming mainstream. And CodeMentor is the platform that provides on-demand expert help for software development. We connect you to expert developers for live help and long-term mentorship via screen sharing, videos, and chat. So you can think of us as the Uber for live coding help, or a live version of Coursera. And if you're an entrepreneur, I guess we all are within this webinar, you can think of us as your on-demand CTO. So our network of 3,000, over 3,000, many experts include already book authors, creators of popular open source libraries, top Stack Overflow users, and even engineers at top tech companies such as Google and Amazon. So we've been working with a lot of aspiring entrepreneurs, early-stage startups, and YC and Techstars startups to help them build faster and launch their product much faster with on-demand coding support.

So by the way, this thing is my hand. What's that pink thing floating around on screen? That's actually sort of fluorescent— I don't even know—

red.

But yes, anyway, that is my answer. Don't be distracted. So let's jump right into the topic. I know you've also bootstrapped business in the past. And as you said, you're sort of technical and sort of non-technical. Why don't we— I guess you could say that about almost everyone today. They're a little bit technical. They're a little bit non-tech. You know, and I think everyone falls a little bit on the spectrum, right? You know, some people may program a little bit. Some people may, you know, know, be masters of Microsoft Excel. Some people might be a, you know, power internet user or whatever. And, you know, so I'd say there's technical proficiency today is ubiquitous. But there are some differences between people. Now, so jumping right into it, let me ask the question, do you think anyone with any level of technical proficiency can start a company today?

Right, definitely I do believe so. Even though, like, if you don't even look at guys like us, right? You look at a lot of very experienced web developers, if they Even though they already have tens of experiences for web development, how about mobile? The mobile is an entirely new frontier.

Right, mobile coding is way different than web coding, exactly.

Exactly, I tried to pick up Objective-C, I still cannot write a single line of iOS app myself. So I mean, do they not start an iPhone app just because they don't know? How to write an Objective-C code. No, they just figure out a way to get things done.

Right, so I think—

Yeah, sorry, finish your point and then I'll— I was just saying that not being able to code is definitely not an excuse for you to not start a company.

And I think that's a really great point, which is why I just wanted to quickly interrupt on it because So you're right, no matter what, as a founder, you're going to find yourself in a position where you can't do what's needed to build the company. Even as a technical founder, you may not know finance that well, but you're going to have to produce a financial report. Or, or you might not know Objective-C, but you know how to web program. So no matter what, as a founder, you're going to run into trouble not knowing an area of the business that you need to manage, right? And I think that's a very good point. So let's use your example of you need an iPhone app, and maybe you know something, a little bit of HTML, or you're completely non-technical. What do you recommend that someone does? What would you say? So I've got to build an iPhone app. I don't know Objective-C. I'm a non-technical founder.

What do I do? [SPEAKING SPANISH] So totally depending on your personal skills level, for this particular question, Since there's more and more interesting technologies that enable you to write iPhone apps without writing Objective-C nor Swift. For example, you can write JavaScript code in order to build a mobile app. Now, for example, that might be an efficient way for you to build an MVP. It might not be efficient, it might not be sufficient for you to to have a full-blown working prototype that supports tens and tens of millions of users down the road. But if you focus the scope to be a working prototype, that should be more than enough. So there's a lot of quick, short paths that enable you to do something. But there's parts, for example, that enable you to build something very quickly on the mobile platform. That's a great—

so essentially, let me paraphrase what you're saying. If you're a non-technical founder or semi-technical founder and you want to launch a business, the question is in fact, what are you launching, right? And if you can pare your scope back to that first MVP to prove a point in the business, you could probably do extensive research or self-training in order to create that MVP. So either You learn JavaScript and program it self, or you make some sort of mockup in HTML that works on a mobile device. Maybe you find a mobile development platform that has the pieces you need to get the functionality. So you don't necessarily need to become a master at Objective-C. You just have to set your sights correctly and find the tools that best suit your need. That's a very interesting point. But so let's say you get that MVP up, essentially the scrappy way, right?

What is—

like, what do you— now it's sort of running, it's kind of working, but you're not technical. What next? Because now I can imagine you get in trouble, right? Lots of people using it. All of a sudden now, what do I do? What would you recommend you do then?

Right, well, it totally depends on how— at what stage you're at at that point, right? And how well your MVP has done.

Yeah, let's assume that for the purposes of this discussion and everyone on the webinar, let's assume that it's at the very beginning, like day 1, set a brief, you know, within the first few days of starting the company, set a brief MVP, got started, all this is very early.

Right, so I guess the first thing is, it's all about like build your product and talk to users, right? So after you show your MVP, after you build your MVP, the next step will be, well, show your MVP to as many users as possible, and continue to build on the product based on the feedback from real users. Since in the very beginning, you as a startup CEO is essentially the product manager, of the company, so you own the product. There isn't really a company, right? The product, the MVP is a company. So it's all about focusing on essentially 100% of your attention, I would say, on making the product as best as possible for this group of users that you'll be targeting.

So, and I agree with that, and so let me paraphrase again. Probably then when you're picking your initial system or out-of-the-box software or whatever you can in order to build the MVP, you should A, ensure, or number 1, ensure that it has enough flexibility that you can tinker with it as you learn things from the user, and then number 2, you should also, you know, try your best to familiarize yourself with everything and everything about it so that as you need to tinker with it, you can do it very quickly. So make sure it has the flexibility and make sure you have the knowledge to change it as new user requirements are coming in. Do you think you need a technical co-founder in these very early days, or do you think you can to pilot through with a software platform or some basic technical understanding on your own?

It totally depends on whether you can move fast enough, right? If you, by doing everything by yourself, if you can still make daily, if not weekly, if not daily iterations on your product based on user feedback, if you can do that however way possible, then yes, you can definitely do this by yourself. You do not necessarily need to have the technical co-founder. I guess people are talking about whether I should outsource my code to some random freelancers on some online platform. I personally think the number one reason why most of those cases will fail is that the iteration cycle is just way too long. So can I—

let me just quickly cut in for a second because I was reading and engaged and not paying attention. My team came in and said, wait, you need to define Define MVP. So we've been talking about MVP and these fast iterative cycles. Let me just take a step back. And by the way, if you have questions, there is a question area. Ask them. If I don't get to them, my team will nag me to get to them. So an MVP stands for minimum viable product. It comes out of a methodology created by a gentleman named Eric Ries called Lean Startup. So if you're— so of course, non-technical founders probably don't know any of this, which makes sense. So essentially, let me just give a one-seconder on Lean Startup and add anything that you think I'm missing. But Lean Startup is a scientific methodology to release a product to the market whereby you do iterative releases, show it to customers, get the customer feedback, improve the product, and then show the improvement to customers. And you keep doing that in a cycle until you build something that the customer really wants. And in order to do that in a rapid way, you create what is called an MVP or a minimum viable product that is the least amount of functionality to prove a core thesis that you believe the customer needs. Would you like to add anything to that definition?

Sure. I remember that the founder of Pinterest, Ben Silberman, once said that— talking about MVPs, right? The problem with building an MVP is that oftentimes you don't know how minimum. And how viable the product should be. Let me share like a personal story, right? So in CodeMentor's case, so CodeMentor was founded 2 years ago by myself. So our MVP was essentially a landing page built by yours truly and a semi-working prototype behind the invite wall, right? So what I did was my MVP was I built a seemingly good-looking landing page in the first place. Well, since CodeMentor is a two-sided marketplace, right, so we need to find expert developers to sign up to become mentors, and we need to have users who will come in and have paid sessions. So what I did first was since I have no idea whether this is something that developers would want at all, what I did was I first, I essentially cold emailed a bunch of friends who are developers, as well as relatively well-known developers in the open source community. So I cold emailed them and just say, hey, this is Weiqing from CodeMentor. I'm building this stealth mode startup called CodeMentor. Here's our landing page. Would this be something that you might be interested in? The response rate to my cold email was close to 50%. At that time. So that was— if you think about it, the early stage of a startup is all about building the product and talk to users, right? In a very minimum form, I was doing both. That, in hindsight, probably only took me like over one weekend or two. So I, with a landing page, I got some critical feedback. Yes, this is something that developers would love to use. As mentors, and I continued to build on that, and I remember that, and then one month later, we got picked up on the front page of Hacker News, and we got a wave of even more users with even more great feedback. At that time, it was only a landing page and a semi-working prototype behind the lotus wall.

So let's go through the landing page. Because Andrew and some others— Larry has asked, does the MVP need to function? What are some tools? People are asking a lot about tools. So there's LaunchRock, which does like one-page landing page pretty nicely. It also does some promotion. There's a service called Unbounce. Unbounce also does a little bit more advanced landing pages and A/B testing. If you want, you can use some— something as simple as WordPress, which is the blogging platform, to create a landing page. What did you use to create your landing page?

So at that time, I also thought about using LaunchRock, but I wanted to have more flexibility at the time, so I actually built everything myself. That was my personal opinion.

Yeah, the advantage of LaunchRock is that it will automatically promote it for for you, excuse me, so you get a bunch of users without doing any work. Another thing Larry was asking, does the MVP have to function or is it sufficient that it's just a mock-up that shows some wireframes, etc.? So let me take a stab at that and then please chime in. It's not about whether it functions or not. In fact, it sounds like what you had built was what's called a concierge MVP. Whereby you have a landing page, someone signs up, and then you in the background do the work to deliver the service manually. There's no massive amount of technology. It could be an Excel spreadsheet, it could just be you with a piece of paper doing the work. And that's generally called a concierge MVP because like a concierge books you a hotel or restaurant you do the work behind the scenes to make the thing appear to function for the user. But I would say a lot of MVPs don't need to function. They can be a concierge MVP. What would you like to add to that?

Yes, exactly. So as Paul Graham of Y Combinator likes to say, like to suggest to startup founders, that in the early days you should do things that do not scale. And there's a lot of famous examples for this, right? The founders of Airbnb famously flew over to New York on a weekly basis to personally take professional photos of the early Airbnb hosts back in the days. The founder of Stripe famously helped other fellow developers install Stripe. By taking away their desktop computer and do everything on themselves. The founder, they're the team behind an old company that, well, another startup that was acquired by Google, Aardvark. They were acquired by Google for $50 million. It's, they, well, long story short, they On the surface, it seems like they have this fancy algorithm that do a lot of magical stuff in the background. But in reality, everything was actually done manually. Also in our very early days, right? So every matching on CodeMentor was done all by myself. So I just hustled a lot to make that business happen.

Let's go on to— so now let's go on to the next level of question, which is like, OK, so I've got a minimum viable product out there. I might have used an existing piece of software, landing page technology, or even Excel to deliver the initial services, and I'm mainly non-technical, okay? How then do I— and this is still very early days, maybe now it's a month or two after the company started— how do I grow my technical technical skills, what programs should I know, what would you recommend, like base-level knowledge for a founder of a technology company?

I'd love to hear your thoughts on that. Sure, there's tons of many, many different resources online that you can take a look, right? There's a lot of free resources. The most obvious one would be something like a Codecademy. Everything's free, it's interactive, you can go on and learn a few hours of JavaScript all by yourself. And down the level there's the Treehouse and CodeSchools of the world where you can pay $25 a month to learn any technologies that you want with prerecorded videos, recordings, right? And of course, Update online resources. There are meetups that you can attend. So if you live in major tech cities, you can go to a lot of meetups and meet with a lot of fellow developers who can be potential co-founders, ideal co-founder candidates for your early-stage startup. If you don't live in big tech cities such as the Bay Area, you can also go to some online resources, right? Something like a co-mentor, shameless plug here. You can meet with a lot of developers and get on-demand help. I personally believe that it's like learning by yourself can be awesome, but the thing is that you don't know what you don't know, and even worse, you might be heading into a wrong direction without yourself knowing it. So if you can have expert guidance, whether it's your friend or your colleague or someone who you meet at meetups, if you can have like an experienced developer to take a look at your progress on a regular basis, that'll be much helpful.

Yeah, so when I started one of the businesses right before Founder Institute, I basically saw a need in the market and I learned to program building it myself, sadly. But it came out okay. So there are tons of resources online, resources like Codementor. But I would say, generally speaking, as a CEO though, you don't really code. I would imagine today, how much coding are you doing day to day?

[Speaker:MIHAI_IONESCU] So personally, yes, you're right. I don't code myself anymore. Make changes from time to time. Because I guess the key here is that even though like as the company grows bigger and bigger, like you don't need to do the daily coding by yourself, but sometimes you just want to make like super quick and minor product changes, right? Like if you can code, it would just take you 5 minutes. If you do not know how to code, you like talk to another developer, you need to stop what he was doing It just wastes more time for the entire team. So it's like learning how to code to some degree can really go a long way.

So let's drive into that. I mean, you probably should know a little bit about the primary language of your product, right? And then that's dependent on what platform or technology you're using, right? So if you're on a mobile primarily on Apple, then, you know, Objective-C or the like is something that you should have some sense of. Or if you're doing primarily web and you're making advanced web technologies like spreadsheets or whatever, you might want to know some JavaScript. So basically the language you should have some basic familiarity with is dependent on the product. Would you agree with that?

Yes, definitely.

Now, I would additionally say that for everyone out there, considering that you're going to be a founder, some good knowledge of basic project management principles is a must-have, right? Because if you don't know how to speak to developers, if you don't know how to set deadlines, if you don't know what a product development sprint is, you're going to be lost in the lingo of the people working for you. Would you also agree with that?

Yes, definitely. I'd like to add that by knowing, by understanding how to code to a certain degree, it actually can go a long way and can feed into being a better project manager. So like, if a developer says, well, this feature would take 2 weeks to build, if you know how to code, you can kind of gauge whether that kind of feature will really take that long or not. Or maybe there's a much, much shorter path to that, because sometimes developers, without you telling him exactly why you want this feature to build, it's all about prioritization, right? So maybe the feature does not need to be that full-blown at this stage. Maybe there's a minimum viable feature there. Like, had you not know how to code, you wouldn't be able to know any of those. You wouldn't be able to communicate, um, in Spanish with your developer.

Right, right. So you can actually— so let's talk through the basics of project management for these guys on the call today. Um, so basically, whenever you work with a team, 'Cause eventually what's gonna happen, so now you built your MVP, it did pretty well, you've learned a little bit of technology and you're bringing on a team to help you. And ideally this team is either in-house or it might even be out of house in the beginning, a vendor or even a contractor. You need to describe to them what to build. So that's usually called requirements. And what you were just saying, which is a very good point, is you can't write good requirements if you don't have some understanding of the technology. So, um, now let me add some other things. Generally, you'll have a— all modern technology systems have a front end, which is the thing that the user sees on a website, software, mobile app, etc. And it will also have a backend that exists on the servers. This is the database, the various application layers, etc., that process the data to go in the database and present information to the frontend. So a lot of times when you write requirements as a novice, you're only describing the frontend but not the backend or the database or everything else, and you need to rely on your vendor, partner, or employee to figure all that stuff out, which can be dangerous. So again, you've got your requirements. The requirements describe ideally the front end and the back end. And, you know, in theory, we're providing these features that are very clear. And so, again, knowing a little bit about technology is helpful. So back to you, given that framework I just outlined, and I'll go into what a sprint is and some other things in a moment, what are— if you're writing these requirements, are there any things you recommend a novice should know?

Personally, I would just recommend any novice to keep the scope to be as small as possible, because the number one problem that I see a lot of early-stage startup founders that will My vision is like this super huge product that does XYZ and more that will take 2 years to build, right? That's like the old waterfall approach that is not agile at all. The number one advice I'll give is make the scope as small as possible. If this— if the first version needs to be released to real users within 2 months or within even less, 1 month, like what would the core feature look like? It also helps the—

Well, like Tinder, right? Tinder has one thing: yes, no, right? So that's it. Like, you know, they're like, show a picture, yes, no, show a picture, yes, no. I mean, you can— it's a hugely successful product with really one simple thing, right? So finding—

I think your point is very valid.

Don't build a million other things, try and find that one super simple poignant thing that will make your product work or will make it fail.

Is that— that— more features would not make your startup more successful.

If anything, it could confuse users about what the point of the product is, right? So if there are too many features, it's like The end of the day with Tinder, it's like yes or no, and that's the main decision point, and that's the main feature, if you will. I think that's really sage advice. Now you referenced agile, so let me just— there are different ways that programmers write code. Agile is one of them, and one of the things that is commonly done by programmers is they take a period of time So there are two ways you can build something. You can say, I want to make this feature, or I want to achieve as much as possible in a period of time, right? So if you go on a time-based approach, that's called a sprint. And then average sprint is about two weeks. So a group of developers or a developer will say, hey, I'm going to do a sprint for two weeks. And we'll see what I can make in 2 weeks. And they sort of try to get a certain amount of stuff done. Conversely, you could say, hey, I need to build this feature and I'm going to get it done as quickly as humanly possible, but it's more important to get the feature done than the amount of time. That's sort of oversimplifying a lot of like development philosophy, but as you referenced Agile, is there anything you want to educate our listeners about development philosophy?

Well, I guess for early-stage startup, right? Again, my personal view is that you should always move as fast as possible, right? Do you really need that feature? Can you not just push everything out of the door in 2 weeks? Yes, that's my personal philosophy. And also, if you want to work with any developers, whether it's in-house or or outsourced freelancers, just try to have like a daily scrum meeting, if you will, just to—

Okay, scrum is another term. Right, so scrum is another term that people use in development where a developer will stand up at the beginning of the day and just announce to the room issues, things— you might do a better job of explaining it to me, but it's a type of development methodology with very quick updates updates at the beginning of the day by all of the team members. Do you want to add to that?

Right, and I think from the angle of a non-technical founder, you think of it, it's really a very convenient way for you to see what your developers are working on and whether they are being stuck with irrelevant issues or not. So during a Scrum meeting, the developers will essentially announce to the team or to you what he is working on, what, is there any trouble that he's facing right now, and what he's planning to do, or what he has done, what he's working on, and whether he has stumbled into any issues, any roadblocks or not. So if you have this daily meetings with your developers, the longest that they can get done with any issues is 24 hours, right? That actually minimize minimize the development risk that you don't hear back from your freelancers for 2 weeks, and by the end of 2 weeks, he or she will build— you asked for A, but he actually gave you B. So you minimize the risk for something to happen.

So let's talk a little bit about how you're building without a technical co-founder, because now you're managing it, right? And Miranda, if I pronounce— I'm going to get the name very wrong. So she was asking, is it a good idea to get your product made outsourced or a web development company versus insourcing it? What are the pros and cons? And are there some IP risks? So, I mean, this is a— so you're a non-technical founder. You don't necessarily have a technical co-founder. Now, do you try and get them in-house or out-of-house? And then, because I think if we're working out-of-house, there are some tools related to the Scrum that we should talk about. But let's just, before we get to that, right, let's talk about in-house versus out-of-house. Do you have opinions on which is better?

My opinion is that you should not outsource your core product experience. You should own the product experience by yourself. Unless the outsourced freelancers can have daily scrum meetings with you and can do daily pushes or weekly pushes, then he's kind of not, he's kind of in-house, although he's a freelancer. So unless that thing can happen, you definitely should not outsource your core experience. That's my personal view. You can outsource anything that's not core, right? Or something that might not require—

Let's define core and not core, just because again, we have to assume that a lot of people on the call or on the webinar are not as experienced as you or I. So like, again, Tinder, going back to a simple example, core would be the mechanism of Saying yes or no to someone on the mobile phone for the purposes of dating. Non-core might be like sending email reminders to people to sign up with that, that, or even the newsletter. Would that be an example in your mind, or can you give a better example?

Right, yeah, that's, that's a little bit more granular than I had in mind. I was thinking of that if you want to build an on-demand service, for example, Uber for ex, for example, then I guess the core experience is probably offline, not the— well, maybe the tech behind. Not the tech, right?

So the core— that's a great example, actually. So a very good friend of mine started Sprig. You click a button, you order something. Clicking the button to order isn't part of the experience. The food that shows up at your door, the quality of the food, whether it's really good, hot, you know, prepared correctly, how fast it comes, that's the great example. That's the core product. So in fact, in that business, it's a tech-enabled company, but the tech is irrelevant. Right? Because it's just like click a button, food comes. The food coming and being good is the core product. That's a great example.

Better example. Right.

All right. So core, non-core. So you don't outsource your core stuff is your advice. And that's generally the advice that every smart person will give a new founder. If it's core to your business, don't outsource it. Right? But I think you added a nice twist to that. If it is technical and core to your business and you have a freelancer that you can speak to every day, so you're gaining the learning and you have fast feedback cycles, then it is okay to outsource it because you're getting the benefit, but it might be more cost-effective.

Right, exactly. And I guess as the company, as you progress as a startup founder and as the companies continue to grow, you will definitely still hire more than one engineer in-house, right? So you might be into your advantage to start early and, for example, I guess one common hack that I would advise people is try to find a freelance consultant to work with you as a part-time consultant in the beginning. He or she doesn't even need to write code for you. You can write code for yourself and have weekly meetings with him just to make sure that you're on the right track. But the whole process—

Right, so, yeah, great suggestion, sorry.

No, yeah, so the whole, the entire point is, one, you where you actually, the whole process is kind of like a recruiting process for him or she to be your full-time co-founder down the road. But this whole process is also a great way for you to try working together, and had this not worked out, that's fine, right? Because one, the guy is only a consultant, and two, he or she actually would still be contributing value to your company because he has given you awesome and valuable feedback to your code, and you're still progressing as a company. And if this works out great, he will become your technical co-founder or employee number one, engineer number one. So that's like one nice hack that we usually offer people.

Right, so start working with them in the freelance capacity, and the nice thing, exactly as you said, and I think I want to just highlight this because it's so important is, you know, you don't know if someone's co-founder material or a first employee, right, until you've spent a decent amount of time with them. So if they are freelancing with you, right, if they're doing this as a consultant, part-time possibly, or even full-time, you start building a relationship with them Then you know whether, hey, I can work with this guy as a co-founder, or you know, hey, I can work with this person as a first employee. You gain that critical knowledge by working with them day in and day out. I love that idea of using them, even if you're doing the coding, to essentially bounce ideas off of, even if they're technical and can do a better job than you. that math education going. Let me ask you a question related to that because I think that's a very fast— I haven't heard that before and I love it. So maybe as a way to learn even, and this I've never heard anyone say this before, so we may have come up with something here. What about hiring for non-technical co-founders someone who's like a project manager and like say, hey, you know, will you be my advisor? Can I get your time a few hours a week? And learn from them, right? A professional technical project manager being an advisor early on to train you. It's an interesting thought that came out of your comment. What do you think?

That's quite interesting. Well, I guess our company CodeMentor has been trying to address this from the code, the CTO, the CTO on demand analogy. But interestingly, we should start like a PM, like project manager mentor.

Yeah, that's a great idea.

To help all the aspiring entrepreneurs out there.

Because, yeah, to your point, the CTO, you know, as a company gets bigger, the CTO is a project manager anyway, right? That's another thing, by the way, FYI, your CTO will also not code after a certain period of time, which doesn't even seem logical to you, but I guarantee you it's true. So your CTO will also not be writing code. But yeah, so project— gaining that project management skill, possibly through a freelancer early on, or advisor, might be super useful to you. Because as we've been saying, getting those requirements right for the front end and the back end, figuring out how to do these daily Scrum meetings, figuring out the sprints, the speed, getting all that right is very hard for a non-technical person. And so a shortcut might be bringing someone on with those experiences. So let's talk about how you might find some of these people. Do you have any advice? How do I find them? Where are they? The freelancers, the advisors, the possible CTOs, the vendors. All the above, what is your advice on finding some of these guys and women?

Right, I guess the usual suspects would be like going through your networks, local meetups, there's a bunch of them. But again, the most dangerous thing is start a company with a random person that you meet at meetups, right? So the great logical step for you is to, once you found a potential great candidate, start working with them. Start to familiarize yourself whether the coding, the working style of each of you would match or not. Yeah, and again, the hack that I mentioned, right? Once you've identified a potential great match, try to work with him or her as a part-time consultant and try to work with them for a few months and see whether you enjoy working with each other or not.

Yeah, and I'll add something to that. So one of the things that most new founders don't understand is that everyone in the organization, from the vendors to the employees to the you know, literally everyone associated with your organization, that forms the character and forms the culture of the organization, both internally and externally. So for example, if you hire a big mean lawyer, even if you're a super friendly founder, you're going to be perceived as a big mean person in the world because a lot of times your lawyer, if it's you and your lawyer, half the organization is going to be a big mean lawyer guy. And similarly with the vendors, if you hire a certain type of vendor that works a certain way, that vendor will actually be more of your staff than you. And so your company will be perceived in the world as your vendor. So it's very careful, it's very important to carefully select those initial vendors contractors, advisors, for culture, etc. And the best way to do that is to work with them. We have a few questions coming in from the audience, and if you have questions, we have a few minutes left. So, you know, again, a lot of people are asking it about how to choose which technology to use, right? They don't really know, and I need to know how And one of the questions related to that is, don't I need to find my co-founder first? Because if I pick a technology and then the co-founder, and then the co-founder doesn't want the technology, I'm kind of out of luck. That's a tricky one, which is true.

Right.

Good question.

Do you have an opinion on that? Yeah, that's a good question. So essentially, we also got asked about this quite a lot, right? So which technology should I learn? Usually we recommend two ways to think of this. One is to choose one that has a big online community that is active recently, and two is choose the one that your potential co-founder is familiar with so that he or she can be joining you down the road. Let's go for the first. We actually, the co-mentor, our team that co-mentored actually wrote a pretty extensive blog posts analyzing like which is the best programming language for beginners to learn in 2015. So we analyze a bunch of things, right? Average developer salary in the US, size of the Stack Overflow online Q&A community, the size of the GitHub open source projects, and even the popularity of the requests on our site CodeMentor. So we found out that JavaScript is the dominant winner. So in most cases, we'll actually recommend anyone, whether you're just starting out, you should at least learn how to write some lines of JavaScript. So here's why.

What is number 2, by the way, dare I ask? If number 1 is JavaScript, what's number 2?

Well, I guess it's Ruby on Rails and Python. They come in close seconds. Yeah, so Ruby on Rails, they're great because it's beginner-friendly and they have a very large supported community and a good number of open-source libraries to use. And Python is great as well because it's very versatile and useful for things like data science as well.

So basically, I think, I love your thing, if you know who your co-founder is, Base it on the language your co-founder knows. If you don't, base it on the language that's most popular in the world for the thing you're doing. Great answer, actually. John was asking a question. If you have a web app, should you copyright it before presenting it to people who are technical in order to protect it from being stolen or copied or whatever else? I mean, I'm happy to answer that, but you're the guest of honor, so I'll let you go first.

Sure, I'll go for that. Yeah, probably not, because honestly, ideas are quite worthless in the startup world, at least in the very, very early stage. Most likely your idea will evolve, and maybe the over— the high-level direction could stay the same, but how you attack the market will probably evolve as time goes on. Maybe sometimes as fast as 2 months after you started. So don't just go through all the hassle of copyright or trademark or file a patent for your business process because 99% of the time that won't matter at all.

Yeah, listen, Your idea is the inner space between your personality and the world, right? So even if someone took your idea, they would implement it differently than you. So never worry about someone stealing your idea. There are 1,000 people that sell shoes online and there's only one Zappos, right? And that's because Tony's personality is manifest in the business. And that's what makes Zappos Zappos and not Zalando or any of the other clones all around the world that do the same thing, and they'll never be the same. So we're winding up here, last few minutes.

Any final—

so we got a lot of people who are entering the technology world looking to start a company. What sort of final tips or final pieces of advice do you think they need to know or should know before embarking on this exciting journey?

Sure. Well, life as an entrepreneur can be super hard, right? Starting a startup is hard, but comparing to starting a company, well, honestly, I feel like learning to code is kind of like a cakewalk compared to the hard things about hard things of building startups. So if you do your journey entrepreneur to be a 10-year, 20-year journey, being able to know code to some degree, right, to know enough code to build your own MVP or even to just communicate better with your engineers is an extremely helpful skill set for you as an entrepreneur. So yeah, learn to code, build a startup, and be awesome.

So I'll tell you something, and I'll add to that. So The Hard Things About Hard Things is a book by Ben Horowitz, who's a venture capitalist at a VC firm called Andreessen Horowitz. Marc Andreessen is the other partner who helped found that firm and actually created the first web browser, commercial web browser. So yeah, I've been a serial entrepreneur for 21 years, and I was running a very demanding company with approximately 100 employees, multiple offices, 20 million active users a month, and I learned to code while doing that, okay? So when you start out— now, I was a little bit technical many, many years ago, and I guess now this was 7, 8 years ago itself, but you can learn to code anytime, and as you well said, learning to code is not as hard as building a company, and it provides you with a vast amount of a leg up. So I'll give an example of how that leg up manifests itself as just a closing thought. So, you know, for the venture fund that I'm running now, we wanted to build a system to manage the deal flow we're receiving. In the olden days, I would have written this requirements. This time, because I know how to code, I wrote the data model, right? So I actually wrote the database model, and then I wrote some functionality on top of the database model. It probably took me a day and a half to spec out a very complicated system. Them, whereas if I didn't know how to code, that might have taken me a month or more. And because I provided the developers with the data model, I made their life easier as well. So thank you so much, CodeMatter. Welcome. And listen, thank you guys for dialing in. This was lovely. Lots of great knowledge shared. I love the idea of a virtual PM for hire to help new founders, uh, get the hang of things. This has been fantastic. Thanks, guys. Thanks for tuning in, and I hope to see everyone again soon.

Thank you.