How To Make It as a
First-Time Entrepreneur

How to Make it as a First-Time Entrepreneur

This is the fourth 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.

Learning Python

I know the below will seem daunting. It’s a lot of stuff.

I remember reading the Learning Python book and putting it down after 20 pages and having a major freak-out.

What was I doing? I had been out of college for 5 years having learned a ton of finance and I was reading a book called “Learning Python” with a mouse on it?! Did I just hit a huge reset button on my life? Was I even going to successfully learn all of this? Did I even know everything I was supposed to learn?

I didn’t have the benefit of reading the post below. No one told me it was possible nor that I should do it.

But, we were going to have to give up unless I became our technical co-founder and I was definitely not giving up. So, I kept reading the Python book.

Six months later, much to my surprise (though I now know why), I was ready to build any prototype we needed. That made us very dangerous and credible as a startup team. I still do some development for our team and, more importantly, I have a much better sense of what is possible and how long things will take making me a much better founder.

Lastly, you’ll get a lot of skeptical looks from people when you tell them you are trying to teach yourself. Just remember that they’re not in the arena, you are.

It’s Not That Hard

The challenge of building your own prototype isn’t that any individual part is hard (assuming your core innovation isn’t on the technology side and it most likely isn’t). The challenge is that there are so many different components you have to learn about.

The point of this post is to give a high-level overview of each of those components and make recommendations on which one you should learn yourself and which one you should just hire someone to do for you.

Also, I still don’t fully understand all of the components but, guess what, it doesn’t matter. I wasn’t looking to fully understand everything. The goal was to understand them just well-enough to build our prototype and get traction. We now have an awesome tech team that understands them way better than I ever will.

The Major Components You Need To Know

The best way to give you some context around the components is to describe what happens when a user visits a website.

So, when a user comes to Yipit, they make a request from our website by visiting a url.  So, as an example, lets say that a user goes to her New York daily deals page: (note that this exercise assumes the user has already created an account and is logged in)

That request by the user is sent through the internet to a machine that runs your website.  That machine is called a server which brings us to our first component: servers.

  • Servers are machines that have your code, your database and run your website by responding to requests from your users. You don’t buy these machines. You rent space on them.
    • Popular examples: 1and1, slicehost, Amazon Web Services
    • Learn or hire someone: You want to spend as little time on this as possible. It will have no impact on your ability to get traction and is just something you have to set up and fix when it goes down.
    • What we did: We hired someone on a hourly basis, who is now our CTO.  We used and still use Amazon Web Services. Just make sure the person you hire lets you know what to do when the server goes down (it will go down)

Now, the server is just a machine. On that machine, is software that actually handles the request from your user and that software is our second major component: web servers.


  • Web servers are the software sitting on your server that is responsible for receiving the request from the user and sending back a response, usually in HTML, that the user’s browser will display
    • Popular examples: Apache, nginx
    • Learn or hire someone: You also want to spend as little time on this as possible so hire someone to get it set up.
    • What we did: We used Apache at first, switched to nginx and are now back on Apache. I would recommend Apache since it’s more popular. Again, we got this setup on our behalf.  Just make sure you know how to restart the server.

Okay, so now that the server got the request that the user needs her New York daily deals, it needs to respond. But, the server doesn’t know her deals or how to display the deals in a format her web browser will understand. So, it gets a little help. It sends the request to where all the magic happens and our third and most important component: web application frameworks.

  • Web application frameworks are responsible for receiving the request and generating the html page that will get sent back to the user. They do all the work. This is where the logic of your site will sit.
    • Popular examples: Django (built in Python) and Rails (built in Ruby)
    • Learn or hire someone: This is what you have to learn and will be where you spend almost all of your time. If you learn how to develop with these frameworks, you’ll be able to build almost any prototype you want.
    • What we did: I decided to use Python but Ruby is also great. If you have a good friend that’s an expert in either one of these, I would just pick which one they know and ask them lots of questions as you learn. I first bought a book on Learning Python. It’s not critical you fully understands all the ins and outs of Python.  I certainly don’t.  You just need to know enough (for loops, data structures). I then learned Django primarily from the online django book.  Will talk much more about this in a separate post.
    • Tools: I use Textmate to do most of my programming. I use GitHub to manage my revisions. (Ask the person you hire to set github up for you).

While the web app framework will do all the work, it needs a little help because it doesn’t actually have the data.  For our example, it doesn’t have all the new york daily deals. That data sits in our fourth major component: databases


  • Databases store all of the data for your project. Think of them as really large excel spreadsheets with rows and rows of data
    • Popular examples: MySQL
    • Learn or hire someone: You should hire someone to explain this to you and set it up. You should learn enough to run some basic queries off the database and alter the structure. The web app framework obfuscates most of the interaction with the database.
    • What we did: I read this book on learning MySQL. I wouldn’t read past page 300 and don’t worry if you don’t know this stuff to well
    • Tools: I use Sequel Pro to view the database.

While the web app framework will handle the creation of your html pages that get sent back to the server, you still have to write the templates in HTML and CSS which is our fifth major component.

  • HTML is the format that web browsers expect for web pages. CSS is an additional file that comes along with the HTML that helps to style the html.
    • Learn or hire someone: You should learn this. It’s actually the easiest thing to learn. If you have a co-founder that isn’t technical, they should definitely learn this. It’s not programming and it will be a big help to have someone else on the team doing this.
    • What we did: My co-founder Jim learned HTML and CSS.  He read and recommends this HTML book and this CSS book.  In three weeks, he was ready to go.
    • Tools: Firebug running in Firefox is your best friend; it’s awesome. I also recommend PSD2HTML to get your photoshop files turned into HTML. You can then work off of what they did. DO NOT BUY DREAMWEAVER.  It’s a nightmare-maker.

The last major component is Javascript. It’s a programming language that runs on your user’s browsers. You know when you click on certain websites and the page doesn’t reload but a little box pops up or it unhides content? That’s using Javascript.

  • Javascript is a client-side programming language that allows you to manipulate content on your site without requiring the user to reload the entire page. It’s not a necessity but it can significantly improve user interface and user experience of your site. There’s a library written in Javascript that you should use called jQuery
    • Learn or hire someone: You shouldn’t really learn Javascript but rather you should learn jQuery which is a library written in Javascript that makes it much easier to do all the user interface things you want to do on the page. Also, I wouldn’t worry about mastering jQuery, just learn enough to accomplish the user interface improvements you are looking for.
    • What we did: We just read through the jQuery website and did some of the tutorials. It’s pretty easy to get going.
    • Tools: I never found a javascript debugger that I really liked. Firebug’s console mode lets you see if there’s something wrong.

Development and Production Environment

When you launch your site, you will have a development and production environment.

  • Development Environment. This is just a fancy way of saying where you work on your prototype that normal users don’t have access to.  Or even simpler, your laptop. You’ll essentially have a working version of your website with a database, your code, etc running on your laptop. I strongly recommend you find someone who knows their stuff (pay them per hour if needed) to set this up for you. Sit right next to them while they do this and ask lots of questions. It should take them around 5 hours and it would take you a frustratingly long time to do it yourself. If you can, I also recommend switching to a Mac. It’s way easier to deal with than a PC.
  • Production Environment. This is where a live version of your site sits where users can access it. You do work on your development environment and then you push it to the production environment where users can see that latest feature you added. Again, you should have the person you hire set this up and the mechanism in which it gets updated from your development environment.

Other Acronyms and Terms You’ve Heard

When I was starting out, I was always intimidated by the endless list of acronyms that were thrown around. The good news is that if you understand the major components above, you can now fit these acronyms in their buckets.

A few of the more popular ones:

  • PHP, Java, Perl: Just programming languages like Python and Ruby
  • XML: Just a format to put data in like HTML. It’s just another way servers send data to users. It’s typically used for API’s.
  • API: This is just a way for your website to interact with another website. As an example, if you have a website with business listings and you want to show Yelp’s reviews on your website, you use Yelp’s API. That is, your website sends Yelp a request for the reviews of a business with phone number 555-1234 and Yelp returns an XML file with the reviews. Your site parses that XML file and puts the reviews on your HTML page.
  • JSON: Javascript object notation. This is just another format to put data in that’s actually much easier to use than XML. Most API’s give you the option of getting back JSON formatted data in addition to XML data.
  • AJAX: Asynchronous Javascript and XML. This is a way for your website to interact with your server without having to reload a full page. On Facebook, when you like someone’s status update, do you notice that the page doesn’t reload. That’s because it’s using AJAX. When you click on the “like button”, the javascript sends a request to the server to let it know that the status message has been liked without having to reload the page.

You probably have way more questions.  Feel free to ask away in the comments below and I’ll respond to them.  You can also ask through my account.

Lastly, remember that your goal isn’t to master these things but to learn just enough to get a prototype up and running that you can iterate on. Once you get traction, you’ll be able to bring on awesome developers that will have a mastery of this subject matter.

Looking for more specific advice?

I’ve given many people advice on learning to build their own prototypes. Every month, I make available a few slots to give people advice over the phone or in person (in New York). You can book a slot using this form. The rate is $39 for 30 minutes though if you don’t think you got enough value from the call, I’ll happily refund you the amount.

This is the fourth post in a a series on becoming your own technical co-founder. In my next post, I’ll describe my experience of learning python and django in more detail.

  1. Guide to Finding a Technical Co-Founder
  2. Why You Can Become Your Own Technical Co-Founder
  3. Should You Find a Co-Founder, Hire a Programmer or DIY?
  4. Big Picture Overview of All the Components of a Web Service (This post)
  5. How I Taught Myself Python and Django (coming)

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

When Jim and I quit our finance jobs to start the next big thing, we were really unprepared for our startup journey.

We didn’t have startup experience, we had no real domain expertise (our startup wasn’t going to be about finance) and we didn’t know any investors in the tech community.

There was very little reason for them to want to invest in our startup.

Exactly three years later, we raised $1.3 million for Yipit, a daily deals aggregator, from Ron Conway and David Lee’s SV Angel, RRE, DFJ Gotham, IA Ventures and a handful of other amazing tech investors.

This post isn’t about the tactics we used once we started getting interest, I’ll share that with you later and you should check out VentureHacks. The point of this post is more to share how we put ourselves in a position to get interest from high-profile tech investors. Hopefully, it well help you as you try to do the same.

Note:  We didn’t think of raising money as a goal. I highly encourage you to consider starting a boot-strapped cash-flow positive business. For us, the ideas we working on needed scale before we could monetize them which required us to raise funding.

How We Did It

Below are the the key moments in our journey:

  1. Realized we needed traction. This was key. Unless you’ve successfully started another company or have serious domain expertise (we didn’t), you need traction. Traction is essentially positive momentum in customer growth. For us, it would mean sharp user growth. Trying to raise money before traction is largely futile. So, we stopped putting together business plans and powerpoint presentations and set out to build a prototype that would get us traction.
  2. Built relationships with potential investors. While we built our prototype, we started meeting with potential investors.  To be *very* clear, we were not asking them for money and didn’t bring presentations. We just wanted them to know who we were and what we were working on. The first two investors who committed to our round came from these early meetings. I also remember another investor positively commenting that “we were known entities”. In other words, they were more comfortable investing in people they had known for a while.
  3. Released our prototype. The initial version of Yipit was an aggregator of all sample sales, happy hours, deals happening in New York.  We put out a private beta in June of 2009 and publicly released it in December of 2009. By end of January, we had a few thousand people signed-up.  Not bad, but we didn’t have real momentum.
  4. Decided to raise a small seed round. At this point, we had been living off of our savings and had decided to finally raise a small seed round to cover our expenses and start paying ourselves a small salary to end our savings leaking. We met with a few investors and they weren’t interested.  We didn’t have traction. So, we immediately canceled meetings with other investors. We instead turned to people who were willing to invest in us because they believed in us: our friends and family. We quickly closed the round in late January.
  5. Pivoted to focus on aggregating just daily deals. During our meetings with investors, we heard two business critiques: we couldn’t easily scale to other cities (this was true) and it would be hard to monetize beyond basic email advertising (also true). Fortunately for us, while we spent all this time organizing deals, a very successful company launched called Groupon that created deals in cities. By late January, there were 12 companies now doing exactly what Groupon did. We then pivoted Yipit in February to just focus on aggregating these new daily deals. The new version addressed the two main concerns we had heard from our investors: we launched in five cities and we could monetize via affiliate relationships.

    Successful Pivot (Y-Axis is Subscribers)

  6. Pivot got us traction. As you can see from the chart, our user growth shot up and we now had real momentum and traction.
  7. Investors started calling. By April, we started getting calls from investors wanting to know more about Yipit. At this point, we were getting buzz in the press, signing up users and the industry was on fire as Groupon and LivingSocial were raising huge rounds and there were now 40 plus daily deal services.
  8. Decided to raise large seed round.  We decided to raise around $1 million round to build out the team and give us 18 months to hit certain milestones. Because we had built up relationships with investors, we didn’t have to cold email anyone. We just reached out to them and met with the investors that were calling us.
  9. Demonstrated we weren’t naive. As a first time-entrepreneur, investors are worried you are naive about the challenges facing your startup over the next 12 months. Every startup has risks and your startup and our startup are no exceptions. When an investor would bring up a risk, we wouldn’t vigorously defend ourselves saying it wasn’t a risk. Instead we would tell them that it was a real risk for us and we were very focused on mitigating that risk over the next 9 months by doing X, Y and Z.
  10. Got first lead investor.  RRE was the first to commit to investing in us and it all got really easy from there. The social proof of having an investor with a great reputation backing you does wonders for your fundraising process.
  11. Closed up the round. We had calls, meetings with potential investors almost every day in May and closed the round at the end of June. Aside from investors reaching out to us, the best source of investor leads is to ask the investors who are committing to recommend other investors that might be interested. We also used VentureHack’s AngelList at the very end. (Will be sharing more about our experience closing the round in future posts).

Getting Traction was HUGE

As you can see, getting traction was huge for us. But, we were also well-positioned to take advantage of it because we had built relationships with investors and had been keeping their feedback in mind.

If you’re trying to raise money as a first-time entrepreneur, I really recommend you get a prototype out there and find your traction before you spend time creating decks and pitching investors. And, if you need to raise money in order to build a prototype, you are underestimating what you are capable of.

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

Lastly, what are we doing with the new round of funding? We’re expanding the team.

Chad and Steve Left Paypal to Start YouTube

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

Now that Yipit raised a round of funding, we have the amazing opportunity to grow our team of engineers here in New York City.

But, in all honesty, we’re not looking for just great engineers in the way Wall Street, Google or Microsoft does. We want our developers to one day become the next great founders. Starting a successful company is one of the most rewarding experiences on both a personal and outward level. We want you to experience that.

If you just want to be a developer for the rest of your life and makes lots of money, I think that’s awesome but that’s not what we’re looking for right now. We can’t match the salary that Wall Street or big tech companies will offer you. What we can offer you that those companies won’t is an experience that will prepare you to one day start the next big thing.

You may wonder why not just start a company now. The problem is that being a talented hacker isn’t enough to start a successful company. You need a bunch of other skills. That doesn’t mean you can’t try, we did. But, learning these other skills first, will put you in a much better position to be successful.

Other Skills Needed

We spent three years going from hacking together weekend projects to starting a venture-backed company. Aside from the engineering skills, here’s a quick snapshot of the long list of others skills we had to learn along the way:

  • Product management: customer development process, minimum viable products, lean startups
  • Fundraising: pitching your startup, understanding company risks, developing relationships with investors
  • User interface / user experience: user testing, absorbing user feedback, understanding expected paradigms, simple conversion funnels
  • Analytics: what metrics to measure, how to iterate based on those metrics, how to report those metrics, startup metrics for pirates
  • Graphic design: spacing; consistency; contrast; color
  • User acquisition strategies: SEO, SEM, affiliate programs, API, created syndicated content, viral loops
  • Recruiting: attracting talented people to your team; learning how to use job boards, craigslist, personal network
  • Writing: concise website copy, getting company blog syndicated
  • Market analysis: market sizing, competitive analysis
  • Business modeling: lifetime user value, customer acquisition cost
  • PR: pitching tech bloggers; guest blogging; getting featured by big media companies
  • Networking: becoming a member of the community; creating “buzz” around your startup; developing relationships with journalists
  • Outsourcing: know what to do yourself and what to outsource; mechanical turk, elance, virtual admins

It took us three long years to learn all of this. How did we do it? We literally wrote all the skills down, identified the experts in each area and methodically read everything they had written. We also learned by releasing a couple of weekend projects: 140it and UnHub

If I could have gone back to 2007, I would have done it very differently. Three years of struggle is a long time. Instead, I would have worked at a start-up that would have encouraged me to learn these other skills.

That’s why we’re taking this approach at Yipit. As you help us build the technology that will make Yipit great, we want to make sure we help prepare you to become a great founder.

Looking for Two Developers

Right now, we’re looking for two developers to join our team. Send me an email at vin at yipit dot com. You can see more of the specifics on the position and our technologies at our jobs page.

We look forward to meeting you.

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

Traffic Bumps via Chartbeat

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

Last Saturday, we woke up to a surprising alert from Chartbeat, we had a new record for most active visitors on our site Yipit.

It turns out that CNN had run a two minute segment profiling Yipit. By Sunday, they had aired the segment four times and we easily had our best ever two-day stretch across all key metrics including user sign-ups.

Did we get it because we had raised money, crossed 100,000 users or hired an expensive PR firm? No. The following is how it happened.

(If you’re having trouble with the video, try refreshing the page)

Listening to Our Customers

Yipit’s primary product is to aggregate the best daily deals in your city (Groupon, LivingSocial, BuyWithMe, Yelp, Scoop St and 160+ others) and email the best ones to you based on preferences you set.

Since launching Yipit in February, we’ve had a policy to reach out to users that unsubscribe to collect feedback. We send them an email explaining that we’re a startup and offer them a $10 amazon gift card to get on the phone with us for 10 minutes and explain what happened.

I know that sounds like a lot of work, but we actually use a virtual assistant to handle the entire process of setting up the call. We just have to do the calls and everyone on the team does the calls.

In June, we got an unsubscribe from someone with a gmail address. We reached out to him and he explained via email that he had unsubscribed because he lived in Connecticut and didn’t think he would be able to use the New York deals we were recommending. But, he also explained that he was an executive producer for CNN’s Money Unit and wanted to set up a call with us.

Customer Development Process Got Us Profiled

It turns out that he was really impressed with two aspects of how we were running Yipit:

  • We were reaching out to our unsatisfied customers to get their feedback on how to make Yipit better
  • We had pivoted from an overall deals and coupon aggregation service to just focusing on daily deals based  in part on those user feedback calls

After the call, he said they wanted to feature us on a series called “The Turnaround” that focuses on a business that makes a change that leads to more success. As he was telling us about the series, I was thinking to myself that the series really celebrated successful pivots, a key tenet of the customer development process popularized by Steve Blank and Eric Ries. We were getting profiled because we were following the customer development process!

Were We Just Lucky?

Clearly we had been very fortunate that one of the users that unsubscribed happened to be an executive producer at CNN. But, maybe we weren’t as lucky as it seems.

Isn’t the job of journalists to try out new services and report on them to their readers? I would expect that your earliest customers consists of not only early adopters but also a handful of influential tech journalists, magazines editors and executive producers.

In other words, aside from the many benefits of getting feedback from your early customers, yet another reason to talk to customers is an opportunity to have more meaningful conversations about your startup with the journalists who are trying it out. If you have good and meaningful conversations with them, they will probably be more likely to tell their audience about you.

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

This is the third 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.

You have the next big idea but don’t have a strong technical background and you don’t have a great technical co-founder lined up. Sadly, that represents over 95% of potential entrepreneurs out there and it’s a very frustrating experience.

Not all is lost. You don’t need to build an amazing scalable company right away. You just need to get a prototype off the ground that gets traction. Once you get traction, you can attract a great technical team. So, how do you build that prototype?

Three Options For Building Your Prototype

You have three options all of which are hard, frustrating and risky:

  • Keep trying to find a technical co-founder. We tried this at Yipit and couldn’t find anyone.
    • Pros: If you have a great technical co-founder, your startup now has a real future.
    • Cons: You won’t do any work on your project till you find someone. Worse, you’re probably not going to find someone and, if you do, they’re going to be less than ideal.
    • Advice: I wrote a gude to finding a technical co-founder.
  • Hire a programmer. We also tried this at Yipit and it didn’t work.
    • Pros: You’ll have someone working on your project right away.
    • Cons: It will cost you money. You’re not going to manage them correctly. If that initial prototype doesn’t get traction right away (and it probably won’t), it’s going to be a real struggle to quickly iterate and you’ll end up spending even more money.
    • Advice: See this great article on how to hire a programmer.
  • Teach yourself to build it. After failing to the above two, we decided we would teach ourselves. Six months later, we could build almost any prototype we wanted. We got traction with Yipit and now have an awesome technical team working on it.
    • Pros. You’ll have full control over your destiny. You can iterate your project quickly and you’ll have way better interactions with your future technical team. You’ll have this skill for your future ideas.
    • Cons. Your project is going to have to wait till you teach yourself. It will take a serious time investment from you.
    • Advice. I’m writing a series on becoming your own technical co-founder based on my experience. See my first post on why it’s easier than you probably think.

Which Option Should You Choose?

Okay, so which option should choose? There’s a lot of ways to think about it, but I think it really comes down to where you think your startup is going to create real value.

Tech startups create real value in one of three ways: (note: for example companies, I’m referring to their initial prototypes):

  • Technology Innovation. Your service has to be secure, it has to scale immediately, you need PhD’s to help you develop algorithms and you’re probably applying for a few patents.
    • Examples: Initial prototypes of Google, Twilio, SimpleGeo, Aviary, Hunch
    • Advice: Keep trying to find a technical co-founder. In fact, unless you have serious domain expertise, you should reconsider why you are trying to build a start-up that has a very serious technology component.
  • User Interface / User Experience. This represents most startups we see today. The tech aspect is mainly writing and reading from a database and you might build on top of an API. You won’t need to scale right away and it doesn’t need to be super secure.
    • Examples: Initial prototypes of Facebook, Foursquare, Twitter, Yelp, Yipit
    • Advice: Teach Yourself. Your main challenge won’t be the technology but will be getting the interface right. Getting the interface and experience right will require you to iterate the product several times and you’ll want to be in full control over how quickly you can do that.
  • Sales / Marketing. The tech stuff is *really* easy and replicable by many. The key to your startup’s success is your sales, editorial or marketing operations most of which will be mainly happening offline. In fact, you’re initial product isn’t a real tech company, it’s a tech-enabled company.
    • Examples: Initial prototypes of Gilt, Groupon, Thrillist, Gawker
    • Advice: Hire a Programmer. The prototype’s functionality isn’t going to determine your success. It’s your ability to create great content, build a great sales team or execute on marketing channels. Just get something out there and recruit a great technical team later.

As a personal experience, if we had been building a Groupon competitor, we would have hired a programmer. But, since Yipit, an aggregator of all these services, involves more user interface / user experience challenges, it made more sense for us to teach ourselves so that we could iterate on the concept till we got it right.

So, for all the 95% of us who don’t have a great technical co-founder lined up, I hope to encourage you that you can get started on your dream today. Assuming you are not trying to innovate on the technology, either hire a programmer or start teaching yourself.

This is part of a series on becoming your own technical co-founder. In the next post in this series, I will delve into becoming your own temporary technical co-founder based on my own experience staring with a big picture overview of all the components of a web service.

  1. Guide to Finding a Technical Co-Founder
  2. Why You Can Become Your Own Technical Co-Founder
  3. Should You Find a Co-Founder, Hire a Programmer or DIY?
  4. Big Picture Overview of All the Components of a Web Service
  5. More to Come…

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.

Learning Python

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:

  1. Guide to Finding a Technical Co-Founder
  2. Why You Can Become Your Own Technical Co-Founder
  3. Should You Find a Co-Founder, Hire a Programmer or DIY?
  4. Big Picture Overview of All the Components of a Web Service
  5. More to Come…

Steve Job’s Technical Co-Founder

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

“I’ve got this HUGE idea. I just need to find a technical co-founder.” Ugh. I’ve heard that too many times over the last few years and it almost always ends badly.

I was in this situation and we barely escaped. I write this post to put you out of your miserable technical co-founder search and give you some realistic options.

The Challenge of Finding a Technical Co-Founder

To find a great technical co-founder, you need to convince them of the following:

  • Your idea is better than all of their ideas
  • The equity is worth spending all of their spare time working for no money
  • You are worth 50% of the equity of the company
  • You will execute and convert an idea into a big successful business
  • You’re better than all of the other biz people pitching them

This is a pretty daunting list. You see, good technical co-founders are like the attractive people at the dance. They’re hot, they know it, everyone wants to sleep with them, and they can also go home and sleep with themselves (the analogy got a little weird there, sorry). So, why should they pick you?

Your Options

Here are your options for finding a technical co-founder. Notice how little control you have over most of them.

Getting Traction is a Catch 22

  • College Roommate or Co-Worker. Your best bet by far is if you have personally known someone for a while and preferably worked together. They are the ones that know you well enough to believe what you are capable of. If you don’t have someone like this, and most of you don’t, you’re in big trouble.
  • Have Experience. If you have already started a successful start-up, you’re probably not reading this post because your struggling to find a technical co-founder; you have your pick.
  • Have Domain Expertise. You’re starting a new photo sharing site and you were the project manager for Facebook’s photo app; you’re starting a music label disruptor and you worked for a music label for the last five years. As a personal example, when we told people Yipit was going to be a Kayak for the Daily Deal industry, we would have been way more convincing if we had actually worked at Kayak.
  • Traction (the Catch 22 option). This is the only one you can, in theory, control. You’d have a lot easier time getting a great technical co-founder to join you if your initial prototype had 20,000 users and growing. Unfortunately, it’s a bit of a Catch 22 in that you sort of need a technical co-founder to build you the first version to get traction.
  • Social Proof (the other Catch 22 option). If you had Ron Conway/David Lee from SV Angel or Chris Dixon/Eric Paley of Founder’s Collective investing in you, potential technical co-founders would be a lot more interested. Unfortunately, this is also a catch 22 because without experience, domain expertise or traction, it’s highly unlikely they are going to invest in your start up. In many ways, good technical co-founders and angel investors are looking for the same thing.

Your Realistic Options

Most people find themselves here. You don’t know anyone, you don’t have experience, you don’t have traction and you don’t have investors. You just have an idea and a dream. Here are your options:

  • PayPal Offspring

    Go Work at a Start-Up

    • The Hope: You can get some experience and you’ll find your future technical co-founder
    • Why You Should: You don’t have any money saved up and you have no idea how to product manage, acquire users or fund-raise. If I had to go all the way back to 2007 when I left my wall street job, I would have done this option.
    • Why You Shouldn’t: You’re postponing your dream for at least two years. It’s actually pretty hard to find a good start-up job if you have no real engineering or user acquisition / product management skills. There’s no guarantee your future technical co-founder will be there.
  • Become a Key Member of the Tech Community
    • The Hope: You’ll form friendships with potential technical co-founders and work on small projects together.
    • Why You Should: You don’t have to quit your day job. You have good community building skills and quickly become other people’s friends.
    • Why You Shouldn’t: This is easier said than done (I wrote a post on how I became a member of the tech community). I’ve also seen many people become key members of their community and still not find a great tech co-founder because, ultimately, being their friend isn’t enough.
  • Blog About Your Idea
    • The Hope: Your potential technical co-founder will find your blog, really like your idea and admire the way you are thinking about the problem.
    • Why You Should: You don’t have to quit your day job. You already have an online following. It can be good for you to express your ideas on paper and build some domain expertise credibility.
    • Why You Shouldn’t: It’s a good idea to start a blog but it’s really hard to get mindshare and attention for your blog if you don’t already have a following.
  • Hire a Programmer
    • The Hope: You’ll use the programmer to build a prototype that will get you traction and experience.
    • Why You Should: You know what an MVP is and you have a great vision for what it should be. You know how to product manage and you’ve hired programmers before.
    • Why You Shouldn’t: This is really hard and littered with start-up bodies. We tried this at Yipit and failed. I recommend you start by reading this post on how to hire a programmer. This will cost you some real cash- at least $5K for your first version. I say first version because you’re likely to not get it right at first and now you need to fork over another $2.5K for a second version assuming the programmer doesn’t flake on you.
  • Roll the Dice on a Stranger
    • The Hope: You’ll learn to work together and trust each other and they’ll be a great technical co-founder
    • Why You Should: You have no other options and believe you can get anyone to work well with you. This does work occasionally. I highly recommend starting with a small project first.
    • Why You Shouldn’t: This is a desperation move. Start-ups are full of risks, you’re about add on another huge one. Also, think about the self-selection bias, if this person was such a great technical co-founder, why are they responding to your craigslist post. They would have probably been scooped up by someone else. Even if you are able to get some traction, you’ll probably be stuck with a less than desirable technical co-founder.
  • Learning Python

    Build Your Own Prototype

    • The Hope: You can hack together a prototype to get traction and experience.
    • Why You Should: You’ll be able to build any prototype you want and will be able to pivot your company. It won’t cost you real money other than your living expenses. You’ll have full control over the destiny of your project. If you are fully committed, this will work.
    • Why You Shouldn’t: This requires the most commitment  and will require you to be truly dedicated to your cause. You’ll have to quit your day job and do this full time (you’ll need savings to support yourself). If you don’t quit your day job, you’ll have to take a 9 to 5 job and spend 6 to 2 am every night and every weekend working on it.

What We Did

We tried to hire a programmer and it didn’t go well. So, we decided that I would become our company’s temporary technical co-founder. It took me about six months of working full time before I could really build any prototype we wanted. Four prototypes / pivots later, we landed on the current version of Yipit. (BTW, going to be speaking to a few groups about my experience of becoming our temporary technical co-founder. As part of that, will be writing a series on this blog about what I did exactly.)

What Did You Do?

What was your approach to the problem of not being able to find a technical co-founder?  Did you try an option I didn’t list above? How did you find your technical co-founder?

I hope you now have a much better understanding of how “I just need to find a technical co-founder” is actually really hard. But, not all is lost.  You do have some options, just remember to choose wisely.

This is the first post in a a series on becoming your own technical co-founder:

  1. Guide to Finding a Technical Co-Founder
  2. Why You Can Become Your Own Technical Co-Founder
  3. Should You Find a Co-Founder, Hire a Programmer or DIY?
  4. Big Picture Overview of All the Components of a Web Service [To Come]
  5. More to Come…

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

Six months after leaving our jobs to start Yipit, Jim and I realized we had made a mistake: we shouldn’t have picked each other as co-founders.


The Steves: Jobs and Wozniak

Jim and I trusted each other and we were working really well together; but, it became painfully clear that we needed a technical co-founder. We had made the critical mistake of starting a company with someone who didn’t have complimentary skills.  We were too similar to each other.

We tried to find a technical co-founder but it was hard to convince a great technical co-founder to join two “business guys” with no start-up experience. So, we went to Houston’s, our favorite serious business meeting restaurant, and made the decision that Jim would learn front-end development and I would become our temporary technical co-founder.

I had taken a few computer science courses in college but had never built a website nor coded in 7 years. Six intense months later, I had learned how to build our prototype. The code wouldn’t be scalable, but it would be good enough for us to get traction and attract real engineers to join our team.

Meanwhile, Jim, despite having very little technical background, taught himself HTML/CSS and jQuery in a few months. Another major key for our early success is that Jim became very adept at using Mechanical Turk and outsourced manual processes. We used those skills to quickly solve what would otherwise be very complicated technical challenges that would have set us back months.

Three Important Characteristics of a Great Co-Founder

So, having had the chance to experience picking a co-founder and having met many co-founder teams, I’ve come to appreciate three very important characteristics an entrepreneur should look for when choosing a co-founder.

  1. A friend. Your co-founder should be someone you’ve been friends with for a while because you need to really trust your co-founder not to give up on you or sabotage the start-up. Jim and I had been friends for five years. There were serious bleak times on our journey building Yipit and, truthfully, one of the main reasons we kept going was blind loyalty to each other. We had made serious sacrifices to work together and neither one of us wanted to be the one to let the other down by giving up.
  2. Previously worked together. Just because someone is a good friend doesn’t mean you will work well together. Making matters worse, it’s really hard to predict which of your friends will be good co-workers. Fortunately, Jim and I had worked together before in college and for a summer after college.
  3. Complimentary skills. This is the toughest one. You tend to be friends with people who are just like you but your start-up doesn’t need two co-founders with the same set of skills. I always cringe when I hear three friends who all used to be consultants trying to start a company. As you’ve read above, Jim and I were really guilty of this. As far as web start-ups go, a product manager and a developer seem to be the ideal pairing.

There are way more things to take into consideration like fundraising philosophy, outcome expectations, domain expertise, start-up experience.  But, it all starts with the three above.

Also, I’m sure someone in the comments will say: “I just found someone on Craigslist and we sold our company to Google.” Don’t listen to them, they were lucky that the person worked out. More often then not, those start-ups are disaster stories that you never hear about. Startups are full of risk, if you’re not going to mitigate the risks you control (like picking a co-founder), your chances of success will go down drastically.

How to Find that Co-Founder

Lastly, I know that most people’s college roommate wasn’t an awesome CS major or an established product manager. That makes it tough to find a co-founder matching the characteristics I mentioned above.  For those of you, I recommend the following:

  • Work at a growing, successful startup. It’s the place where product managers and engineers become friends and learn how to work together. This is one of the main reasons why so many successful startups are born from perviously successful startups like PayPal and why I’m excited for Foursquare’s, Hunch’s, and Gilt’s progeny here in New York

  • Work on several small projects. If you don’t want to wait, I recommend working on a few very small projects with several potential co-founders with complimentary skills. Hopefully, through the course of working on the project, one of them becomes your friend and you realize you work well together.

Picking a great co-founder is really hard. It’s a tough decision that has serious consequences for your start-up. Please take the time to choose wisely.

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

Odysseus resisting the Sirens

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

On my three year startup journey that lead to Yipit, I had over 30 other completely unrelated ideas. Each time I got the idea, I would immediately start sweating profusely for three straight hours in a ridiculous state of unbridled excitement and optimism. Sounds great, right? Not really. Those new ideas and the emotional frenzy were a serious distraction.

To be clear, the “ideas” I’m referring to are the ones that have nothing to do with your current startup. Switching your startup’s focus to a related area based on what you’ve learned (i.e. pivoting) is a winning strategy and one that Yipit employed twice.  This post also assumes that you are and have been actively working on an idea.  If you haven’t started yet, experimenting with new ideas is a great way to start.

In our case, Yipit had always been about organizing local information and we had been working on it for a while. But, along the way, we spent significant time on other unrelated ideas including:

  • Social version of delicious (summer of 2007)
  • Tool to recommend the best version of the online video you were currently watching (spring 2008)
  • Bookmarklett that smartly shortens your tweet to less than 140 characters. Over 350K tweets shrunk (spring 2009)
  •  2-minute personal website creation using your existing third party profiles. 10K accounts, 40K monthly unique visitors (spring 2009)

I now think of these new ideas as the Sirens of the startup journey. If you listen to their call, your startup journey will cease to make progress. Each of these projects were serious distractions from our initial vision of organizing local information.

The Temptation

To understand why these new ideas can be so tempting, I refer you to the incredibly insightful startup transition cycle.

The gist is that when you have a new exciting idea, you are in a state of “uninformed optimism”.  As you spend more time on the idea and start learning about all of the issues, you get into a state of “informed pessimism”.  This is a bad state that eventually leads you to a “crisis of meaning” where you either turn the corner into “informed optimism” or crash and burn.

Most startups are in “informed pessimism” and heading to a “crisis of meaning”. And, that’s when the Sirens start calling with new exciting and unrelated ideas.  Those new ideas are tempting because they are still in the “uninformed optimism” stage and seem so much better than your current idea.  I fell for it several times.

The Danger

Your ability to become a successful entrepreneur is about taking your current “informed pessimism” idea and turning the corner into “informed optimism”.  If every time you get to the disappointing “informed pessimism” stage, you impatiently hop back to a new idea at “uninformed optimism”, you’ll get caught in a never ending cycle. You have to be patient long enough with your idea to see if you are able to turn the corner.

The Solution

I finally learned to resist these new ideas after reading Tim Ferriss’s post. I now see those ideas for what they really are, “uninformed optimism” ideas. They may seem amazing but you just don’t know about all the issues associated with them.

So, if you are in the “informed pessimism” stage, either plug your ears or tie yourself to the masthead like Odysseus and keep working on your current idea.  Don’t be seduced by the Siren call of that exciting but shallow unrelated idea.

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

No One Wants To Play With Me

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.

I remember walking into my first NY Tech Meetup almost two years ago. I looked around and didn’t know anyone in the 120-person crowd.  After watching the demos a safe two seats away from the closest attendee, I approached someone and introduced myself.  They didn’t seem interested in talking to me and walked away a few minutes later.  After standing around for a few more minutes acting like I was looking for someone, I just walked out.  Ouch.

Two years later, that’s all changed.  I’m now a member of the tech community.  Don’t get me wrong, I get left out of all sorts of tech events (a painful experience of seeing the event get announced on Plancast weeks before and then getting reminded the day of, courtesy of Foursquare checkins).  But, more often then not, I make the cut and, when I go, I’m greeted by many friendly faces. I even get emails from people wanting advice on how to break into the NY tech community which is why I’m publishing this post.

Here’s what I did (like everything else in my life, it’s a logical series of steps):

1.  I realized it’s really important. I didn’t think it was till I had a couple of lunches where people completely changed how I was approaching my work (both on the product side and the entrepreneurial side).  I also read this crazy but brilliant book: Never Eat Alone.

2.  I set up social media profiles. LinkedIn is good and easy but Twitter is the really important one.  After meeting with people, Twitter was a great way to keep the connection alive as most people (including me) are thrilled and flattered whenever anyone responds to their tweets.  The other thing to do is set up a blog.  If you can do it, that’s awesome and it will be really helpful.  I never was able to keep up with it till more recently.

3.  I reached out to my existing network. I found all my existing friends who were in tech and met up with them.  I also asked them to introduce me to other people they knew.  This got the ball rolling.

4. I cold emailed / got intros to prominent young members of the community.  I met with community organizers (Charlie O’Donnell with nextny and Nate Westheimer with the Tech Meetup).  I also met with anyone who was seriously working on a startup.  Out of every five meetings, one will go nowhere, three will be good and one will be amazing.  I had amazing meetings with: Tobin Schwaiger-Hastanan, Fraser Kelton, Jonathan Wegener, Jon Steinberg, Jason Schwartz, Andrew Kortina, Nathan Folkman, Mark Davis, Eric Friedman, Bryan BirsicDave AmbroseJustin TsangGreg Galant and a bunch more I know I’m forgetting).  They gave me advice that would have a profound impact on what I was working on.

5. I went to tech events.  The NY Tech Meetup is a great way to support your community and meet new people; but, if you’re not good at going up to people, you’re going to struggle.  I had more success at the smaller meetups like the NYC Lean Startup Meetup.  You should try to form a quick connection with someone and email them afterwards to set up a breakfast or lunch.

6.  I helped organize an event for founders.  This may have been the most helpful of all.  Jim Moran, my co-founder at Yipit, and I organized an “Entrepreneur’s Brown Bag” with DFJ Gotham.  Every month, 12 different entrepreneurs would get together at DFJ Gotham’s offices for a pizza lunch and we would talk about our challenges.  We no longer do it but, over a seven month period, we met so many awesome founders that turned into great friends.

7.  I joined Soccer 2.0.  I played a ton of soccer growing up and I found out about a tech team that played soccer (you wouldn’t think that’s the best way to put together a sports team but we actually ended up winning our division). Whatever your non-tech related hobby is, I’m sure there are other members of tech community who share it.

8.  I didn’t keep score. My goal with everyone I meet with is to be more helpful to them than they are to me.  I try to spend more of the meeting talking about their stuff than mine.  I try to give them advice / ideas and come up with introductions that might be helpful to them.  Trust me, it all comes back and way more than you would expect.  After I met with Chris Dixon, who was obviously way more helpful to me than I could be to him, I got back to my office and spent four hours going through his site Hunch and sent him a hundred points of feedback.

While it took a serious commitment, becoming a member of the tech community has been crucial for me.  I can honestly say that much of the success that we’ve had at Yipit (funding, product improvement, PR) can be attributed to someone in the tech community who was kind enough to help us out.

(Photo courtesy of Larry)

Vinicius Vacanti is co-founder and CEO of Yipit. Next posts on how to acquire users for free and how to raise a Series A. Don’t miss them by subscribing via email or via twitter.