What’s the Best Way to Build Your Startup? CTO, Freelancers, Agency?

You have a brilliant idea for a Startup, you want to build the app/software but you can’t code. You have 4 options:

  • Learn how to code
  • Find “The CTO”
  • Hire developers
  • Outsource with an agency

I’ve been in this situation for more than once. I’ve co-founded +7 startups before creating Altar.io & 10kstartup and I’m not a developer, so I’ve tried many different approaches and learned the hard way. I’m sharing my experiences and hope they are helpful to you.

1. Learn how to code:

We shouldn’t waste more that one paragraph with 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 focus on the business growth and strategy, 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.

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: you should be super focused in what you can do better, not in learning how to code.

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 hottest Startup Events 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).

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?

Short list to know if you are dealing with the Soulmate-CTO:

  1. Passion: He/she has as much passion for the idea as you have (or at least he/she shows 90% of the thrill you have);
  2. Expertise: 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.
  3. Commitment: 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. Being pragmatic: Set a timeframe to have your MVP rolling and see if you get to a common ground before you commit.
  4. Alignment: If you are going on this adventure together it is very important that you have your expectations matched. 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 for 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 a “atomic relationship”. You are in an atomic relationship when you discuss a lot and each discussion reach 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.
  5. Responsibility: 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 for testing 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 develop a deliverable in a short time. Something feasible and not too complex. Could be a roadmap, a budget estimate. If he commits and delivers a 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).
  6. Last, but crucial: Communication: 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.

3. Developers without marriage

At a first glance it seems like a great second option: flexible and no commitment before having an experience.

I have a long record on working with freelance developers. I really like the flexibility of picking the “perfect” profile for each challenge, I keep an organized database of all the freelancers that 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. But choosing freelancers is not always a sea of roses, be aware of the aspects when considering this option without long experience on doing it.

  1. Trust: How to trust freelance developers for main decisions? If you don’t have a long experience in development, you don’t know how to choose the best option in terms of programming language and all the architecture decisions. These are decisions that should be a 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 freelancer developer might be selling you that the best options is what he does for living. Take as an example a PHP developer, you come with a product vision that should clearly be implemented in Node.js, but (i) he is honest and he tells you that and put 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 is: the core tech decisions are fundamental for the scalability of your product in the long, mid and short run! 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.
  2. Management: Have you ever managed a team of developers? If you haven’t, be aware of what you are getting into. There are 12 Archetypes of Developers, each has its own specific characteristics. But in general terms, developers are not easy to manage when you are not experienced.
  3. Communication / Availability: For communication, like with the CTO, it is very important that you can communicate well, that he is communicative enough to make you feel totally safe about the decision, you don’t have language barriers and you understand mutually.
  4. Dependency: 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 on by any other developers that might join the team later or occupy his seat if he leaves the project for any reason and he will be only owner of the key for your castle. So be sure the developer is following the standards.
  5. Scalability: You know you will need to scale as soon as it is required. This one relates to the previous point (dependency) but it is wider than that. When you chose to work with a developer then you will have one resource. If you need more resources you will have to through the process all over again.
  6. Reliability with delivery & deadlines: 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 time working with a freelance developer. As I refer we only keep la creme de la creme and after a bad experience it is very improbable that we will work again and one of the reasons for our one-work-stands (non repeated developers) is they can’t make a proper time estimation, so they fail on average with c. 200% departure from estimate. Did you hear that? 200%. No they are not delinquents, it is really extremely hard to make a 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 him a more complex task, and then we evaluate if we keep him 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.
  7. Work quality: As i referred about the CTO, look at his portfolio and ask an expert (an exempt one) to make a validation of the quality of the work.
  8. Security & Confidentiality: In my experience I never had a problem of 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 a NDA.

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:

  1. Record and Experience: 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.
  2. Communication, Technology & Infrastructure: 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.
  3. Cultural Compatibility: It is also important that your partner understands your “language” and ideally speaks same “language” as you. They understand your idea, your business and they give you the references you like.
  4. Size Match: Find a partner with a compatible pricing structure. Of course you wouldn’t mind to have Matt Rogers as your product partner, but maybe it will hard to have him onboarded at the stage you are now. On the other hand: I also like to say: “If you pay with peanuts, then you got monkeys”, that means, being mingy won’t bring you good results in the long run, for sure, you need someone experienced and you sure want good quality and a professional customer care.
  5. Dependency: The agency must also follow the industry standards for project organization and documentation. So what was highlighted about the 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 party in the future, bu sure you sign the right contract, you must be able to bring your code to other player’s hands, otherwise you got into a marriage by force and now you will have to get divorced and bring your lawyers.
  6. Scalability / Flexibility: 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 are not flexible. You should try to commit with small sprints with deliverables instead of getting into a contract of months and months and remember a Software is a living organism, so 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 keep evolving, growing and shrinking.

Wrapping up:

Look at your MVP as a key investment, choose wisely, having these topics into consideration. 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 finding a soulmate-CTO from day one, and if you were lucky to have found him/her then, for sure, you should stick to your buddy.

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, there were 5 job postings for each 1 candidate, 5 to 1! If you put on top of these metrics that only few are good developers, and from the good, many have communication and commitment problems, you see the maths reasons to being struggling, you aren’t doing anything wrong, it is just the conjuncture.

So if you haven’t find your soulmate-CTO yet, I strongly suggest you to deliver the execution to a highly experienced team with proven track record. There are many successful startups that started this way until they built their own team. I’m talking about Skype, Slack, Klou, Staff.com, GitHub, MySQL, Opera, JPay, well you got the idea.