You have a brilliant idea, but you have no idea how to build a startup. And you can’t code. You have 4 options: Learn how to code Find “The CTO” Hire freelance developers Outsource with a software development company I’ve been in this situation more than once. I co-founded 7+ startups before creating & and I’m not a developer, so I’ve tried many different approaches and learned the hard way. I’m sharing my experiences on how to build a startup hoping they are helpful to you. Altar.io 10kstartup 1. Learn how to code: We shouldn’t waste more than one paragraph on this option because it is such a dangerous one. I’m just mentioning it because there are many founders that think seriously about this option for more than 3 seconds, some even try it. There are endless reasons not to do it, the simplest one: you need to , on what moved you to start this journey. That vision you had is the drive that you must focus on. To achieve your vision you’ll need extra time creating the core connections, thinking about the market, in how to penetrate it and dealing with all the blockers that will come up along your way. focus on the business growth and strategy Don’t underestimate (i) the difficulty of developing a good piece of software (you should put it in the hands of someone experienced) and (ii) the focus and resilience you will need to carry out your plan on the road to success. My advice: , not on learning how to code. you should be super focused on what you can do better 2. The quest for the Soulmate CTO: You’ve read a couple of blog posts about “66 Tips to find the perfect CTO for your startup” and there you go. Across the way you will hear many people saying that “investors invest in teams” so “you must find your CTO“. You will start hitting tech meetups and purchasing tickets for the like crazy and listen to many geek conversations trying to find your co-founder (don’t get me wrong, I love tech meetups, events and geek conversations). hottest Startup Events If you pick the right meetups, you will meet lots of interesting people, with interesting projects and also developers that look like geniuses when they start dropping all those buzz words you can’t understand and how to separate the wheat from the chaff? Use this shortlist to know if you are dealing with the Soulmate CTO: He/she has as much passion for the idea as you have (or at least he/she shows 90% of the thrill you have); Passion: He/she must be, at least, as good doing his stuff, as you are doing yours. This might seem subjective and it is, but you can try to make it rational: If you are i.e. a student coming out of college with a great deal of energy but not so much experience, then it makes sense to stick to a promising CTO that is also finishing the software engineering course. But if you are a senior consultant with a good position in a big firm or an experienced marketeer that brings market knowledge in the palm of your hand, so you should look for a soulmate with a comparable depth of knowledge and track record in his area. There is not a recipe for this match, so be sure you feel safe and comfortable with his experience and execution power. Look at his portfolio and ask an expert (an exempt one) to make a validation of the quality of the work. Expertise: You should also be sure that he/she has the required commitment. There isn’t anything worse than “getting married” with a co-founder that doesn’t want to commit. You will be living the “mistress syndrome”: your co-founder has a full-time job, you are committing to the startup more than he is, he keeps delaying the full commitment for any reason (not the perfect timing, salary-wise) and you keep waiting for him to make his decision one day. Be pragmatic: Set a timeframe to get your MVP rolling and see if you get to a common ground before you commit. Commitment: If you are going on this adventure together you must have your expectations aligned. Discuss roughly the (i) roadmap, (ii) equity split & salaries, (iii) work culture and the most importantly (iv) the paths you envision for the startup must coexist. I don’t mean you need to be 100% in tune on every topic and never discussing any detail. It is the total opposite, it is very healthy to discuss a bit or as much as possible. With discussion, you will be sure you are not dating a passive-aggressive mate (1 of the 12 developers archetypes) that can put your relationship into a dangerous position when he explodes after a long silence. So with a bit of discussion you will understand ASAP if you can get to a quorum and be aligned, otherwise you might be divorcing later and the cost would be: your energy, time and money. Also, be sure you are not in an “atomic relationship”. You are in an atomic relationship when you discuss a lot and each discussion reaches the point where you are discussing atoms and epistemology. This is also very dangerous because you will consume your energy in the wrong topics and although it might seem so, your energy is not infinite. Alignment: For sure you agree that responsibility is a key role for success and you want to be successful. So remember to make this check: Your CTO is responsible. There are many ways to test responsibility, my pragmatic and simple suggestion, in this case, is asking for some deliverable for a meeting and make the test. Imagine you will meet a mentor in a few days. Ask your future CTO to commit to developing a deliverable in a short time. Something feasible and not too complex. It could be a roadmap, a budget estimate. If he commits and delivers good work: perfect. If he commits and doesn’t deliver: red alert!! If he can’t commit maybe we go back to point 3. (commitment). Responsibility: It is a commonplace that tech people tend to have communication problems. Many developers you will know share this attraction for being alone in their “cave” with their 7 screens and low light. That is ok, not a problem, but your CTO must be able to communicate easily and naturally and not as if he is a super sapient master of the universe, making you feel dumb. Remember, he won’t be in the basement forever. When you are successful, you will grow your team and your Soulmate-CTO will need to run a horde of developers, you don’t want him to be a dictator, but he shouldn’t also be a submissive follower. Some team leading capabilities and for sure good communication skills are mandatory to avoid big problems in the future with you and all the team. Last, but crucial: Communication: You can also consider looking for a CTO as a service. An experienced CTO is expensive and may not be willing to commit with a long term project. A couple of years may be a different story, though. You can get precious help on your strategy, building a team, launching and getting investment. He will then take his pay and go on his way. 3. Developers without marriage At first glance, it seems like a great second option: flexible and no commitment before having an experience. I have a long record of working with freelance developers. I like the flexibility of picking the “perfect” profile for each challenge. I keep an organized database of all the freelancers that have worked with me, with a detailed profile and history of works together. Every time we have a project where we need to distribute work, we can pick the best one for each role. However, choosing freelancers is not always a sea of roses, be aware of these aspects when considering this option if you don’t have a lot of experience doing it. How do you know you can trust freelance developers for big decisions? If you don’t have a lot of experience in development, you may not know how to choose the best option in terms of programming language and all the architecture decisions. These decisions should be done by someone with a great deal of experience and in an exempt position. This is your CTO (if you already have one that has enough experience) or an outsourcing agency. A freelance developer might sell you what he does for a living as your best option. Let’s take a PHP developer, for example, you bring him a product vision which should clearly be implemented in Node.js – either (i) he is honest and tells you that and puts you in contact with another developer, (ii) he is still honest but his knowledge is strict to his experience, so he will not even know that there are options 100 xs better for your startup, (iii) he is not honest, he knows this is not the best options, but it is what he can offer, so he will convince you. Another reason and I shall say the more relevant one, is: ! The time of implementation, the stability of the system, the scalability of the requests and the costs with infrastructure that your system will require, will determine if your product tech-wise will play its role or not when things start moving. Trust: the core tech decisions are fundamental for the scalability of your product in the long, mid and short run Have you ever managed a team of developers? If you haven’t, be aware of what you are getting into. There are , each has its specific characteristics. But in general terms, developers are not easy to manage when you are not experienced Management: 12 Archetypes of Developers For communication, like with the CTO, it is very important that you can communicate well, that he is communicative enough to make you feel safe about the decision, you don’t have language barriers and you understand mutually. Communication / Availability: You must be sure he follows the industry standards for project organization and documentation. Otherwise, if he doesn’t follow the standards, is it TDD (Test Driven Development), CI/CO (Continuous Integration / Continuous Deployment), you name it, his code will be very difficult to be followed by any other developers that might join the team later or occupy his seat if he leaves the project for any reason. The risk is that he will be the only person with a key to your castle. So be sure the developer is following the standards. Dependency: You know you will need to scale sooner or later. This one relates to the previous point (dependency) but it is wider than that. When you chose to work with a developer, you choose to have one resource. If you need more resources you will have to through the process all over again. Scalability: As I told you before, I have a strong experience managing freelancers and about this point, I’ve experienced 75% failed delivery & deadlines when first working with a freelance developer. As I mentioned, we only keep la creme de la creme and after a bad experience, it is very improbable that we will work with that developer again. One of the reasons for our one-work-stands (non repeated developers) is that they can’t make a proper time estimation, so they fail on average with c. 200% departure from the estimate. Did you hear that? 200%. No, they are not delinquents, it is extremely hard to make an accurate time estimate for software development. So the technique we’ve adopted, also for code quality assessment is: we start with a simple task assignment (i.e. “please create this simple endpoint in our API”), if it goes well we give them a more complex task, and then we evaluate if we keep them or not. I believe that in your position this is not very attractive, because it is time-consuming, delaying the commitment and you just want to get things done. Sure, but play safe, I always do it and don’t regret. Reliability with delivery & deadlines: As I stated about the CTO, look at their portfolio and then ask an expert (an exempt one) to make a validation of the quality of the work. Work quality: In my experience, I never had a problem with security or information breach with a freelancer, but I chose to work with delicate matters only with people I already trust a lot. So if your startup has a patent being submitted, or any kind of secret sauce you should play safe through an NDA. Security & Confidentiality: 4. Outsourcing with an agency: The risk is the same as outsourcing anything that is not a commodity, you must carefully pick the right partner. When selecting your partner to outsource something important, the aspects you need to care about are: You must validate the quality of previous works by your partner. For the MVP it is easy to validate design quality looking at the portfolio and for development quality, if you have a geek-friend it is also easy to evaluate the code quality via their git repository. Record and Experience: You should check if the partner has the right tech framework and communication abilities to know if they can manage to execute the project successfully with ease communication. Also, be aware of generalists. If you hear “we’re not stuck to a technology…we do everything: all stacks and technologies”, it actually means “we’re not specialzied in any technology”. And probably means they are not the best in any technology. You want a team of specialists so look for a team that masters 1 or 2 technologies, not all. Communication, Technology & Infrastructure: : It is also important that your partner understands your “ ” and ideally speaks the same “ as you. They understand your idea, your business and they give you the references you like. Cultural Compatibility language language” : Find a partner with a compatible pricing structure. Of course, you wouldn’t mind having as your product partner, but maybe it will be hard to onboard him at the stage you are now. On the other hand: I also like to say: “ ”, that means being mingy won’t bring you good results in the long run. You need someone experienced and you definitely want good quality and professional customer care. Size Match Matt Rogers If you pay with peanuts, you get monkeys The agency must also follow the industry standards for project organization and documentation. So what I highlighted regarding freelancers in point 4 also applies here. There is an extra care you must have when dealing with an agency: “lock-in nightmare”. If you want to be able to work with other parties in the future, be sure you sign the right contract, you must be able to bring your code to other player’s hands, otherwise, you get into marriage by force and now you will have to get divorced and bring your lawyers. Dependency: Look for a partner that offers flexibility in terms of team size and allocated time. You don’t want to go into a waterfall contract that is not flexible. You should try to commit with small sprints and deliverables instead of getting into a contract of months and months – remember: . You will have different needs across your way, choose a partner that can adapt to your different needs, that is flexible to scale up and down the team accordingly to your needs, that keeps evolving, growing and shrinking. Scalability / Flexibility: Software is a living organism Wrapping up: The decision on how to build your startup is key for your project’s sucess. In CBinsight’s article you can see that accumulatively 53% of failures are team-related. also reports that 88% of Founders say that assembling your founding team should be given a high priority. You need to choose wisely. “Top 20 reasons startups fail” Harvard Business Review Learning how to code and trying to manage a bunch of developers by yourself, I simply can’t recommend that. We agree the idyllic option is , and if you were lucky to have found him/her then, for sure, you should stick to your buddy. finding a soulmate-CTO from day one I guess that’s not the case, otherwise, you wouldn’t be reading this article until the very end. Don’t worry, you are among the majority of non-tech entrepreneurs, it is very unlikely that you find this person in a seller’s market, where each year the ratio of request for developers per developers keeps increasing, you see, ! If you put on top of these metrics that only a few are good developers, and from the good, many have communication and commitment problems, you see you aren’t doing anything wrong, it is just the conjuncture. there were 5 job postings for each 1 candidate, 5 to 1 So if you haven’t found your soulmate-CTO yet, I strongly suggest you deliver the execution to a with a proven track record. Many successful startups started this way until they built their team. I’m talking about Skype, Slack, Klou, Staff.com, GitHub, MySQL, Opera, JPay, well you get the idea. highly experienced team Daniel De Castro Ruivo, Co-Founder at Altar.io This post was originally published at Altar.io
