This is the first part of a series on becoming your own technical co-founder. In 2008, we couldn’t find a technical co-founder for Yipit. I’m writing about how I became our technical co-founder. Hopefully, I’ll encourage other entrepreneurs with a dream but no technical co-founder options to take their destiny into their own hands.
Disclaimer: If you know a great technical co-founder that wants to work with you, join them. This series is intended for everyone else who has a dream but can’t find a technical co-founder.
We Were Screwed
As the summer of 2007 came to an end, I had one of the most depressing and humbling weeks of my life. Just a few months before that, I had left an office facing Park Avenue making an absurd amount of money for a 26 year-old to start an internet-based company. I was now sitting in my apartment realizing, for the first time (and not the last), that I had absolutely no idea what I was doing.
We had been working on a site to help people share links with each other in private groups and had been using an outsourcer to build the first version. We wanted to do something in local but thought this site would be an easy way to quickly test our relationship with the outsourcer and get our feet wet.
After handing them an 80-page product spec months earlier, we were able to finally test the site five weeks later than scheduled– so much for quickly testing our relationship. Nothing worked. In fact, you couldn’t even share a link. As depressing as that was, it was made worse by the fact that the outsourcer told us he had tested out the site and “found no bugs.” I remember reading the email and then looking over at the other tab I had open with 16-pages of bugs we had found in 4 hours of testing. We were screwed.
While we continued to work with the outsourcer for a month and a half, we knew it wasn’t going to work in the long run. It wasn’t even really the outsourcer’s fault, it was our fault. We definitely weren’t managing them well. But, more importantly, we didn’t know what we were doing as entrepreneurs. I started reading Steve Blank and Eric Reis and realized we were going to have to do ton of iterating and having an outsourcer in the middle was going to make it really hard to be successful. We needed to iterate quickly and, thus, we needed someone on the team to do the iterating.
So, it was now October and, after failing to find a good technical co-founder, we knew we had to make a decision. Either we give up or one of us would become our technical co-founder. Since I had taken two intro CS courses in college, we decided I would become the technical co-founder and Jim would help out on the front-end development (HTML/CSS) side.
I was terrified. I had never built a site and hadn’t written a line of code since my freshman year of college (7 years ago). I thought we were doomed.
But, to my complete surprise, six months later, I was able to build almost any prototype we wanted. Really.
Why You Can Become Your Own Technical Co-Founder
It turned out that it was a lot easier than I had expected. At least it became easier when I realized that the goal wasn’t for me to become Yipit’s CTO. My goal was to build a prototype that got traction. (By traction, I mean that visitors convert into users of your site, those users come back to the site and they refer their friends) Once we got traction, we had investors and great technical co-founders knocking on our door.
Another way to think about it is that you’re just going to be a temporary technical co-founder. You just have to know enough to build and iterate on a prototype to get traction.
Here’s what I found that makes it much easier than you would expect:
- Minimum Viable Product (MVP). To get traction, you don’t have to build a complete product. You just have to build some small, core aspect of your idea and get people to start using that. That means you can get something out much smaller, get traction and then bring in a real CTO to help you expand the product. The version of Yipit that got us traction was built in 4 days. It took us a year of customer learning to know what to build. But, from a technical perspective, the MVP that got us traction took us just 4 days.
- Don’t have to worry about scaling and security. Scaling and security are really complicated technical challenges that you don’t have to actually worry about (this assumes you aren’t working on a project where scaling or security are a core aspect of the business). Getting traction doesn’t involve signing-up 1 million users. By the time you run into scaling issues, you’ll have an awesome CTO to help you fix it.
- Doesn’t have to be perfect. I used to worry that my code had to be perfect. Guess what? It’s going to get thrown away and re-built by your future CTO. It doesn’t have to be perfect or pretty, it just has to work. I remember playing with an early version of Foursquare and getting MySQL errors. It didn’t matter because they now have an awesome tech team that re-built it all.
- User interface and experience is more important. You’re not going to be working on your own complex sorting algorithms or MapReduce. Most web startups are CRUD apps. The technology is simple in the back-end, the value created is primarily in the user interface and user experience. UI / UX is a real challenge, just not a technical one.
- Django and Ruby on Rails. There are amazing advanced web frameworks out there that make building a website much easier. A lot of the stuff that would have been a nightmare 8 years ago is trivial now.
- Community help. Whenever you run into bugs / issues when developing, do a google search for the bug and you’ll find someone has already posted it and someone answered it. With StackOverflow, that’s gotten even better.
- Systems Administration help. Setting up your server, dev environment and production environment can be really frustrating and tedious. But, you can hire someone who has already done it and have them set it up for you in less than 10 hours. That’s what I did a year and half ago and that person became our awesome CTO.
- Open source apps. It turns out that pretty much everything you are trying to do on your web app has already been done by someone else. Want to integrate with bitly, someone built that library client. Want to add comments to your site, someone’s built that plug-in. Best of all, they are all free and open source. Worried you’ll pick the wrong one? Who cares. As long as it works, move on. You can always change it later.
I hope this list gives you some confidence that becoming your own temporary technical co-founder is not as hard as it may seem. Of all the reasons I gave above, the most important one is to remember that you just have to hack something together that works. Once it works, get people using it and keep hacking till you get traction. It doesn’t have to be perfect, scalable or secure. It just has to work.
Like working with big data sets?
We’re aggressively expanding YipitData and looking for:
- Data analysts (consultants, financial analysts)
- Data product managers (technical and can work with analysts and engineers to build a system)
- Data engineers (can build complicated systems to collect and process very large data sets)
Email me personally and we’ll meet up! I’m at vacanti at gmail dot com
This is the second post in a a series on becoming your own technical co-founder:
Pingback: Should You Hire a Programmer or DIY? | Vinicius Vacanti
Pingback: Innovation: Part I | The First Part
Pingback: 6 Things You Need to Learn To Build Your Own Prototype | Vinicius Vacanti