Finding a Co-Founder, Part 1 – Evaluation

I’ve been involved in multiple startups over the last few years. One of the key lessons I’ve learned is to ensure that the co-founding team works well together. Your team can make or break the startup. A recent Fortune article indicates this is the third top reason why startups fail. In my experience, at least 50% of the startups I’ve been a part of didn’t go beyond the initial brainstorming phase for this reason. The co-founding team couldn’t agree on issues, had different goals or just didn’t work well together. In the end, the business collapsed in only a few weeks.

So what does “works well together” mean? Well a lot of things. I’ll talk about 3 issues that I’ve found to be critically important.

Alignment of Goals and Timelines

Why do you want to start a company? Why are you passionate about this idea? What do you want to get out of this experience? What’s your short-term and long-term goals? Think about the answers to these questions and then find people who are also aligned with you. It’s ok if you’re not perfectly aligned as long as everyone is in agreement on the long-term goals of the business. When the long-term is aligned, you’ll be able to resolve most team conflicts just by reminding everyone why they’re working on this startup.

In addition to understanding everyone’s goals, make sure everyone is aligned on the timeline of the startup. Some people may want to take an aggressive, full-time approach and launch ASAP. Others may want to take the conservative approach and use an organic growth strategy while working at a full-time job. This should be discussed and agreed upon in the beginning as this affects how each person makes decisions. You’ll find disagreements can occur because each person sees the issue differently from a time perspective.

Having said this, you also don’t want a team of “yes-men”. You want to find the right balance between aligned goals and maintaining each person’s unique perspective. You want enough differences to inspire innovation while not being a victim of groupthink. No one said this would be easy!

Specific Skills

Make sure you know your own strengths and weaknesses. Then look for someone who can fill in for your gaps. Anyone else you bring on should continue to fill some weakness for the team as a whole. This ensures that each member of the core team has a critical role to play and is contributing something meaningful to the team to help its success. This also ensures accountability since any lack of progress in a specific area can be attributed to the person leading the effort.

Time Commitment, Bootstrapping, and Equity

Time, money, and equity are probably the 3 biggest topics that need to be discussed early on within the core team. Some co-founders may be working full-time at a job, so how much time can they truly dedicate to the startup? If you’re working full-time on the startup, then how much money can you spare to help bootstrap the company in addition to covering your own living expenses? Finally what is a fair equity split amongst co-founders given the differences in contributions by members of the team? What happens if someone doesn’t deliver?

Personally, I’ve found that startups have a higher chance of success when everyone is going full-time on the startup. If this is not possible, then the equity split should be divided in such a way that the full-time individuals have more control and are able make decisions without being slowed down by the part-time individuals. Equity should also be milestone-based for each individual: once someone accomplishes a milestone, they are granted additional equity associated with that milestone. This ensures that everyone knows what they need to do and everyone does their part to move the company forward. For individuals working on the startup part-time, this strategy also incentivizes them to purposefully allocate time to work on the startup. Inc has a great article that goes into more details about this form of equity grant in more detail.

On the topic of bootstrap capital, first figure out how much money you need to get started. I won’t go over that here, but will mention to make sure to include a buffer in the budget for unexpected costs. Once you have an estimate, I’ve found that using an inverse ratio strategy works well: the more time you contribute to the startup, the less money you put in. So if you’re working full-time on the startup, you’ll put in less money. Everyone should still put in something, but the part-time contributors will put in more money to balance the lack of time contributed. This makes sense as time is money!

While there are many more topics to consider when finding co-founders, I’ve found these are the core issues that break up many startups. One thing for certain, the team needs to be open and honest with each other. Have these tough conversations in the beginning rather than later to save yourself much headache and time!

Azure Websites vs. Azure Mobile Services

Since I decided to go with Microsoft technologies for my new app, the next question I asked myself was related to hosting. With the growing prevalence of cloud services, it was obvious to go with Microsoft Azure to host my platform. With the benefits of Microsoft BizSpark, this was a no-brainer decision.

As I researched into what Azure offers, I learned there are currently two solutions for hosting mobile app platforms on Azure: Azure Websites and Azure Mobile Services. I spent some time researching both and the differences seem to come down to whether you’re a developer familiar with server-side coding or not. Mobile Services is great for client-side developers who don’t know much about server-side development. Mobile Websites will spin up the tables and the CRUD API’s in one step. You can even customize the logic using node.js. Websites, on the other hand, require that you manually create your own website and service, create your own database, and make sure everything is working properly without deadlocking. This is for the server-side developer.

I eventually decided to go with Azure Websites because the simplicity of Mobile Services was causing more problems than the time savings gained. I liked that Mobile Services provided client-side libraries to interact with the service on multiple platforms, but it wasn’t too hard to learn Alamofire to call my API code from my iOS app. My relational data model was also sufficiently complex such that the default implementation of Mobile Services created more of a road-block than made things easier. Since I’m familiar with server-side development, using technologies such as ASP.NET MVC, ASP.NET Web API, and Entity Framework for the database made more sense than trying to learn node.js. Websites also have many more scalability options than Mobile Services.

Cloud infrastructure is great. Not having to worry about the machine, the DLL’s, the system libraries feel so liberating than the old days when I had to respond to system alerts at 3am in the morning. Azure provides all of these benefits no matter which solution you choose. If you’re on the fence on selecting Websites or Mobile Services for your app, hopefully this helps clarify things.

Picking Technologies for a Startup

When you’re starting from scratch, one of the first questions you have to ask yourself is “what technology?” Sometimes it’s clear – content accessible anywhere in any format: responsive web, creating dynamic web content: use Javascript. Unfortunately, most times it’s very ambiguous: what server technology? what mobile platform?

This was one of the first questions I asked myself when launching my new startup. I eventually realized the following are the key questions to ask in my situation.

  1. What are you familiar with?
  2. Which platform do your customers use?
  3. How much time do you have?

What are you familiar with?

I’ve established my career on the Microsoft stack: C#, .NET, ASP.NET, LINQ, SQL Server, IIS, … Therefore, you would think this is a slam dunk right? Choose the Microsoft stack. However, I’ve always wanted to learn and play around with the open source stack: Linux, Apache, MySQL, and more recently Ruby and Ruby on Rails.

I figured building a new platform is a great opportunity for me to learn a new technology and apply the learnings to a real project. In the process of making this decision, I spent a few weeks learning Ruby on Rails, reading tutorials, and going through a few online videos in an effort to get the basics down before writing any production code.

Besides asking myself what I’m familiar with, I also debated with myself on many other factors not specifically related to programming. Which platform has more local developers we can hire? Which platform do I have more friends I can call upon? How much would it cost to hire contractors? How much does hosting cost? What’s the maintenance and support process? Are there software licensing fees to consider? Who do I turn to if I need support? When you just write code, you don’t think about these topics. However, when you run a technology department or start your own business, these are issues just as important, if not more important, than how clean your code is, how much code does your unit tests cover, how efficient is your code, …

In the end, I picked Microsoft for two main reasons: (1) that’s my background and that’s what I’m familiar and (2) see question 3.

Which platform do your customers use?

Obviously if you’re building a mobile app, you’d need to pick a platform. If you asked me 10 years ago, I would have told you I’m building a Pocket PC app. That would be an easy choice since there weren’t many smartphones back then and my background is in Microsoft. Alas, those days are long gone and today’s world is very different.

Mobile platform’s today revolve around iOS or Android. iOS spurred the “modern” smartphone and has Apple backing the platform. Android has the biggest market share with Google supporting the platform. Each platform is attractive to different customer segments with different demographics. Development on iOS is on a Mac, using Xcode, and either Objective-C or Swift programming languages. Development for Android is on PC or Mac, using Android Studio, and uses Java.

In the end, I picked iOS. There were technical and business reasons for this selection. On the technology side, it’s much easier for me to develop and test with a smaller set of device types and screen sizes to worry about. I’m also familiar with iOS development having played around with it in the past. On the business side, which is the more important reason, the type of customer we’re trying to reach with our initial version is more likely to have an iPhone than an Android device. We didn’t consider the other mobile platforms (Windows Phone, Blackberry, …) at this point because not enough of our target users use those platforms.

We also considered building a responsive web and going the route of using a Web View on the mobile app side. However, UX is critical for our app so we decided to invest in the native app for the initial release to ensure our customers get the best first impression. Of course this decision means we would forgo customers on the other platforms. This is a risk we were willing to accept since our goal is to prove out the concept with our first version before moving ahead onto other platforms. Lean Startup anyone?

How much time do you have?

The last, and possibly the most important, question I asked myself was regarding time. Just like any corporate project, time is always a big consideration. This is just as important if not more important for a startup since we’re trying to launch fast with limited resources (me essentially), get feedback on our product, and either fail fast or pivot so we’re not wasting time and resources on a concept that isn’t working.

My partner and I set out with an aggressive timeline to get our app launched early in the year so we can learn from the release and iterate quickly on the product until we find something that works. If you’re familiar with the project management triangle, then you know something has to give when you have limited resources and limited time.

Therefore, we needed to cut out everything else that wasn’t core to developing the product, which ultimately means delivering the most value to our customers in the least amount of time. In the end, going back to question 1, I realized I didn’t have time to waste learning new technologies. That’s why I realized the technology decision simplifies down to: the platform that allows me to be the most efficient and quick with development. For me, that means the Microsoft stack on the server-side of things and iOS on the client-side of things.