It is really easy to look at Facebook and Google and Netflix and think “Yeah I could have built that.” Every one of us has one or two or possibly even three ten-billion-dollar-ideas. All you really need is a programmer right? This startup thing does not look all that hard.
I just happen to be a programmer. It is kind of frustrating to talk with people and see the hunger in their eyes because I am their path to Zuckness. They haven’t even busted out the unilateral NDA for their amazing idea and I feel dirty and used. It breaks my little heart.
The good news though, is that I am kind of crazy. All my non-crazy programmer friends send me lots of people to talk to; for some reason they are not interested in talking to idea people. I like talking to the idea people quite a bit, honestly. Does that mean there is something wrong with me? Maybe I should seek help. Maybe not.
Through these conversations I have learned that people do not have any idea how hard it is to make a startup, nor do they have any idea how big numbers work. A good friend of mine lamented that they have been doing high tech startups for twenty years and they were not yet abundantly wealthy. It does not work that way. There is no reward for time served.
In the process of trying to help people to build their startups I have learned some interesting things. I am going to share some of the more obvious things you can do in order to help increase your odds of long term success.
The first thing is that there is never enough money to do everything you want. You are going to have to make sacrifices to get to the starting line. Deciding what you can and cannot have is crucial, and will test your limits mightily. Most of the time that someone comes to me with an idea, it is generally a five hundred thousand dollar startup. Usually they have about fifty thousand. That is not a giant gap in Carl Sagan terms. There are ways you can save money in getting out the door; we will go through them.
Students – You can generally get away with a more junior programmer than you think you need. The challenge is that you likely will need to give them some kind of direction, or else be prepared for a more expensive rewrite later once you have de-risked your research in development. It is gut wrenching to be on a phone call with someone who has their cost per user climbing 3% or higher for every five hundred users they are adding, when they have found a solid product market fit.
Part Time Programmers – In addition to students, you might find someone who already has a steady job and is willing to help you on some kind of equitable basis. They may love your idea, they may need your product, and they might even be willing to work for revenue share on the backend. Be wary of the person who wants to work entirely for free; you often get what you pay for.
Overseas Operations – You can generally find less expensive developers outside of Silicon Valley, as shocking as that sounds. You can get some pretty good bang for the buck by going overseas, or even to Canada. Sometimes you might find a marginally more expensive outsourcing firm that has a local handler to work with you on getting your idea built. There are risks here too. It is hard to know if you are funding an eventual competitor, or even if you are going to get everything built according to the letter versus the spirit of the agreement. Many of these companies are building products as a work-for-hire mercenary business to get to some goal as an organization; either they are looking for bigger contracts, or they are just idling along profitably as a think tank looking for product market fit.
The Crazy Full Stack Veteran – This is the person who has done this dance before and generally works at a 10x pace. Usually they are a lone wolf and have enough of everything you need to get something stood up. There are some interesting trade-offs to consider with the full stack veteran to get your idea to market.
These all have their pros and cons. There are approaches that are cheaper, that will take more time. There are approaches that have less risk, but will cost more money. Balancing this all will be hard, especially since most people are very adamant about the role of cash in all of this.
When you are cash poor for a good idea, it is worth trying to understand what you can and cannot give up in order to get the burn rate down. Are you willing to give up revenue share to get out of the gate? Are you willing to give respectable amounts of pre-funding equity to your developer? Do you have to own the technology developed? All of these things can be used to bring your up front costs down.
When I talk with people about their ideas, I tend to size them up like an investor would. Have they managed businesses before? What level of experience do they have with success? If a person has a nice idea and is fresh out of school, the ROI on equity for your first shot out of the gate is essentially unmeasurable for upside. If you are speaking with an executive with twenty years of experience with hundred-million-dollar enterprises, that is a safer bet that their equity will be worth something. You can generally set your own expectation on returns after spending time talking to people and looking at the marketplace.
If you are able to front some of the development cash, and then pay the rest out of revenue share, that is also an option. If the work costs fifty thousand dollars worth of time, and you can only pay twenty up front, it is reasonable to offer twice the amount of the gap on an accelerated revenue share until that gap is paid up. I like this model. I have been partially paid out on it in the past, although it is a calculated risk. When I do these things for myself, I generally cap it at twice the amount. It is not fair to burden someone with perpetual accounting for revenue share on a pure cost basis.
Finally, do you need to own all of the technology? I like to own my frameworks and I have built about half a dozen projects over the past decade where I retained the rights to research and development work. I am always willing to sign a time limited “non-compete” on that technology, usually six months to a year after the completion or termination of the agreement, depending on the product space, the size of the deal, and the people involved.
These are great tools to align the costs of your product. You can mix and match them too. I think that there is good value in having a part time technical executive spending a few hours with your students or overseas developers to make sure that you are getting the right things done. Be prepared to make it worth everyone’s time. For me, I like to have a slice of equity and a slice of cash for helping people; it is never fully worth it to do one or the other.
Now that you have gotten past the benjamins, let’s discuss some things to help you make sure you are getting your money’s worth, and building value. Let’s talk about legal agreements and what you should make sure you have access to.
Regardless where you found your happy little worker bees, make sure you have a proper agreement in place; what you pay in lawyer fees now will save your business in exorbitant costs and pain later on. Make sure you have a reasonable jurisdiction in the agreement. Make sure the terms for confidentiality, termination and breach are all mutually acceptable. Understand if you are going overseas that the intellectual property laws may differ. Also, please do not just ask people to sign a unilateral NDA just to discuss the idea. It makes sense when you get into specifics to have a mutual non-disclosure agreement in place. You probably think your idea is priceless. The average programmer will tell you without execution it is worthless. The real answer is somewhere in the middle.
As you get your agreement set up, try to establish incremental milestones; this should be pretty common. Be afraid of large lump-sum payments. It is fair to put a milestone on contract execution, and to add milestones for feature completion, QA completion, and final product acceptance. Make sure there is language in the agreement to discuss “out-of-scope change requests”. When milestones are submitted for acceptance, you should commit to a “yes/no” within a reasonable period of time. When I ask people to build projects by milestone and I am unable to get to it within ten business days, I commit to approving the milestone For Billing Purposes Only to keep the cash flow going. It is only fair to all parties.
Make sure you are getting access to the things you are paying to have built. If people are building you a product, it makes sense to have source level access to the code repository at all times. I am saddened when I hear about people holding source code hostage in startup situations, regardless of the circumstances. If you are working with someone who is nervous about giving you access to the things you are paying for, you should consider that a warning. A good technologist will rebuild a second version of something from scratch better anyway. If they are not comfortable giving you repo access to code for the product, you should walk away. This should also mostly be true where you are sublicensing code from them instead of buying it outright. The only exception is if they have something in escrow, or clearly being used as a provably-successful revenue-generating enterprise they wish to protect. If this is the case, make sure you bake in a year of time into any termination for them to keep your business running as a moral part of your agreement, so you do not get shut off and left completely in the cold.
There are some things to think about as you are building your billion dollar business. There are always ways to get stuff built; there are always tradeoffs to be made to get in front of customers. These steps will not greatly enhance your incredibly low odds of success, but will help make an already difficult journey more reasonable and manageable.
As always, feel free to like and/or comment. I have done my best to help some people live their startup dream. I am always happy to answer questions!
