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.

The Nontechnical Founders Series

Do I need a technical co-founder, and where can I find one?

How long will it take to launch a product?

How do I recruit and interview developers? 

How do I know what programming language to build my startup’s product in?


As a technical startup founder in New York City, I get asked these questions and many like them all the time. There are a lot of smart, young, ambitious, first-time entrepreneurs without any technical background, who seem dedicated to building a tech company. I admire their ambition and their willingness to learn, so I’m always glad to help. 

A large part of building a tech company is the technology. It’s very important. There is of course, a large part completely unrelated to the technology – the strategy, marketing, fundraising, recruiting, and so-forth. These are all great roles that the nontechnical founder can excel at, but I truly believe that the core of an early stage tech startup is its product, and without some semblance of knowledge surrounding the technology piece, you’ll put yourself at a severe disadvantage. 

I have a technical background. A computer science education, a passion for learning and playing with new technologies, and a history of launching products quickly. As such I’d like to write a series of posts dedicated to helping nontechnical founders get up to speed on the technical issues they may be faced with in starting a company these days. Note that I say “starting” a company and not “growing and selling a company.” Unfortunately I won’t pretend to yet have had that experience, and as such I won’t get unsolicited advice about things that I’ve yet to test out myself.


Table of Contents

1. Do I need a technical co-founder?

2. How do I find the right co-founder?

3. What technology should I use to build my product?

4. How long until my prototype will be ready?

Coming soon – What should I do while I’m waiting for the product to be ready?


Every time I add a new post to this series I’ll update this page with the link.

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