How To Make It as a
First-Time Entrepreneur

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.

Family, friends, journalists, potential investors and palm readers will tell your idea is brilliant or foolish but they don’t really know. Very few ideas are clearly amazing. The success of most ideas is very much unclear.

So, how can you find out if your startup idea is good or bad?

Fortunately, there are people out there who can definitively tell if your idea is good or bad. They are brutal, selfish and don’t really know what they want. But, if you put a version of your startup idea in front of them, they’ll either use it or quickly lose interest.

Those people are your potential users. The people whose problem you’re solving and they alone, through their action or inaction, will tell you if your startup idea is good or bad.

The problem is that it takes months to get a working prototype ready. Well, not if you are ready to take a few shortcuts.

The Idea

In late January of this year, we had noticed two things:  people loved Groupon and there were, at that point, around 15 competing daily deal services of which 7 had launched in the last 30 days.

The problem we identified was two-fold: people didn’t want to sign-up for all these new deal services getting 15 emails a day and didn’t want to keep getting deals that weren’t relevant to them (e.g., guys didn’t want spa deals).

We wanted to create a product that would allow users to tell us what kind of deal categories they wanted (restaurants, not spas), every day we would grab all of these new daily deals announced in their market, filter the deals based on the user’s preferences and email the best ones in just one email.

How We Tested It

We could have sat around for a few months asking people what they thought, writing a business plan, modeling out what it would like in five years, thinking about where our headquarters would be, and other irrelevant things.

Or, we could create a very simple prototype as fast as possible. We could see if potential users would sign-up. And, if they did, whether they would open our daily emails, click on the deals or just unsubscribe from our emails.

Building a Prototype in Three Days

We had a long list of features we wanted for Yipit but we cut everything except for the bare minimum:

• Landing page to sign-up
• Page to collect category preferences
• Page to recommend Yipit to others
• Page where you could see all of the deals in our system

In retrospect, we could have done without creating the page where a user could browse all of the current deals.

On the back-end, we needed:

• Script that would send out a daily email with the deals that matched their preferences
• Crawler to grab all the deals from the various sites and put them in our database

All of the above is actually very easy to build.  The only problematic one was the crawler to grab the deals from the various third-party sites.  Each site was different, the urls were weird, duplicate deals would be a problem and categorizing the deals accurately is a hard problem to solve. We quickly realized the crawler was going to take us weeks to build poorly and months to build correctly.

But, what we concluded was that the whether we could build the crawler wasn’t a risk. We could; it would just take time. The real risk was that people didn’t want to use our service.

The Shortcut

So, we said, screw it, we’re not building a crawler. We’re just going to do the deal entry manually and eventually build the crawler if people actually liked our new service.

We created a simple admin page where a deal could be entered in (title, picture, price, etc.). We then hired a part-time person who would wake up every morning, go to the 20 daily deal sites and manually type the deals into our system and assign them to categories like restaurants, massage, spa, etc.  Crazy? Yes. Scalable? Probably not. Did it matter? No.

Finding Out If Our Idea Was Bad

Three days later, we were ready to put our prototype in front of potential users. Much to our delight, people started signing-up and started getting and clicking on our email. They were implicitly telling us they liked our idea! (I’ll write a future post on how to get these early users but basically you get them wherever you can. You don’t need that many to know if your idea is good or bad).

If people hadn’t signed-up or hadn’t clicked on our emails, we would have found out right away that there was something wrong with our idea. But, that would have been okay because we hadn’t spent months on it; just a few days.

How to Find Out if Your Idea is Good or Bad

My main pieces of advice are:

• Build a very simple prototype for your idea and get it in front of potential users. You’ll learn more the day you talk to your first user than the months you’ve spent pontificating
• Don’t be afraid to do things manually at first like we did
• Build a landing page with screenshots that describe your future product and see if people will sign-up for your invite list. Dropbox did that before they had a product and signed-up 100K people.  Clearly, they were solving a problem people had!
• Cut every feature except for the core feature.  Seriously, you don’t need any of those extra features.
• 95% of startups are able to have a prototype built in less than two weeks.
• Don’t write a business plan.

It’s very likely your idea is bad. Find that out as soon as possible so you can evolve it to a better idea.

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

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.

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.

From a PR perspective, I like to think of the internet as an ocean full of schools of fish. There’s the TechCrunch school, the NY Times school, Lifehacker school, HackerNews school and thousands of others.

When one of these services feature your startup, their respective school of fish will suddenly and dramatically swim directly towards your startup. And, as fast as they come, they will swim by you even faster.

You are a fisherman, your startup is your net and your goal is to catch as many of these fish as possible.

If your net (your startup) isn’t well-built and ready for them, the fish will swim right by you and they’ll never come back. It’s tragic and a huge blown opportunity. It happens to so many startups and you can see it in their traffic.

But, some startups have built a good net and they overnight acquire thousands of new happy users.

Here’s how we made sure Yipit, a daily deal aggregator, had a good, strong net to catch as many of these potential users as possible.

“Net” Strategy Depends on Your Stage

Startups are generally in one of the following four stages.

• Stage 0: Visitors Come But Leave
  • They might click around but they don’t activate into a real user. For Yipit, that means they don’t subscribe for our daily email
• Stage 1: Visitors Sign-Up But Don’t Come Back
  • A visitor will like your site enough to create an account but they con’t come back. For Yipit, they pick their city and provide us their email but don’t open / click on our emails.
• Stage 2: Visitors are Retained
  • Not only does a visitor sign-up, but they are coming back regularly. For Yipit, they either come back to the site to see new deals or, for most of them, they receive our email recommendations.
• Stage 3: Visitors Refer Others
  • They either like your service so much they tell their friends or the service itself encourages them to refer others. We didn’t have a great way to track referrals though we could see it with google searches for “yipit” and direct navigation.

Stage 0 and Stage 1: Create Splash Page

Most startups are in stage 0 or stage 1. You should not be actively seeking PR.

Before Yipit pivoted to focus on just aggregating daily deals, we were at stage 1. Users signed-up for our service but they weren’t clicking on our emails, they weren’t using the deals we were recommending and they weren’t referring others.

So, we would direct new visitors to a splash page where they would sign-up for our waiting list. We would then invite them to the site and see if they signed-up and came back. When they didn’t, we would offer them $10 to get on the phone and explain why they didn’t like it.

We got visitors to Yipit in a bunch of different ways: meet people, google ads, facebook ads, some current users would refer new users, friends, people googling us. The fortunate thing is that you don’t need that many users to figure out what’s wrong with the service.

Every startup in stage 0 or stage 1 should build this splash page today. It’s a great source of early test users and, more importantly, you get their emails so you can follow up with them.

I recommend you use Unbounce to build it.  You don’t have to have any technical background to do it.  We didn’t use it because it wasn’t around but would use it today.

Some tips for the splash page:

• Have one concise, huge phrase that explains what problem your startup is addressing. For Tumblr, it’s “The Easiest Way To Blog”. For Yipit, it was “All the Best Daily Deals In Your City“
• The email sign-up form should be on the splash page
• You should A/B test it with different messages
• Have an image or video that explains what the service will do
• See About.Me’s splash page, it’s awesome. Not only do you sign-up for their waitinglist, but you reserve your username. So smart.
• Dropbox had 100,000 users just off of their splash page

Stage 2 and Stage 3:  Ready For PR “Launch”

Based on our all our conversations with users, we pivoted to focusing on aggregating daily deals in February of this year.

Right away, we knew we were in stage 2. Our early users liked the new service, we liked it, they were buying deals, they were telling friends. We were ready to launch.

We made a PR push and got TechCrunch, Wired and a few other companies to cover our launch. When those users came, we converted them into our first five thousand users.

The only caveat for not launching in stage 2 is if you can quickly do a few things that will dramatically increase your referral rate (like integrating with Twitter or Facebook). If that’s the case, implement the low hanging fruit before launching since it can potentially double / triple the impact of your PR efforts.

Had we grown impatient and tried to launch before we were at stage 2, we would have crash and burned after launch.

(For more on the stages of a startup, I recommend Dave McClure’s amazing Startup Metrics for Pirates.)

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.

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.

Naming your startup sounds fun and awesome.

Let’s say you have a music sharing idea, so you’re going to grab music.com.  Wait, that’s probably too obvious. I’ll be creative. Let me try sharemusic.com. Oh, taken. How about Musicster.com, taken. Songster, taken. Songly, taken. Beaster, taken. Uh, oh. That’s when you realize something we’ve all at one point realized, EVERYTHING sensible is taken.

Before you know it, instead of spending time getting your prototype out, you’ve spent way too many days on instant domain search, thesaurus.com, polling friends, telling yourself you’re not going to spend anymore time on it, wondering if a .net domain is all that bad, telling yourself google was a terrible domain name so you shouldn’t care that much, trying to reach someone in Russia who owns the domain you want, finding a domain that’s actually available, buying all 10 spelling variations, realizing 5 minutes and $50 later that you don’t actually like the domain.

We went through all of the above when trying to name Yipit and we came up with a long list of terrible names and these were the ones we actually bought: streetcake, frankencity, 1gotham, citybat, noocher, zaxme. Ugh.

Needless to say, we were very unhappy with our final list and, even worse, we had spent way too much time on it.

So, after the fifth time we had told ourselves we weren’t going to spend any more time on it, we decided to come up with a different strategy.

Bottoms Up Approach to Finding a Domain

We wanted something short and we decided we wanted the domain to end in “it”.  We figured people say  “google it”, and we hoped that one day, if we got popular enough, we could make it easier on people by having the “it” as part of the name. I will be both very happy and very sad if, one day, I hear someone say “yipit it”.

So, I wrote a simple python script to generate every [consonant][vowel][consonant]it.com.  With 21 consonants and 5 vowels, that resulted in 2,205 possible domains.

Obviously, I wasn’t going to look those up individually. Fortunately, godaddy has a bulk uploader that lets you check 500 domains at the time. (If someone knows of a better bulk upload checker, comment below!)

Of the 2,205 domain combinations, around 400 (in May 2008) were available. As you can expect, the ones that were available had Q’s in them with no accompanying U’s and other horrible formations.  It was disappointing. The available domains were terrible but, amongst the trash, we spotted the needle in the haystack: yipit.com.

The best part, it took us just 30 minutes to find our domain!

We both liked it and asked a few friends and family what they thought.  They all really liked it. I couldn’t believe our domain search was over. Yipit was our new company name.

(Hilariously, that same week, we had asked a creative friend of ours to come up with names and she had come up with 20 fun names one of which was “yipit”.)

How to Come Up With Your Own Script

Good available domains are like needles in the haystack. They are really hard to find by trial and error but this scripting technique combined with the bulk checker, lets you get to those needles fast. I recommend you do the following:

• Come up with a prefix or suffix that you like.  For us it was “it”, maybe for you it’s “get” or “un” or “ster” or “me”.  It doesn’t have to be a real prefix or suffix, it could be a suffix like “mo”
• Write a script or use excel, to generate combinations of your prefix / suffix with two / three letter combinations or actual lists of words
• Run them through godaddy bulk uploader and see if a great domain falls out

Hopefully this will help you find your domain and get back to doing what actually matters, building your prototype.

I went back today and ran the script again. I checked all the combinations through the godaddy bulk uploader tool to see which ones were still available and put the available domains in this google doc. The pickings are slim.  My favorite one is Vopit though it sounds a little bit like vomit.

(If anyone else tried a similar approach to naming their startup, let us know below in the comments!)

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 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: http://yipit.com/new-york (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 formspring.me 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…