Making a POST request to a Rails API Endpoint

Here's a rare super-technical blog post. I spent enough time struggling with this seemingly simple problem today, that I felt I should share the answer.

The problem: You're designing a REST API for your Rails app. You want to let people insert records in your application via a POST request. However they submit their POST request via their 3rd party application, and your app throws an InvalidAuthenticityToken exception. Why is this happening?

The background: Ruby on Rails stores an authenticity token for each session, and submits this token as a hidden form field in any POST request upon a form submission. It does this to authenticate that the request is actually coming as a form submission through the web site, as opposed to a random POST request generated from CURL or another tool. A 3rd party application developer certainly doesn't have a token assigned and therefore can't submit this via their API request.

The solution: Rails only checks for the authenticity token in the case of a form submission. If you submit your data as content-type application/xml or application/json, then the token is not required. As a result you can set the content type appropriately and encode your input parameters as either xml or json. See the below gist for a ruby example.

It was hard to find this solution via google. Anyone know a smoother solution? Does the API designer generally disable forgery protection in this scenario on POST endpoints for inserting data via an API? Let me know in the comments or on twitter @petkanics

Quora as a blog subsidy


There's been a lot of buzz lately about Quora, the question and answer startup from ex-facebook employees Charlie Cheever and Adam D'Angelo. The site has done an amazing job of quickly building up a strong community of users including many experienced startup founders, investors, and respected members of the tech ecosystem. I read an interview with the founders where they explained that they didn't exactly see it as a question and answer site that they were building, but instead it was more of a blogging platform where you are writing to an audience who's already opted in to read about what you're writing.

When you come to a question page on Quora and it’s blank there are a bunch of people waiting for the answer. An expert will look at it and say “there’s an audience here and I know exactly what they want to hear. And I actually know about this stuff, or know enough to research and produce a really interesting piece of content, and it’s going to go to the perfectly targeted audience who opted in to hearing about this."

This struck a chord. If you're looking for an audience for your writing, previously you would post to your blog. A few people might be subscribed. If you share a link to your post across your social graph, maybe 100 people will read your post. If it gets picked up by an aggregator or social news site, then maybe a few thousand people will read it. And if all of the above happens and you really hit the SEO jackpot on a previously unfulfilled popular search query, then you may get thousands of readers from search over time. But of course that all begins with an original creative idea.

Now consider the case of writing on Quora. The site has a large audience, with many followers on particular topics such as "startups" or "venture capital." There are plenty of unanswered questions, and if you happen to have some valuable information to contribute in answer to someone's question, you are almost guaranteed that what you write will be of interest to at least that person. And as you're taught very early on in school, if you have a question you should ask it, since someone else probably has the same question. Chances are many people are interested in what you have to say. Your writing is immediately distributed to a list of topic followers, and if what you said is really insightful, it will get voted up and bubble to the top of the answer listing.

There are many reasons to write a blog – writing helps formulate your ideas, you create a personal voice within the greater community, and active discussion follows from intelligent posts. In Quora, all of these advantages are maintained, with the added benefit of a built in audience. So this prompts the question: is your time better spent writing a personal blog, or answering questions on Quora?

I suppose there are two main advantages to a personal blog: If you want to write about a topic where there is no existing question on Quora then you have a place to do so, and on you blog you can include personal branding around your writing. On a blog you can add pictures, video, and other media to your post. However it would be nice to subsidize your blog content with your own Quora answers as well. When the Quora API is available I'd like to write an importer which optionally autoposts Quora answers as blog articles with the question as the title of the post and the answer as the body. This would create a nice steady stream of blog content with the addition of distribution of your voice to the Quora audience. Two birds with one stone. 

Now to figure out how to reduce the SEO hit on duplicate content…

The internet never sleeps


When people ask me to describe my regular workday, I usually start off by mentioning that I spend from about 7:15-7:45am "catching up with the internet."

You see, it seems as if this post-web-2.0 internet consisting of realtime, social, and mobile is an organism that never stops moving. It's constantly spewing off news stories, tweets, startup launches, blog comment discussions, and genius viral campaigns. Not only is there a 24-hour news cycle, but there's a 24-hour discussion cycle amongst my friends, my colleagues, and people whom I aspire to one day become my colleagues. And there's something to learn from all of it.

So during my waking hours, even though I don't spend every minute working, I still try to spend as much time as possible absorbing. It's not that hard to stay current on the pulse of the internet because I'll either catch an update on twitter, hear someone in our workspace talking about the latest controversy, or get an email asking me what I think about the hot new datastore. But when I sleep, the internet keeps moving forward. The debates of the day ramble on late into the west coast hours, and intelligent people contribute valuable information to the general collective knowledge base. And it really burns me up inside to feel like I'm missing out.

Am I missing out? In the grand scheme of things probably not. If I don't hear about news that broke 6 hours ago while I was sleeping, then it probably wasn't important enough to be worth knowing anyway. But still, it's hard to tell what's worth spending time on and reading in the morning, and what's not worth the 10 minutes that could be better spent elsewhere.

There are a number of services out there which try and recommend worthwhile content to you based on your past habits, topics of interest which you've tagged, and the influence of other people like you in the system. The smart folks at are working on content recommendation system like this, as are the bright minds at Pinyadda, among countless other startups. If these services can truly recommend useful content, and more importantly do it in realtime, then it will be interesting to see how they turn out. I think it may be overly optimistic to expect that the realtime aspect will be effective, so instead I would like to recommend another approach: curated personal daily briefings.

When President Obama gets up in the morning, he doesn't even have to ask, "What's going on?" There's already a large team of people who's sole task it is is to provide him with a briefing on every area of governance that he's concerned with, and they're all waiting and ready to give him a report. I'd like an analogous team ready to give me a briefing on what's going on, as well as to tell me what is worthwhile to follow up on on my own. 

Sounds like it's pretty far fetched, eh? Maybe not. Consider that I'd be satisfied with one person very similar to myself, a good friend and fellow NYC startup hacker-founder perhaps, who happens to be paying attention to the internet during the 12 hours that I'm not, giving me a 10 minute briefing first thing in the morning. I'd be happy to return the favor for him during the time he wasn't paying attention. We'd read similar news, be interested in similar topics, and follow similar sources on twitter. Now, with just two people playing this role there'd definitely be gaps when we'd both miss something, but what if there were 4 people and we only had to report once every other day? What if there were 10 people? 60 people? Each person would be responsible for creating a curated update of the past 12 hours once a month to contribute to the group. Seems reasonable to assume there may be 60 like minded people in the same ecosystem looking to benefit from these updates.

Now what if there was no need to organize a group like this at all, and instead there was a service that you could pay for these on-demand updates. Maybe I wouldn't subscribe individually to pay out of pocket (I probably would actually), but it would certainly be beneficial for a startup to pay for this for each of their employees. The productivity gains would be tremendous by eliminating the need for every individual to filter through all the content on their own. A service could deliver updates to subscribers via podcast, via email, via personal phone call, and it could be customized to each person based on their interests and sources of preference.

I haven't taken much more time than it took to write this to think through everything, so with more thought it could obviously be tuned. But it seems like a curated wire news service for niche groups based on their ecosystem and preferences would at least be useful, if not profitable.

Key takeaways from The Facebook Effect


I recently read David Kirkpatrick's new book The Facebook Effect, which chronicles the history of Facebook from the pre-creation days in a Harvard Dorm Room to the 400 million user platform and advertising behemoth that it exists as today. It was a very pro-facebook, pro-Zuckerberg account as compared to much of the media coverage that has been given to Facebook over the years, and while it points out the mistakes they've made along the way, it generally gives the young founders the benefit of the doubt. Overall, I found the book interesting and worth the read simply for the Facebook story, but from an entrepreneur's perspective, there were three key takeaways for me that will shape the way I think about building our current company.

1. Ride a big theme
Shortly after the founders experienced the early success of Facebook on their campus, they realized that they were onto something big. But their goal was never to build a business that had one product which was an intercampus social network. Their goal was to increase sharing in the world. They felt that by making the world a more open place, they would make it more transparent, bring people and cultures closer together in the global ecosystem, and as a result it would be a better place. Their business wasn't based around selling one product or even one feature within a product as some businesses are. Their goal was the change the world.

By riding this enormous theme of sharing and openness, Facebook was able to address a market of almost every person on the planet. Sure they needed a product which would facilitate their themes, and they had a great one, but they were really starting from a point of almost limitless growth potential.

2. Timing is critical
You often hear people say that they had the idea for Facebook before the launch of Facebook. And sometimes in tech circles you even hear people say that they built a Facebook style service before Facebook but it never caught on. Well here's some news: lots of smart people spent lots of time and money building Facebook style social networks long before Facebook even launched. And some were actually moderately successful. However many just didn't have the timing that Facebook had and the world wasn't ready to embrace a global social network yet.

What made their timing so accurate? There were a couple of contributing factors including people's willingness to accept transparency online, proliferation of broadband internet, and the rise in popularity and availability of cheap digital cameras. 

Companies that created social networks before broadband internet had a hard time convincing their users to wait around for endless page loads and no photos. Facebook users spend a tremendous amount of time on the site because they can keep clicking from link to link, from photo to photo, and get instant satisfaction. Try that before broadband. 

Social networks that launched before people were comfortable enough with the internet to put their information online had a hard time getting people to use their real names and information. Facebook only let users use their service with their real name and identity, and therefore there was an enforcement on the site that you couldn't misbehave or your reputation would suffer. In 2001 people were scared to enter any information online, but in 2004 people were ready and the timing was right.

The Facebook photos feature was really the first application built on top of the Facebook social graph, and it was a gamechanger for the company due to the amount of time that users spent on the site after the launch. But photos on other networks just weren't popular until everyone had a digital camera with which to take the pictures. 2004 was probably one of the earliest years that you could expect your average college student to possibly own a digital camera. And if they didn't own one, they could buy one for a couple hundred bucks in order to join in the facebook photo frenzy.

When thinking about your own business, you need to look around and leverage the emerging trends (or even better yet the trends that are just about to emerge), and use them against existing, slow moving competition. Look at recent changes in the world and technology and take advantage of the latest ways that people are spending their time and money.

3. Product vision is key and needs to be protected
Mark Zuckerberg really was a product visionary. He somehow knew what users would want, before they even did, and he was almost always correct in his predictions. The protection which he gave his vision was paramount. He was endlessly harassed by investors, officers of his company, and even the public at times to consider major changes, but he fought them off hard and committed to building the product that he wanted to build. 

Ben Horrowitz wrote yesterday in his discussion on why they funded Foursquare that "The only thing better than the CEO being the keeper of the vision is the CEO being the creator of the vision." Facebook had this CEO with the right vision, and he knew never to compromise the vision or the product for short term wins. If he had, Facebook would likely be chock full of banner ads and part of the Rupert Murdoch empire.

Why hacker angels is a great idea

I was really excited to hear recently about a new collective of investors known as hacker angels. Their simple web site describes the group as:

an informal association and not a fund. 
If inclined, we may provide feedback, advice, 
mentorship, hacking, investment and/or serve 
as advisors or independent board members, 
on an individual basis.

While their web site may be understated, their accomplishments are not. They've been the developers and entrepreneurs behind some very successful web products, and they're the exact type of mentors that young hacker entrepreneurs need in the early stages of their business. This group of guys will not only be able to provide investment to the companies that they work with, but also invaluable advice about how to go from product to business.

I predict that they will have success in backing very smart hackers, very early on in their careers. While your average recent MIT graduate may be intimidated by traditional finance focused investors, they'll be able to relate easily, and therefore trust the hacker angels. Fred Wilson has written about VC's Who Code, and the great perspective that they provide in later stage VC deals. I imagine that the hacker angels will provide a similar barometer on early stage financings.

Who I want to work with

Things over at JumpPost have been moving very quickly, and we’re excited to be making our first full time hire. We’re looking for a lead product designer, and the full job post can be found over at TheResumator.

We’re a product focused company, and as such our product designer will play a key role in the success of what we’re building. Since I’ll be working closely with this hire every day, I figured now would be a good time to declare who I want to work with in an ideal world outside the guise of a formal job post.

It goes without saying that our product designer should have a great sense of design. Show me what you’ve designed before, show me that you’ve created great user experiences, and show me that you go the extra mile to really take ownership of the full product experience from beginning to end.

You should not only be able to think in terms of product experience, but you should be able to implement your designs as well. I can do all the back end coding and get you the data that you need, but you should use your HTML, CSS, and javascript skills to make the design a reality. Implementation and execution are everything.

You should be fearless. Designing for the web is one thing, but you should also jump at the opportunity to switch gears and work with UIKit to design for the iPad, work with FBML to distribute our listings into Facebook, and design widgets to be embedded across the web. We’re thinking a lot about distribution at JumpPost, so all environments are fair game. These skills aren’t required in advance, but you should have the guts and confidence to work with us to learn them as required.

One of our greatest strengths as a young company is that we have big ideas and we build quickly. I’m far from a brilliant programmer, but I have confidence in my ability to build whatever it is that we dream up. If you feel the same way about yourself as a product designer, I’d love to talk to you. Check out the job post, and get in touch.


How long until my prototype is ready?

This post is part of the Nontechnical Founders Series – a set of posts aimed at helping would be nontechnical startup founders get answers to their questions around the technology side of starting a company.

In previous posts I’ve written about collecting the right resources in order to launch an internet product. I covered skills your technical co-founder or contractor need to possess and what technologies they should be comfortable with in order to move quickly and create a solid foundation from which to grow your company. The next logical question is, “How long will it take the team to build the product?”


As with everything, the answer is that it depends on what type of product you’re creating. Let’s assume that you’re building the usual data driven web application, and that there’s not any core deep technical IP requiring unending research. Let’s also assume that the product is being built by one core developer (either your technical co-founder or your hired contractor) with rough competency in all areas of the development stack, and a contract designer. 

The short answer is that you should push for your product development to move quickly. It’s no secret that I’m a big fan of releasing early and often, and as such, it’s not necessarily important that the “release” version of your product contain every single feature which you’ve been dreaming about for months. As soon as the developers have a product that does anything, they should push it live so that early users can begin poking at it. How long should this take in the case of the basic web app? Probably about a week for an undesigned version, and probably about 2-3 weeks for a designed version. To give you an idea of the scope of what you can expect in this timeframe, let’s take the following example:

You’re building a facebook clone. In just a couple of weeks users should be able to sign up, create a simple profile with a profile photo, and add and remove friends. On one hand that doesn’t sound like a facebook clone at all (no photo albums, tagging, chat, applications, etc), but on the other hand think about the basic functionality and what’s been accomplished in just a couple weeks. After this base is in, it’s easy to add features one by one every couple of days. But if you never released this basic functionality after week one, you wouldn’t have any early users (even if it’s just your team, friends, and family), and you wouldn’t be getting any feedback about how to best move forward. 

Okay, so a couple of weeks to launch a simple prototype that does something but nothing interesting. In the case of the facebook clone, maybe you’d like to get to the point where people can write on one another’s walls, create albums, and tag their friends? At that point you’d feel comfortable “launching” to the world.  How long does it usually take to iterate to an interesting point? 

It shouldn’t take longer than 3 months. I arrive at this rather rough estimate by looking at the startup accelerators as good examples. Programs like YCombinator, TechStars, and DreamIt generally run for about 10-12 weeks, and at the end of the program most teams have an interesting product to pitch to the media and investors. If these programs have learned through years of experience that most consumer web applications can be built and demoed in under 3 months when the founders buckle down and get to work, then this is what you should shoot for yourself if you’re launching a similar product. If you are using an agency instead of an in-house team, expect development time to be 2-3 times longer. This is due to the overhead of communication, going back and forth with changes over the span of weeks instead of hours, and the inevitable second guessing that occurs when you have one party thinking and the other party blindly responding.

If you want to move fast, then I would like to emphasize one key lesson I’ve learned: release your product as soon as possible. Immediately. Don’t even wait for it to work fully. When you keep your product behind closed doors, it tends to fester. You spend days or weeks debating key feature decisions with your team, and you use unfinished features as an excuse to delay launch. Compare this to a simple product that is out in the open being used by actual customers. If you feel embarassed that they’re not experiencing the complete product in all it’s glory, then you’ll race to enhance the product every single day. You’ll know what the most pressing need is, and you’ll get it implemented quickly to create a better experience for your users. Your product will grown organically instead of in a contrived way, and you’ll know very quickly what’s important and what’s unimportant.

Good luck, and get to work.

What technology should I use to build my product?

This post is part of the Nontechnical Founders Series – a set of posts aimed at helping would be nontechnical startup founders get answers to their questions around the technology side of starting a company.

I often get asked by nontechnical startup founders what language they should use to build their product? Since they won’t be writing code themselves, what they really are looking for are the buzzwords to use when writing a job ad for a developer or potential co-founder. This is of course important, because if you write a job ad asking for mainframe experience and strong knowledge of qbasic, you aren’t very likely to attract the talent you’re looking for to help build your company. 

I’ll start by saying that if you have a strong technical co-founder on board, then you should trust their judgement to build in whatever language and platform they are comfortable with. But for the purposes of this article, let’s assume that you aren’t so fortunate. Let’s also assume that your product is a consumer facing web application. If you’re working on something deeply technical, mobile, or embedded, then either your language choice is already made up for you, or you’ll probably need the know-how in advance. When building your standard web application however, you have no shortage of choices.

Some choices will lead to rapid development, the ability to attract A+ talent, and a large community that you’ll be able to leverage for years to come. Other choices will lead to a development team of one, unable to expand. 


Background – Languages, Frameworks, Platforms

You’ve probably heard these terms thrown around a bunch, without really having any idea what they truly mean. Here’s the quick overview.

A programming language is the basic tool that a programmer will use to write your application. Each language has different strengths and weaknesses. Some are harder to program in and require more code, but run faster and use less memory. Others require less code and are easier to program in, but may run slower. Examples of languages are C, Java, Python, Ruby, PHP, Erlang, and on-and-on.

A web framework is a tool that simplifies many of the tasks that programmers would otherwise need to reproduce over and over again when creating a web application. Each language has a number of different frameworks to choose from, and the choosing a good framework is much more important that choosing a particular language.

A platform is an environment which your application will run on. It can be a server that you buy and stick under your desk (not recommend). It can be a cloud based system which will help with scaling, backups, and deployments such as Amazon EC2. Or it can even be a special purpose destination environment like Facebook the iPhone. The right platform will simplify maintaining your site and keeping it up and running.

Okay, so finally, what languages and frameworks should you choose?


The Big Boys

These languages and frameworks all are pretty trendy in the startup world, have no shortage of adept and fast moving developers, and are proven on popular real world applications. You’ll be safe with any of the below.

Ruby – The ruby language paired with the Rails framework is a popular choice these days. It favors convention over configuration which means that any Rails programmer can drop immediately into any Rails application and have a very good idea of where to get started. It’s built to support rapid development and prototyping, it has a great community working on updates and plugins, and it’s not going away any time soon. Ruby/Rails developers tend to be expensive but worth it. There are also other Ruby frameworks such as Sinatra which are suitable.

Python – Much like the Ruby community has Rails, the Python community has the Django framework. Everything mentioned about Rails applies equally as well here. Python and Ruby are both high level languages that are easy for developers to program in. Expect good things from the Django crowd.

PHP – This language runs some of the biggest sites on the web including Facebook, WordPress, and Flickr. It has the lowest barrier to entry among the three languages mentioned here, which means that programmers tend to be a little cheaper. (It also means you generally have to be more on the lookout for bad PHP coders). It has a number of good frameworks such as CakePHP and Zend

Javascript – A developer won’t necessarily build your entire site in javascript, however it’s a skill that’s very useful to have on your team. Developers use javascript to make your web pages dynamic, and provide nice visual effects. You’ll want someone familiar with javascript working on your web app.

Safe Options But Be Careful

These languages and frameworks are fine if you have the right technical lead who knows what they’re doing and have plenty of experience. They tend to be a little more old school than the frameworks above, but they’re proven, and will get the job done. The pace of development might be a little slower, and the younger talent may not be as eager to join up to work on these projects. 

Java – The java language is an old favorite in the enterprise. As such, there’s no shortage of ex-big-co employees who will have experience building large applications in java. Unfortunately java applications, and their frameworks such as Spring, have relied a lot more on configuration than the current frameworks, and haven’t quite evolved very quickly over the last 10 years. There’ll be plenty of cheap employees around to work on Java projects, but you may not be the most attractive shop in town.

.NET – Microsoft’s current platform is called .NET, and it has a number of languages to choose from, but usually pair ASP.NET with C#. Like Java, .NET is a favorite in the enterprise, and there’s no shortage of developers around who will have experience here. Developing in .NET generally takes place on a windows machine (unlike many of the above options where developers prefer Macs or Linux), and it’s accomplished inside a really nice program called Visual Studio. Unfortunately, the licenses for this suite, and the servers to run them on, are very expensive. So if you choose .NET, be prepared to pay.


Stay Away

If a developer tries to convince you that he’s going to build your web app in any other language, advise strongly against it. There is no doubt it’s possible, and the developer could even do an incredible job. However it’s not likely that you’ll attract a strong team, and be able to grow it as necessary to support an unconventional choice.

Another thing to watch out for is a developer who tells you that he’d like to use his own homemade language or framework. Again, they may be very capable, but it will be hard to find others jumping at the opportunity to join on.


Developers are generally very strong-minded about their programming languages of choice. I didn’t write this article to incite a holy war or to offend anyone. I would just like to give nontechnical founders and idea of the current landscape of frameworks commonly in use in the startup world. If you have any other suggestions or think that I’ve missed anything, feel free to let me know in the comments.

How to find a technical co-founder

This post is part of the Nontechnical Founders Series – a set of posts aimed at helping would be nontechnical startup founders get answers to their questions around the technology side of starting a company.

So you’re committed to founding a tech startup, and you know that you need the right technical co-founder to come on board to build and launch your product, right? Good. Now where do you find this mythical co-founder, and how do you know what to look for?

I’m not gonna sugar coat this. Finding a technical co-founder to partner up with you and build your product from scratch will be a long, time consuming process. Unless you have plenty of money to offer up front in salary in addition to large amounts of equity to give away, expect to spend about 2-6 months on the hunt for the right co-founder. Since you won’t be working on your product in the meantime, the best things you can do are to get smart on your business, and to contribute intelligence to the community.

The worst thing that you can do is try and recruit a technical co-founder based solely on the idea that you came up with the previous day. If you’re not really smart on the idea, and already well connected within your market, there won’t be any incentive for a technologist to join up with you and build your product for you for only 50% or less of the business.

Getting smart on your business should be a given. Do the market research, talk to as many people with knowledge on the subject as possible, come up with a set of assumptions around a strongly crafted model that will need to be proven, and then collect data on those assumptions. 

Contributing intelligence to the community is a little bit less intuitive. The easiest way to get your voice out there in the open is to start a blog. Write often about your business, your thoughts on technology, marketing, distribution, and existing business models. Comment on other well read blogs, and engage in the discussion. Aside from writing, actually participate in community events, attend meetups, speak on panels, and schedule frequent meetings with potential candidates for the co-founder position.

You’ll meet plenty of these candidates through the startup community in your city if you put the time and effort into immersing yourself into the experience. Contact people from the online communities like Hacker News, email people you’re connected to on LinkedIn, set up followup meetings after you meet a potential candidate at a meetup. 


When you actually talk with technical candidates, how will you know you’ve found the right one?

First of all, look at what they’ve already built. This will be the best evidence of what they’ll be able to build again. If it looks like, sounds like, and acts like the product that you want to launch for your business, then that’s a great sign.

Secondly, ask them what their specialties are, and what they contributed to their previous projects. At the early stage of startup life, it’s important that you hire generalists and not specialists. That means that you’d rather have someone who’s built an entire application from beginning to end, instead of someone who was pigeon holed into just working on the design, or the front end, or the database, or the API. A key word to use here is the full stack. This means that they’re comfortable working in almost every area from the database all the way up through the front end design. The right technical lead for your team will have worked on all of them a little bit. They needn’t be an expert at any one area, and in fact they may be really weak at certain areas, but they need to be confident that they can at least find the right person to help them out when needed.

So if the candidate seems to get along well with you, they’ve built something interesting before, they have the commitment and tenacity required in a co-founder, and they seem to have confidence in their own technical ability, do you sign them on the spot? No. There are still two more steps that I’d recommend. 

You’ll want someone technical who you know and trust to interview them to vet their technical ability. Your trusted friend will be able to dig deep on technical ability to make sure that they really will be able to live up to what they told you they will. Even if they pass this test, I recommend you’ll want to work with them at least on a trial project to see how the two of you work together. Pick a small project (it can be unrelated to your business), and you work on the business related strategy while they work on the technical side. After a few days if everything still feels right, it might be a match.

I’ll leave you with a high level checklist. All of these needn’t be fulfilled, but the more that you can check off, but more likely the long term partnership will be successful.

  • They’re highly technical
  • They have active projects online that they’ve built and can show you
  • You get along personally (don’t need to be best friends, but at least need to tolerate each other)
  • They’re a good communicator
  • They’re around your age
  • They’re located in your city
  • You have similar financial needs over the coming years
  • They come with strong references that you can check out
  • You both have similar goals about what you want out of the company 

Good luck. As a highly technical developer who’s joined up as a co-founder with a nontechnical partner, I can vouch for all of the above from the side of the person who’s being recruited. Disagree or have any thoughts? Let me know in the comments or on twitter.

Do I need a technical co-founder?

This post is part of the Nontechnical Founders Series – a set of posts aimed at helping would be nontechnical startup founders get answers to their questions around the technology side of starting a company.

Do you need a technical co-founder? The short answer is yes.


If I have one piece of advice for an aspiring nontechnical startup founder, it would be to find yourself a technical partner. Nothing will accelerate the process of getting your product built, shipped, iterated on, and improved than having core technical talent within the founding team. This is hardly an original idea, and it is often preached around the tech community these days.

But why is this so important? Can’t you just hire a technical employee or outsource development?

You can, but it will be slower, more expensive, and far more unreliable than having a partner who has the knowledge, drive, and incentive (being a partner in the company) to put out the best product possible. 

As an early stage founder, presumably on a tight budget, your goal should be to get version one of your minimum viable product (to be discussed later), launched as quickly and cheaply as possible. Until your product is out in the open and you’re getting feedback from your users, you don’t even know whether you’ve build the right product. Sure you could get an agency to build your prototype within your budget, but after you get feedback and need to make changes, the bills will start to add up. It often takes many iterations to get the product on the right course, and iterating on a per-hour or per-project budget is not the way you want to preserve capital in the early stage. For this reason, I’d advise that outsourcing your product to an agency is the worst way to launch a business.

Hiring a technical lead, who’s not a partner/co-founder, is a slightly better alternative. If you have the funding to do so, and you find the right candidate who’s willing to be incentivized by salary instead of equity, then this can work. There are at least three reasons I can think of why this is subpar to having a technical cofounder. It’s going to be more expensive cash wise, the employee won’t be as incentivized to work above and beyond their expectations of what they consider standard, and they’ll be far more likely to leave when a better offer comes around.

But having that right technical partner will pay dividends many times over in the early stage when your product gets prototyped, released, and iterated on a daily basis. When you want to test something out or try a different direction, your co-founder will say “can-do” and you won’t have to worry about making the stressful decision about whether to put another 5-10K against an agency developed prototype feature. Imagine this scenario playing itself over time-and-time-again in the early days of your company, and trust me, you’ll be glad that you have a technical partner to go to battle with.

Of course it’s important to find the right partner, and not just settle for the first one that comes your way. What should you look for in a partner and how will you know when you’ve found the right one? More on that in the next post.

If you’re interested in following along with the Nontechnical Founders Series, or know someone who might be, you should subscribe to stay up with future posts, or follow me on twitter.