How to hire a programmer to make your ideas happen
2010-06-19
Do you have an idea for a website, online business, or application, but need a programmer to turn that idea into reality?
Many of my friends have been in the same position, so here's my best advice, below.
But first, a quick request: If you are a programmer, please leave a reply below with YOUR best advice. Feel free to include your URL and email for anyone to contact you. I know my advice is not complete, (and you may totally disagree!), so any further advice is appreciated.
1. Reduce your big idea to “Version 1.0”.
First read my short “Version Infinity” article.
Dream the big dream of everything your site/service/company might be some day, and write it all down.
But then think of the bare minimum that would make you happy, and people would find useful. What are the three most essential features? What is the most essential feature?
Call this Version 1.0. Save the rest for later. No need to even tell people about the rest unless they're really really interested.
A programmer is much more likely to say, “I can do that!” to this simple version.
Your goal here is just to get Version 1.0 built. That, alone, will be a huge accomplishment. Everything below is describing only Version 1.0.
2. Write a simple overview of what it does.
Again, remember: only describe Version 1.0. Stop there. The big version is written down somewhere else.
Leave off all details that the programmer doesn't need to know.
For example: If you want to sell videos, you don't need to say what's in the videos. Just “sell downloadable and streamable video files.” If you want the site to translate ancient Arabic poetry to Spanish to increase global tolerance, just say, “Translate paragraphs from Arabic to Spanish.”
Be succinct. Programmers love that.
Include people in a story, using the terms you use.
For example: “A company creates an account, then creates a new project with a title and description. In the project, they upload multiple documents to be translated. Each document has a from-language, to-language, and a name. The system counts how many words are in each document. When the company marks the project as ready, it is announced to the translators. The announcement shows how many documents, how many words, and a price. The translator rejects or approves. They log in to translate the documents, one at a time, marking each finished when done, which sends the file back to the company for review.”
From this, the programmer will look for nouns and verbs, so start to think in those terms to help you communicate better. (A programmer would see: Company, Project, Document, Translation, Translator, etc.)
3. Write a detailed walk-through of every click.
Close your eyes and imagine yourself using the site.
Describe every thing you can click on the first page.
What happens when you click it? Exactly what did the system do? What happens next?
Start to think in IF-THEN branches. Example: “If it's a new user, it takes them to this welcome page. If they've been here before, it takes them to their account page. If it asks for a number, but they type a word, send them back to the same page but with a message.”
In a text file, write down every thing you know this Version 1.0 needs to do. Every click. Every action. A long list of small simple things.
Start to think of the exact wording of what you want it to say, but save that somewhere else. Don't clutter this list with wording.
The goal is to keep this long list of actions very clear and simple, so that a programmer can see it, and see that each step is easy. For them it should be like eating chips, not an elephant.
4. Break it up into milestones.
We tend to think of other people's work as easier than it is.
So break Version 1.0 up into many “milestone” steps. Think of it as a day's work. (It might take more or less than a day.) The point where they upload their work for you to test. Where you test it and are happy that little piece works.
Don't expect it to look pretty at this stage. Expect it incredibly ugly but functionally working. Like building a house, the paint and decor goes last.
For example: in my translation site story, above, the first milestone might be just a plain ugly web page where a company can create an account, create a new project, then upload named documents into that project. That's it! If that works, that's a good start.
Thinking of your project in milestones makes all the difference. You'll stop and communicate at each, making sure you're happy before continuing. Misunderstandings can't run on too long. You'll estimate time and cost better. And you'll both feel a good sense of momentum.
5. Make your first milestone a stand-alone project.
To find a programmer you like, you need to take just the first milestone, and treat it as a complete project.
Open a new text file, and copy just the parts of the story and walk-through that are included in the first milestone.
If a feature doesn't come until after the first milestone, remove it from this copy of the story. Remove it from this copy of the walk-through.
This text file should contain a start-to-finish project that sounds like a day's work, and mentions nothing else.
Now start to prepare it like a help-wanted ad. Say, “We are hiring a developer to create only the beginning of an application. If this milestone is completed well, there will be more work immediately. The requirements are as follows....” Then paste just the story and walk-through for your first milestone.
Because you don't want them to just say, “I finished. Here's the source code,” make sure you finish with something like, “For completion of this project, please have this up and running on a development webserver I can access to test its functionality as described.”
Because posting this help-wanted ad will bombard you with dozens of offers that sound legitimate but have never read your ad, you should really do this step: At the end of your post, write something like, “VERY IMPORTANT: To separate you from the spammers, please write I AM REAL as the first line of your bid. We will delete all bids that do not start with this phrase, since most bidders never read the requirements. Thank you for being one who does.”
Get this all in a plain-text file, ready to paste.
6. Post it at elance, guru, odesk, vworker.
Go to the following sites to open an account at each: elance.com, guru.com, odesk.com, vworker.com
Post this short project at each site. Use their escrow service. Location of provider doesn't matter - they can work from anywhere. Don't pay for a highlighted listing. Pay by the hour. Set the bidding time limit to 7 days. Most bids will come in the first 3 days.
You'll get many offers, but if they don't have your magic phrase at the top (“I AM REAL” or whatever), delete them. This is very hard to do, since you'll feel thrilled that so many people are offering to help, saying things like, “We have looked at your project and would be glad to complete it immediately,” but trust me and delete those. If they didn't read something marked as VERY IMPORTANT already, you don't want to work with them.
Also important: Only go for providers who have great reviews from many past customers. This shows they are used to working this way through this site. Decline bids from providers without many great reviews.
Don't aim for the lowest bid. Use these sites to find someone that seems great and capable, even if they are twice as much as the lowest bid, they might work 10 times faster and better.
Each of these sites has its quirks, so sorry I can't recommend specifics for everyone. But be considerate and nice, once they've mentioned your VERY IMPORTANT phrase to prove they really read your requirements. That's cold enough. Once they've passed that test, be very responsive and friendly.
7. Hire one from each.
Here's the real reason why you're stopping at a simple milestone: you're going to hire at least two different people to do this first step, expecting that one will go bad, one will be so-so, and one will be great.
Yes it means you're paying multiple times for this first milestone, but it's worth it to find a good one.
I've found it easier to choose one provider from each site, so you can “award this project” to just one, and track their work there. They don't need to know there are others.
Some will definitely go bad. Just expect it and don't let it upset you. They'll say something has come up, that they can't start until next month, that it's harder than they thought, or just disappear and never reply. When this happens, just mark that person's project as cancelled or complete, and say goodbye nicely. Then carry on with the rest.
Lastly, ask each one to send you a zip file of the entire source code after each completed milestone. Even if you don't know what to do with it yet, save it. Unzip it and look through it in any text editor. You might actually understand some of it.
8. Continue with the one you like best.
The goal of this project is to find just one programmer (or team) you really like.
If you don't, then just go back to re-post that first milestone again, but changing it based on any feedback you got. Perhaps set a higher price or describe it better.
Once you do, you can let them in on the whole project. Send them your full “Version 1.0” story and walk-through. Get them involved in the whole thing. Hire them to make the next milestone happen, and the next and the next.
They may ask you to continue working and paying through the website, to boost their reputation there, or they may want to just go direct. Either way is fine.
I left out many things, of course, but if you feel something needs to be mentioned, please leave a reply in the comments, below.
Let me know how it goes!

Derek,
Yes,Yes,Yes!
thanks,
PMH
Derek,
Yep - that's a brilliant way to develop a deep field of excellent programmers who can take care of all aspects of your project.
I've fostered relationships (not transactions) with my group of programmers so there is a longer term feel to our collaborations.
And if I need a tweak it's done. Or if they need money faster, it's done.
Hugh
Excellent post, Derek. Very insightful and obviously the voice of experience. Thanks you!
This is also very useful advice if you have both roles: a programmer with an idea. Especially the first section. Scoping the prpject down to something manageable is really hard. I haven't been able to do that on any of my projects yet!
Hiring more than one is a great idea. Keep it small and affordable.
Assume that most freelancers are terrible and you will be much happier and get way more done.
Your working with a whole other idea of professionalism with remote people.
great post Derek!
-- Derek
very insightful tips for outsourcing almost anything.
but I'm a bit confused: aren't you a programmer yourself? when did you find the need to hire a programmer by yourself?
I've done a lot of hiring as described here. Sometimes when it was something I didn't know how to do. Sometimes when it was something I knew how to do myself, but was just trying to work with others. Longer story there, but yeah, this is from experience.
Thank you this is glorious! I've always wondered how to go about outsourcing programming, as whilst I understand and have done programming successfully in the past - I absolutely hate it!
What I do like is the coming up with the idea and mapping out the development part. I love your posts Derek, you really GIVE.
THANK YOU!
What about design mockups using eg. mockingbird? I think that they're good to express what you want.
Is it ok to get feedback on what I think is a Version 1.0 request?
The link to a bold idea - Buycott BP, [the link is my name takes a couple clicks cuz this comment was flagged as spam] - has what I believe are 1.0 requests that would be built upon.
Thanks for any and all feedback. And thank you Derek!
dude, I've been tiptoeing around doing this for years (since reading Ferriss's book) and never jumped in for fear of the unknown process. thank you for elucidation!
j
Incredible post. This really opens up my entrepreneurial mind!!
Derek-
Another brilliant post! Makes me wish I had thought of some of these steps for my own big ideas!
The Version 1.0 concept is great - what a fantastic way to take stress right out of the picture. Besides - no project is ever "finished" - it's always constantly evolving. So just pick a simple starting point and attack!
Plus I love the idea of hiring more than one person - again, the right person will reveal him/her self without you putting all your eggs in one basket!
If anyone's interested, I run Virtual Nathan, my own VA biz, and would love to help others build and realize their dreams!
You can find out more about what I do and read testimonials at: http://www.npagin.com/virtualnathan/ OR email me at VirtualNathan [@] npagin [DOT] com
Every person and project is different, so I'm always open to discussion!
I've hired many programmers in my life. These are excellent recommendations for someone who hasn't done it before.
For #3, I'd add one thing: Create a flow chart of all the site pages and show how they connect (if/then paths), even if it's not perfect, the flow chart really helps programmers understand what you want.
This is GPS for would-be web entrepreneurs lost in a sea of ideas with no sailors to steer their imaginary ship. I wish I had read something like this 5 years ago
Thanks Derek.
Hi Derek,

Great post. I am starting a big web project, and have been thinking about how to break it down into manageable chunks.
Maybe maybe maybe maybe one day I will actually have something to show, and I'd be happy to share with you and the crew that follow your blog.
til then it's top secret
Mono
I agree with all you've said.
I've outsourced a few development projects before, I've found http://www.freelancer.com works well.
As a programmer that has done some freelance work, you sound like the dream client.
However, I think it probably makes sense to overview the entire project after you've accepted someone's bid. Sometimes non-programmers aren't very good at anticipating where there might be problems, so it makes sense to give a very high-level overview of what you expect to happen after the first milestone, and the programmer will know if any follow-up is necessary.
http://www.scriptlance.com/ is another great place to find programmers.
One thing that I found to be helping tremendously is to prototype the idea before handing it off to a programmer. I found prototypes to be more useful in conveying the idea than writing tens of pages of specs. It also helps reduce ambiguity and communication overhead.

A prototype can be a series of hand-drawn sketches or a click-thru presentation using keynote or powerpoint.
Insightful post, as always
Fortuitous that I should read your article now as it's given me some great pointers and refreshers on things I (should) already know. Even as a seasoned freelance programmer, I have learned some useful things here and will be implementing in my upcoming project.
Kudos!
Excellent process. Your v1.0 is what we call the Minimum Viable Product (MVP).
It is important to insist on frequent releases so you are getting new features every couple of days. Don't wait 4 weeks or more while programmers are "building features". If they can't deploy new features into production at least twice a week, don't use them.
We've built Sandcastle specifically for an entrepreneur with an idea, who is not a developer. Sandcastle is a software development service for entrepreneurs.
The blog software thinks I'm spam, so if you want to find us, go to "build a sandcastle dot com".
I need desperate help in revamping my website, self-built many years ago with Dreamweaver. This is really helpful, Derek. You are also timely...just when I need help here you come with the correct suggestions. Bless you, chile! LOL
This is great advice. Another way to do it is to teach yourself programming and build it yourself. That's what I've been doing with an idea I'm working on. It's been a whole lot of fun. A lot better than practicing law (I'm a lawyer). It will take longer, but I'll know the application inside and out. Derek's previous post "After 15 years of practice ..." gave me even more motivation to go this way.
Good article, but if you only say "sell downloadable and streamable video files" some people will assume you are talking about porn, and not everyone will be happy to help with that. So in that specific case you may want to be a bit clearer...
darn it derik, this was going to be my brilliant idea and now everyone knows. No seriously, it's a great idea and bravo for sharing it with others... now just don't share it anymore. jk ;)
ps- totally kidding in my last sentence. you don't have an edit button.
How about someone to review the work of the programmer? I mean, you don't want your site to "just work", right?
), probably your reader needs further references, and some hands-on experiences to appreciate your post.
Speaking from experience: My mate paid someone to build him a database-driven website. I don't know how he chose the person to do it. After he got the source code, he needed to make a few changes. So, he asked me what he needed to do. I had a look at the source code, and it was chock-full of SQL injection vulnerabilities. In addition to showing him what to do, I also pointed out the vulnerabilities and demonstrated how easy it was to login into the admin area of his site without knowing any username or password or database table or column names.
So, in the end, what the hired programmer produces won't be even "Version 1.0", but probably "Version 0.x".
Doing step #2 isn't probably simple for everyone. Writing a set of requirements by itself requires a skill. The programmer will probably not understand your business model, and therefore can't help you point out anything that doesn't make sense in the requirements. I also know someone else who consulted me about his website idea. He knew what he wanted, even he also showed me his ideas about the milestones and "Versions > 1.0". And looking at the requirements, I didn't think it was difficult to find a programmer to develop that. But what I think was hard, and it was something he couldn't consider was that it would be harder to find a *maintaining* programmer, and how much it would cost to run the software, because of technical details he didn't understand.
Nothing essential that I disagree with you in your post, but when read by other people with minimal software engineering experience, they can have too high expectations. So, while your post is a good summary (of things that can't be learned quickly. Perhaps 15 years
These are great suggestions. If you live in an area that has "hacker" or "startup-weekend" type events where idea people are teamed with developers, it can be great way to get some free (or low cost) experience in what it is like to work with a team of developers, narrow the scope of your project, and understand what it takes to get to v1.0 in a short period of time.
Hallo Derek,
Das meiste ist kalter Kaffee finde ich. Warum meinst du Pay by the hour.? Ich arbeite gerne nach Absprache auf Festpreis als Programmierer. Meistens wird allerdings die Stundenbasis bevorzugt. Kannst Du mir erklären aus deiner Sicht erklären warum?
WM_GREETINGS
sebastian
thanks for all of these valuable tips. i'm sure this article will be the catalyst for many successful projects that have been residing in the minds just waiting to be built.
for anyone needing user interface, design and branding for their project visit my portfolio: http://celsius.ws
we love to build bold identities for fresh ideas...
As someone who programs and has worked with another programmer for 11 years . . . THANK YOU for your LOGICAL advice. Most people think it's all a push-button deal and we can make things happen for no money at a push of a button in a day. NOT! It's called work, baby. Any idea worth that's worth $$ is going to take time and money to make it come to fruition. Americans have become impatient andlazy. PLAN, WORK, PLAN SOME MORE, WORK SOME MORE to make it happen!
thank you - this is very helpful and timely!
Interesting post once again, Derek! And strangely timely, as my friend and I (we've both been developing websites and other applications professionally for over a decade) have recently been talking about how often we get poorly constructed invitations to tender for projects.
I think many people have an idea, but don't really know how to develop their idea into a project specification, how much it should cost, or how long it should take. This leaves people open to all kinds of potential problems (kind of like when you take your car to be fixed at a garage you don't know, when you don't know anything about cars except how to drive them).
We are currently thinking about offering a service where we help people to envision their project clearly and then present it in a way that teckies and designers understand.
The idea is that this allows you to get much more clear about what you want to achieve, what's possible with current technology, what other people are doing, how long it might take and how much it is likely to cost. We will even write the invitation to tender for you, based on our discussions.
You can then go into the process with your eyes open and with the best possible chance of getting a great site at a sensible price, in a reasonable timeframe.
If any of you think this kind of support might be beneficial, please send me an email. We are still at the discussion stage with this idea, so it would be great to know if this is something people would find helpful.
Thanks for that....Great tips.
Hi Derek,
That's a great article. You sound like a great client to deal with for a programming company.
I'd like to add one thing: in my experience, some people have problems with creating documents like the version 1.0 specifications, a flow of steps for the website experience, etc.
The common name for that type of work is "requirements gathering" and it's a part of what business analysts do. A good business analyst will help you structure your project and take it from an idea to a detailed plan of action.
Disclaimer: my company creates websites, iPhone/iPad apps and other software, and we provide requirements gathering/business analysis services to all of our clients, for free. Click on my name for the link.
Great post for getting the first step of a new business off the ground. I am a Ruby on Rails programmer and have written the first line of code for a few startups. Two points I'd make pertaining to this post are:
#3: It's not necessary to lay out every click per se. The exercise has value so you completely flesh out what you want your site to do. However, a programmer would read this as a requirements document and produce a cluttered page. Hopefully, your programmer has a very well qualified user experience person on their team who can provide guidance about the experience of the site. Programmers, and certainly not the visionary founders, are the most qualified for that task.
#6 I haven't done a ton of hiring (only a little) and have found the freelancing sites to be a poor source for quality work. Many good freelancers are very busy right now and can be found through networking with friends or linked in. One thing I look for is that if their own portfolio site needs a lot of help then they're probably too busy to update it. Either that or they're really bad. check their references to get them into the right category.
Great post, it will help me direct clients and I hope it will certainly help clients direct their programmers.
Derek!!! You're awesome in your desire to guide people with advice and examples from your personal experience! Please keep going that way, because we are honestly impressed
! THANK YOU!!!
Thanks again Derek. Well as a programmer of many websites I find that it is easier for my clients to consult my ideas first. This gives them ideas to work from as well as giving them an idea as to what they can do. Most people have a basic idea... and that is good. Main pages include, Main Page, Contact Us, About Us, Etc...however, there are many other things that need to be addressed. The main thing when starting a site is to ask yourself, How often is the site going to be updated... and who is going to be updating it. The biggest mistake you can make is hiring someone that creates your site in (let's say) Adobe Fireworks or Flash and then you try to hire someone else to change it (because the original guy is nowhere to be found)and you find that no one but him can make changes because the original file that makes the web page is needed. Yes, the file type of the program that creates your web page is not the actual web page. This file in the web program exports the images into a web based file like HTML. That file can not be changed without recreating the page from scratch. So, besides knowing what you want, you must also know what type of web site you want, as well as knowing what to ask for from the designer so if you decide to fire and hire someone else, you have the needed files to do so. This is one of many examples of things that are way above most peoples knowledge, and has been the reason I have turned down work from new clients asking me to do something they think is simple (like changing a spelling error or price) when for me it would take the same amount of work as creating the page from scratch. Now of course the client only wants to pay for me to change one word, not 20 hours of recreating the wheel. I do consult people, however I am not looking for work right now. I have a full plate and do not like to over commit. I know i may not have explained myself fully, but I am open to explain it in more detail if asked. You can contact me at Michael@HighSpeedSupport.com or Michael@CCwheelers.com or Michael@DaPOW.com.
Love it. Your step by step approach is very helpful.
Thanks Derek!
You would be better served to find a senior level freelancer here http://www.hnhackers.com/ than to try to find a needle in the haystack on many of the freelance sites mentioned in the article, as a senior level freelancer, I tend to shy away from those sites and find most in my peer group do as well. They set unrealistic expectations for professional services.
Another helpful thing to do when it comes time to talk about the rest of the features you want, is to create a VALUE vs EFFORT chart. The Y-axis is value from 1 - 10 and the effort is X-axis from 1 - 10. Then, you take 3x5 index cards and place the features you want wherever they fall in the chart. This will show you that you want to start with the features you think will be of great value to your users, and that the developer has suggested it to be of low effort
As a follow up to the comment above, this is a technique we at http://www.seventhdegree.com followed for the building of the http://www.dafoodie.com app.
Since you asked...
As a programmer on both ends of this stick, my #1 recommendation for anyone's first dip into these water is keep it very, very small.
Very small.
Much smaller than you think you should.
The reason is that there is a vast amount process and vocabulary to learn, and it's best learned when failure is inexpensive.
Derek,
I just discovered your blog and this article from Hacker News. Insightful. Thanks much.
I have a request for a future article for you on your blog. I'm a UX and front end designer bootstrapping my own products with pure sweat equity at night but always looking for someone else to partner with(engineer/programmer)to bring these ideas life. Would love to hear your insights sometime into how to partner with engineers. Thanks again for the good tips.
Harry
I like #1. "A programmer is much more likely to say, “I can do that!” to this simple version."
Here's why I like it. As talented as a programmer/web developer may be, it still takes at least SOME time to grasp the basic concept of what you are wanting to do. That thing you are wanting to do would be called... a foundation.
By keeping it simple, it lets me build a good solid foundation, and that is very important in building a larger system on top.
Starting simple gets me in sync with your idea that much faster, so that when I have to approach more complex aspects, I'm already "seeing" things the way you see them.
Just my two cents...
If you plan to introduce me later to version 2.0,
All I have to say is brilliant article. I will definably refer to it in the future in my own articles.
Wonderful article once again. THANK YOU!! Lately I've been hiring more than one person for the same position thinking I must be crazy. You've confirmed that actually this is merely strategic positioning. Again, THANK YOU!!!
As a programmer, sometimes I get a little frustrated at being given a pinhole view of a larger project. I end up spending time developing for that pinhole, only to find out that what I thought was important was not, and that thing I hacked together is the real focus of the next release.
There is some benefit to having the programmers know where you want to take your minimum viable product in the future. Of course, if you spend money on a programmer and things don't work out from the start, then the time/money spent building that foundation will be wasted.
Now if you don't have enough money to actually pay programmers what they want.
Don't make cheap skate equity offers, with programmer getting equity share of first employee and salary of founder(nothing or next to nothing). Learn programming with python language and do 1.0 yourself, that takes time, but if you have any mathematical skill, like being economist, it shouldn't take too much time. Its just a longer road, so don't give up your day job when doing it.
Don't go C or Java, python is good for prototyping and easier to learn.
And once you have done the prototype, get seed funding. Hire real programmer and tell him to rewrite entire application. And have some extra features to consider at that point.
Or if prototype is good enough to sell, sell it to customers.
Its just a longer road, but now you have trade off some time for some money. And you better keep your day job while doing it your self.
At the moment I'm doing freelance iPhone development. A couple of comments:
* I like your emphasis on pairing down the project to the minimum viable product. This is good advice if you're working with incompetent developers (which is true more often than not). If you're working with somebody competent, however, it helps the developer to know what might be coming in the future. That doesn't mean you give them the whole grand vision. It means that if there's a good chance you might want Y in two weeks, tell me now. I will build differently because of it, and it will work out cheaper for you in the long run. I can't plan for things I don't know about.
* Elancer etc. - it's a race to the bottom. Good devs are never on those sites, because clients find good devs--good devs never have to look for work. They already have great full-time programming jobs or are running booked freelancing gigs. That's the kind of programmer you want to hire: nobody like that is on Elance or similar sites.
* Pay them by the hour and they'll work a lot of hours. Instead, pay them by the project. Only works for developers who can actually estimate (incidentally, they're only the ones you want to hire).
* Regarding the detailed walkthrough and IF-THEN branches: while this is good advice for somebody trained as an engineer or a scientist, most people simply can't be thorough enough with something like that to be of any help. The strength of a great developer is--not only can he program something from a spec, but he understands the reasons behind the spec. No spec is detailed enough to cover all the bases; even people paid to write specs always miss something. Communicate what you want the developer to do and have *him* write up the spec and then look it over. A pro developer has much more hands-on experience with spec reading and spec writing than any client.
* Regarding your overall "numbers game" approach, it will work, in the strict sense that you will get what you asked for, but not in the sense that you will get what you want. Most people, when they try to hire me (although they don't realize it) are looking for technical or domain expert feedback. They may think they need such-and-such coded, but in reality they have a business problem that they need solved. More often than not, I can weasel out of them the business problem, and the technical solution to solve it, and it's often not at all what they originally wanted to have me do. Part of it is that clients vastly overestimate the development time of some types of features, and vastly underestimate the complexity of other types of features, so they cut the wrong stuff from their MVP. In that sense, their project is doomed before they even hire a programmer. Top technical talent can get and keep you on course in a way that will fix problems you don't even know you have.
Thanks for sharing your advice Derek. Here are some thoughts from a developer's perspective.
Many people I've spoken with who have used the freelance sites you mention have had very inconsistent experiences. Having a developer, or company, referred to you by someone you trust/respect carries far more weight. Ask around for recommendations before soliciting bids on a site like that.
In my experience, most added complexity and gold-plating typically happen DURING development, not before. This is usually a key contributing factor to missed deadlines and cost overruns. A decent developer will not only help you scope your project up front, they'll keep you focused along the way. As part of this, I find it helps if requested functionality carries with it a value statement. This not only helps clients remember why it was requested, but it also helps when prioritizing against all other functionality. I typically collect functionality as stories that follow a pattern like:
As a [ROLE IN THE SYSTEM]
I should be able to [PERFORM AN ACTION]
so that [I GET SOME VALUE].
Many developers use something similar to this.
There also might be a slight danger in only presenting a very small portion of your overall functionality. There are many developers that can execute the small, simple functionality to get something started. However, as the complexity grows, the pool of competent developers shrinks. I would say, simply be aware of this. Good developers will let you know they haven't done something before and keep you informed of the possible extra time that it may require to gain the knowledge to complete the task.
Finally, make sure you communicate with your development team and that they're communicating with you. I've seen lack of communication, or miscommunication, kill many projects. Even the best developers and clients can fall prey to this.
Don't forget that the first milestone, no matter how small you think it is, in reality it needs the project's initial foundation: database, framework, some css. This is work that you (the client) don't see, but its costing money too.
Nice post! I liked it through #1-#5. Should be read by any web entrepreneur. Personally I can't imagine myself hiring devs from Odesk, etc. I would rather go for an established development company which can easily scale development team as project grows.
Maybe this is because I run offshore software development company and have seen a LOT of people coming asking for help after dealing with freelancers.
Really useful article, But doesn't it take one's passion and dedication to work into each click (talking from own's perspective) while letting them work.
Suffering from onemanship won't do good in this case, should we form a committee or a group before hiring someone from odesk or what??
As a programmer I wish all my clients followed these steps, It would be heaven - in the very least follow #3
Also a couple of more things for the clients
- ask the programmer to setup the application on a demo server early in the development phase (yours or his does not matter)
- if at any time your programmer asks you test anything please do so - if in doubt ask the programmer what part of functionality you are being asked to test.
- enjoy the process ;-)
The only thing missing I would add is this. When someone approaches me about creating an app for them, I always advise them to take time and break it out using something like Powerpoint or Keynote. Using something like that, or any drawing/diagramming tool really, is a good way to get the idea roughed out.
I recommend they try to break it down by sections first, creating blank pages for each app section. From there just try to put down the basic UI pieces like boxes for text input, buttons, and even a tab bar/nav if they have that worked out.
From there it's a lot easier for a developer to break the idea down further if necessary. Ideally you work with a developer to do this, but you can get the ball rolling by working out a view pages to get the idea across.
That's how I typically recommend some proceed before actually hiring me for the work.
Excellent, Derek. Thanks for your thoughts. I also enjoyed your music!
This is excellent advice, Derek. I've used guru, e-lance and other sites as well as a local freelancer to build Version 1.0 of our site and we're now building the 2.0 app.
Some of the most successful development companies that we are dealing with who are interested in partnering are actually asking for #3, so you are spot on with the need for this when it comes to developing applications.
Learned plenty from this post as well, of course. Thanks for sharing your proven experience!
Thank you! This is great info. It's really nice of you to share this.
Pat
I'm programming in PHP and Java and designing relational and object oriented data bases since 12 years and I do absolutely agree with Drew's comments (#50). - Most of all with the point about Elance etc.
Maybe this advice would be also useful: look for a programmer near you with whom you mix well. That's much more important than to find the super guru of programming, as your needs won't be such a high end task, supposably.
If you can go out and drink a beer together, it's much better than to pay for each minute he/she works for you in an office, distant 10000 miles from you. Everything stands and falls with communication; not with programming.
And don't forget: you're no programmer. And probably you're no marketing expert and salesman, either ... Don't blame the programmer if your internet platform or software's not selling itself. Integrate these two characters in your concept/budget, too.
Best
Patrick
PS: At least for the programmer, an application doesn't start with a description of the application itself, but with the data model and its entity. The first question's not what you want to do, but what you want to store, and what's the central thing (= entity) of it. Then you care about the data structure (= the fields you need to store). And THEN you care about the work flow of the application.
PS II: Dear Derek, not every programmer will give you his/her source code. A serious programmer has built, after some year of experience, his/her own libraries. "Your" application will gain (time and money) by using that code probably, for which's developping you haven't paied. Maybe that code's also protected by an international copy right. In such a case you'll have the right to use it, but not to decompile or distribute it and probably you'll pay a license amount for it. Best regards
This article seems to imply that freelancing marketplaces are the only way to hire software developers and it is not. You should definately consider hiring locally. The easier communication and better quality developers will often outway the added cost.
Also consider hiring by recommendation. The most important thing is to find someone you trust to deliver quality software.
3. Write a detailed walk-through of every click.
It is unrealistic to expect that you can describe an entire application in detail before development has begun. Doing so does not take advantage of a software developer's experience. This may well be the first project you have managed but most programmers have worked on dozens and they have invaluable experience designing features and interfaces. If you design your first application by yourself you will end up with 'the Homer' http://simpsons.wikia.com/wiki/%22The_Homer%22
6. Post it at elance, guru, odesk, vworker.
The reality of these sites is that the average provider is unprofessional and a waste of money. The good developers do not (generally) work through these sites so you are left with the bottom of the barrel. Hence the need for...
7. Hire one from each.
This is great advice if you really want to work with an overseas developer. Remember to terminate projects as soon as they start to go bad. Our natural inclination is to 'give it another week' to see if things pick up; but they never do. It is better to cut your loses and move on.
Be aware that you will waste a lot of time trying to find and manage a quality overseas team. The low rates may, or may not, reduce the overall cost below that of hiring locally.
Great post!
Only thing I'll add: don't ask the programmer to sign a lengthy contract with non disclosure agreements, invention assignment, etc. These won't protect you, and will just make a savvy programmer uneasy at the additional liability.
Also, many good programmers today don't believe in the idea of software patents or "inventions". Software today is often a hodge podge of various works, and there is no original "invention" inherent in it.
I AM REAL
Thanks for an excellent post, Derek.
I totally agree with some of the statements above. And writing a step-by-step walk-through might be important if you outsource your work to India or China where they are used to work by direction and nothing more, or if dealing with a 15 year old kid, programming from his parents basement.
But if you are working with a senior web developer you want to make use of their experience and giving them too strict guidelines can hinder that. I believe that it is better to give a very clear understanding of what the aim/purpose with the function on the homepage is, and what parts are needed, for example it is more important to know what fields need to be there to create a new user, which fields are required and what will happen when a new user is created, instead of a walk though of the sign-up page. Exactly who this is implemented is up to the developer, since they might have better ways then having a normal button, in my experience many customers have a hard time visualizing this and therefore end up with a very strict and old fashion description when modern technology such as ajax could make that extra button unnecessary.
I see the programmers profession just like any other creative profession, you don't go to a painter just to tell them exactly how to paint each stroke, what color to use and what pressure to put. You go to the painter because you like his previous work and I believe the same goes for programmers.
I agree with Drew and Emil above.
A good programmer will build you what you want, not what you asked for.
The real value of a programmer isn't their ability to enter instructions into a computer, though if that is what you want the post is great advice. The value you really want to exploit is the ability to think about your domain in a certain logical way in order to solve your real problem as efficiently as possible.
Hi Derek, I've got 2 programmers, and they're doing what they can in spite of me. I hope to be more helpful in the future. By the way, have you seen the docu called, "David Wants to Fly"? In it there's meeting with a guru in India who defines what a guru really does. Two things are interesting: a guru never keeps his ideas a secret and he takes no money. Dear Derek, you're in the running! Thanks for all your efforts. jpt
I agree with the great tip on how to find a not-too-lousy programmer on outsourcing sites.
Let me try an analogy: if you want to get sex, you can simply pay a prostitute, right now. Done. Or you can date a lovely person for months, get married. It takes longer, but then you are set for life.
Co-founders and outsourcing work the same. The lure of outsourcing is that if you post a job, any job, someone will offer to do it. But you really aren't getting a committed partner. Finding a co-founder will take much longer (3 months is typical). But once you have the right co-founder, the entire project really takes off.
As always a great thought provider and yea lots to take in here but all great stuff thanks Derek
The hard part is really deciding exactly what you want and writing out all the details, but if you're willing to do that it means you don't have to pay the programmer to do it which may be best for a new idea.
A good programmer can always focus on what you need now while keeping the future in mind, and it often helps them do a better job by adding 10% to the work they're doing now to save a lot more time later.
Often it helps to mention what you would like to do next so the programmer can prepare to go in that direction, but make it clear what's an immediate need and what's a future need. Also make sure it's clear that you know it will be a long process to get everything done, and you don't expect a year's work in two weeks
This is also good because it sets the right expectations. A programmer who expects to end up building a large website will hopefully plan for that from the start, while someone who expects to build something small in two weeks may do it in a way that makes the future work more difficult.
In general there are two ways to build a website: one that will work this week and one that will work for years to come. It mostly depends on finding a programmer who has the right skills, who really wants to do it well (hopefully one who is obsessed with giving people the best result possible and not just doing it because they think it pays well), and who usually (but not always) has some experience doing it the right way.
If you don't have much programming experience it's very hard to quickly see if you're getting something that will last, so if at all possible I would recommend starting slowly and seeing if the programmer is really helping you go the way you want. Comparing several programmers will help you see what's just a technical limitation and what's a personal limitation. If you do want to test the programmer, do just that - test their work. See what would happen if a crazy person uses the website and intentionally makes every mistake possible, then does the opposite of what they should (like the website makes them angry and they want to fight back). If the website handles that well there's a good chance that it's built to last.
Oh, and paying by the project is also good. If you set the price too low you'll lose good programmers (or they'll save time by lowering the quality), but as long as it's set well it's just an extra motivation for them not to take the long way.
I hate you Derek, I had the idea to hire "competitive teams for the same task" for years, but I'm too lazy and unknown to actually be able to share this idea with the world. Haters gonna hate...
Great minimalist approach to success!
As someone who has been on all sides (developer, project manager, idea guy, and manager of those three), the only thing I have to add is do #1 repeatedly. Revisit it when things are going well. Do it when you have hit a slowdown.
I use two mental models to motivate myself, team, and developers to do this. One, you are on a raft in a storm. Every requirement, idea, UI widget, is a box. If you don't unload enough boxes you are going to sink. Which boxes must be on the raft at the end of the trip or you should sink instead of deliver? Every last one of the other boxes that are weighing you down, slowing you down, diffusing your focus can be ditched and need to be ditched now! Not later. Not once you do A/B testing. Now!
Put them in the next rev or the someday-maybe pile. Treating it as a now or never question leads to requirements creep. The decision is between 1.0 and later. Carrying them any further runs the risk of project failure as well as squanders time to delivery--the one resource I can not recover.
Second model, your idea is brilliant and each day delayed in release is a day you are depriving the world of that brilliance. What is the core of that brilliance that can be effectively done the quickest? I find this especially effective right after prototype testing, alpha test, or especially when you get a beaming user at beta1. You know that smile when you got it right. Now ditch everything else that is not required to put that smile on the rest of the world. The value difference from none to some is huge. The value difference from useful to insanely great is big and takes significantly more time than getting to some.
Short version for revisiting #1: know what is on your raft and go from none to some as fast as possible.
Derek: Interesting article - I'm not sure if you realize it, but you've basically described what the Agile community calls "User Stories". You may also want to look into tools like Pivotal Tracker for keeping track of stories and prioritizing / scheduling them.
BTW: great keynote at Railsconf!
Thanks D!
As much as I will always value your suggestions on how to live a good life, I believe a comprehensive outline like this from 'the one who knows' could end up being yet another priceless manifesto for those of us still in the DIY trenches.
Thanks for the info in this article. I've worked as a senior business analyst and IT project manager for some time now and I can confirm this is valid advice here.
There are whole areas of expertise and entire careers built around this translation work from "idea to development."
For anyone who is curious, look up the following terms in Wikipedia and you may find further inspiration:
Business analyst
Agile development
Waterfall development
The biggest advice from here is using bite size chunks to get to your goal - or what us IT people call "iterations."
Great ideas here. I am a programmer myself, but have hired other programmers to work on personal projects I have not had time to do myself or to come up to speed with different technologies. Most of the time you can hire a competent developer for a good price and if you find one you actually like, I found that is it worth it pay a little more to establish a working relationship.
This is a rehashing of how development is actually done.
You have written a layman's explanation of submitting a proposal for a project, building what are currently called use cases (20 years ago they were user stories, 40 years ago it was just part of what was called analysis), and the subsequent iterative development (despite what the methodology mavens would have us believe, development has always been iterative, and iterations are just little waterfalls).
None of which is to say this part is bad. I can see where this would be useful to small business owners who have never dealt with having custom automation built for them. It's pretty standard stuff, though.
The competition part, however, is an incredibly bad idea, as the requestor for the project has no way of judging the entrants other than by implementation of bells and whistles. Security is hard to get right. So is database design. Race conditions usually only show up under stress. And so forth.
Footnote: I found this via slashdot at .
Derek,
This is a great article! I agree with your advice, but I have something to add.
As a developer, I've worked in many projects and maintained other developers' code.
Developers can solve your first feature by building beautiful code with testing code that tests it. Or they can solve it with horrible and hard-to-maintain code.
Step #7 1/2
I'd have a third developer review the code of the developer that you picked. Try to get a 1 to 10 score on the code. Is it hard or easy to maintain? Does it have test code & code or just code?
- Ernesto
Lots of good advice there! I especially like the "I AM REAL" idea - just like the rock music urban legend about bands who demand a bowl of M&Ms backstage, and then have an instruction buried deep in the stage construction manual to remove all the yellow ones, to see if the crew is paying attention!
Re: 'Leave off all details that the programmer doesn't need to know… If you want the site to translate ancient Arabic poetry to Spanish to increase global tolerance, just say, “Translate paragraphs from Arabic to Spanish.”'
Not so sure about this. The problem is, it's hard for a non-programmer to know which details they do and don't need to know up-front, and for a programmer there's nothing worse than to be drip-fed requirements after you've started (or completed) your work. "Oh, didn't I mention? It's *ancient* Arabic, not modern Arabic. But you can just change a setting for that, right?"
Great Article...what about trust issues with a programmer...even though you have a patent and you signed a non-disclosure I still think you need someone real trustworthy b/c I have heard some horror stories in relation to having ideas stolen..what's your take on that?
Thanks ..its a kind of book for me...I was perplexed about how to go about it...you have cleared the fog from the glass...
Derek,
Just what I feel I needed. Thanks much.
Ed Taylor
Cool, a lot of this is good advice for *programmers* as well as people who want to hire them. Specifically the stuff about nailing down a minimum first version, etc
Great post Derek... I've had greak luck with the folks at Odesk, both for web development and things like market research.
And I love the "brown M&M" at the end to make sure they read the whole thing.
As part of step 3 (Make a detailed walk through of every click) - I would also suggest making mockups of each major screen. The old aphorism, 'a picture is worth a thousand words' really holds weight, especially if you are working with an overseas development team.
There are lots of products for doing mockups. You can just use a simple graphics program like paint or Photoshop. Word has a drawing tool. I prefer using Balsamiq. It has drag and drop components for most components that are found on websites, which is much easier than drawing your own. I can design a simple page in less than 5 minutes, and a more complicated one might take 30 minutes or so.
Also, there are more options for outsourcing than just the major freelance websites listed above. We run a company in Philippines that helps people hire developers at reasonable prices. Feel free to check us out - Agents of Value
So what you're telling people is that if they want to hire programmers, they should think like programmers. That's not going to work. People who don't think like programmers, don't think like programmers. See how it works?
It's much more useful for an entrepreneur who doesn't think like a programmer to look for someone who can take high level concepts (make a translation engine for ancient Arabic) and break it down into manageable chunks.
So give them the high level concept and see what questions they ask, what tasks they come up with to make it real. I've seen people who can write moderately good code if you tell them what feature to make but can't figure out what features are needed to make up a larger concept. You don't want those people. Avoid them.
Derek this is a fantastic article. We're developing our first web 2.0 SaaS app right now and we wish we'd followed each of these steps in hindsight.
Seriously? Hire two potentially crappy programmers and play the odds? How about going with someone local that you can talk with, interact with? Get Yes, it will be a bit more expensive, but well worth it.
Have you ever dealt with the code thats been outsourced? 99% of the time it's absolutely terrible. No error handling, no unit tests, etc. Not to mention the language barriers and time zone differences.
Get a programmer that's excited about your project. If you do, you'll be able to get a lower hourly rate in exchange for some equity.
Don't look for a programmer through craigslist, but rather ask around your "circle". Don't let your marketing friend tell you that someone is a good programmer. To them everyone is a good programmer. Find a senior engineer, take them out to lunch, pick their brain. Tell them your idea, see what they think of it from an engineering standpoint. Take good notes! They'll be able to help you find someone with the required engineering talents.
Engineering is a delicate practice. Don't leave it to chance.
As a professional programmer of 25+ years experience, and freelance for the past 12+ (and part-time freelancing before that) I think your analysis of how to set out and document the project is first rate - there's little to disagree with.
However, your recommendation to use of one the freelancing sites is fundamentally flawed because your extremely unlikely to find any good programmers on there. I suppose you approach - hire a lot to throw all but the best away - has some merit for handling these circumstances, but your dealing with a pool pool of talent to start with.
Personally in 12+ years of freelancing I have *never* looked for work. People come to me through recommendation. All the good independent developers I know are the same - we never ever go near these sites in the first place. What you will get there is the 12 year-old in the basement types mixed in with the sweatshop programmers of India, Eastern European crackers, and the odd college student making some beer money. None of these guys are going to give you robust, scalable, safe code.
By way of illustration. One of my clients actually hired a guy like this 5 years ago and got him to write the whole of their web-presence. Superficially it sort of worked, but the underlying code is so full of fundamental coding errors ('God' classes, SQL Injection opportunities, massive global dependencies etc.) that it's practically impossible to fix. The trouble is now this, completely crap, codebase is in it's *very* *very* difficult to back out and my client is paying many times the cost of getting it right the first time - at a business-threatening level.
What you suggest is probably reasonably OK for smaller websites - on a sort of prototyping level - but it won't scale. At some point your going to need to get some real professional help in you can talk to face-to-face.
I would say that the "User Story" template format of writing requirements pushed by the Scrum Agile methodology is the way to go, as it chunks functionality in a common, easily overviewable format with a common language. Having a "backlog" also allows you to shuffle things around on a very granular level, re-prioritise things down to what is the essence of your product.
Remember, building something is not about creating lots of documents and tomes of requirements, it's about building a common understanding of what you want built.
Also, make requirements and "conditions of satisfaction" assertable, testable by listing them in the form of scenarios: (http://blog.recursivity.com/post/613811840/bdd-the-holy-grail-of-user-story-testability) - something which can be tested, pass or fail won't be an issue of contention later, whereas long, verbose and wooly descriptions will be.
I'd say when it comes to writing down what you want, less is more: concise is better, testable is perfect.
If you still feel the need to write down long lists of steps, do it in a simple diagram, rather than 5 pages of text.
I'm not sure if this has already been mentioned, but I disagree with the part about only telling the programmer about your stripped down 1.0 feature set. Any good programmer is going to want to hear the grand vision of the project along with the 1.0 feature set. Things that you may want to add later may not be trivial additions that could require complete re-writes to accomplish. Architecture and frameworks can/should be planned up front to at least "leave room" for things that are known to be coming at a later date. Otherwise you will most likely find yourself with a developer who (either because they are lazy or just because they are adhering to the limited scope of the project) do things "good enough" to get by with that release. This type of thing leads to more development cost down the road as features are duct-taped in place and spaghetti code results.
Turns out great minds think alike! I just decided to hire multiple people to complete the first stage of a big project with the same reasoning behind it. I think it's a good thing to do if you can afford it. I wish I'd read this blog post about a year ago lol. I've figured out a lot of this stuff the slow way. Good to know I'm on the right track now though. Love your blog.
I hate to be "that guy", but hiring multiple web designers, each working in different locations, can often prove to be a nightmare. I understand the point here: that by not putting your eggs in one basket you are saving yourself a headache if one of them doesn't work out. But as the coordinator of many projects at IdeasandPixels.com, working off another programmer's code can be a nightmare.
Fact is, most people advertising their services on Elance are not going to comment/markup their code enough to lend any sense of organization to the next developer who gets it. Therefore that developer will either learn the semantics of the last or simply institute her own. Assuming we use three programmers throughout the process, that's going to amount to a lot of unnecessary code that follows no logic or pattern.
Information architecture and non-reiterating code make for a great website, not module-like programming cycles resulting in incoherent, get-what-you-pay-for code.
Just because your idea is going to be deployed on the web doesn't mean you shouldn't treat it like any other storefront or office-based business. To try to cut corners and go cheap is to only make the web a commodity, and will only serve to hurt your business.
Always remember that bid-based development is reciprocated by under-talented developers who can't get an agency job or manage a freelance career. If they could, they surely wouldn't be working for $8-15 an hour with no benefits.
I really appreciate it that you took the time to explain this. Before I read this article, I had a project but no idea how to work with a programmer to make it happen. Now I'm confident I can. Thank you!
Well what you have outlined here is very logical, but the reality of the collaboration between the client and the programmer is in fact more organic and less predictable because both client and designer / developer are human beings and they need to learn to communicate and the process is far more chaotic. If you really believe that you can educate a client to speak in logical, analytical terms like this then you are either lucky to have met clients sent from heaven or are daydreaming.
Why hire more than one contractor to build version 1?
Having redundant contractors is basically an insurance policy against something going wrong and wasting time starting over with someone new.
If you're not in a rush, why pay for the insurance?
Hi Derek,
I think your article is a really great place for people to start, but in my 15 years of developing software professionally, I've typically found that people don't want to go to that level of detail for a project, whether it's a website or a program, and sometimes when they do, it's not a good thing.
As several other programmers have pointed out, a good programmer will want to know what long term plans you have, because some things will be much easier down the road if you have them in mind while you're building that 1.0 version. I always tell people to make two lists -- one being the bare minimum of what they want, and the other being the ultimate wishlist, because while they can't determine the difficulty of adding in "feature x" on the front end, I may be able to. And there are some things that are *much* better accomplished on the front end. An example would be a recent project that I did that was a series of iPhone apps -- 5 apps with completely different content, but they all needed to be run from the same basic program/template. If they'd waited to tell me until I finished the first one that they wanted 4 more just like it but with different content, it would've been much more difficult and time consuming than them telling me that beforehand, because the whole approach is completely different as to whether I'm building a one-off app or whether I'm building a content engine that will eventually be the basis of 5 apps.
Also, I like succinct, but I also like a lot of details. I like to find out what they want and help them determine what they need, rather than them giving me what they believe to be the best solution to problem x, because often there's a much better way to approach the problem than just to provide the answer they're looking for (because they may not be asking the right question).
I also recommend asking around on Facebook and Twitter and getting recommendations rather than just hitting elance/guru/etc -- as several other people have pointed out, it's a race to the bottom and I've only met one professional programmer in the last 10 years who is still actually on those sites. Everybody else isn't.
On a final note, if you want the source code to an application, you need to mention that beforehand, and you should plan on paying extra for it. Even on sites like elance or guru, it should not be taken for granted that the source code is coming along with the project unless specified. You're paying for a specific service, a specific program to fill a specific need, and getting the source to that is not something that's automatically yours because you paid someone -- quite the opposite, actually. Source code is covered under copyright like any work of art (which is what the law considers it) and the person who created it owns the right to it unless they specifically give or sell them away. Even if you do get the source code, don't automatically assume you can do anything you'd like with it (from a legal perspective) because again, just like you can license a photograph to put in your book (for example), it doesn't mean that you own all rights to that photograph and can do anything you'd like with it like putting it on t-shirts and selling them. It's best to agree to everything on the front end, and get it all in writing in a contract.
In any case, you've written a great article that will get people much further along in the process of "I have an idea, how do I make x into a real program/app/website" -- and thanks for doing that.
I liked the idea of hire multiple for that first milestone. Very important!
My advice? If you are planning on offshoring your development, here is a full write up that you must equip yourself with before continuing:
http://www.paradigmpop.com/blog/diwant/2010/06/20/4-very-important-things-note-when-getting-software-programmed-someone-else
It matches up with a lot of what Derek said here, with the angle of pulling off a successful offshore development contract.
Good luck!
I am a dev and have to say, this is all great advice. It's excellent when a client outlines things properly and keeps version 1 down to the basics. I do iPhone development and don't use any of the freelance sites reccomended. I use freelance dot com and I recommend you check it out. Got any iPhone or iPad app ideas? Email me kieran at hotrodsoftware dot com
Here's the problem all the developers here crapping on freelance sites.
They all say it's better to go with a more expensive local you find through referrals because the code will be cleaner, more scalable, etc.
But the reality with most websites "someone gets the idea to create" is that they'll probably fail. There's no sense in spending 5X what you have to when you're really just trying to get a proof of concept.
At this stage, it's perfectly fine, and actually preferable, to use a cheap coder to just get something out the door to test in the market.
If you defy the entrepreneurial odds, and you discover your idea actually has legs, then hire a local expensive program to clean it up and add all the bells and whistles.
I can hear the objections now -- "But it's so inefficient to clean up someone's mess instead of doing it right the first time!"
That sounds plausible, but it's wrong. If you're going to go anywhere "making your web ideas reality," you're going to have to find a cheap way to do it - repeatedly - because many of your ideas will fail. A guarantee of failure is to make startup costs prohibitively high by hiring "bells and whistles" local programmers. You'll be forced into analysis paralysis because you're blowing your whole wad with every bit of work you commission.
That's the ultimate way of putting all your eggs in one basket...by paying so much for "proper" programming that you absolutely must get it right, because you can't afford to do this again with another idea.
Naturally, Americans who make a living programming will never agree with this, as they perceive it as threatening their livelihood. In reality, there is no threat. Contractors should be used when you need cheap proof of concept. Professionals should be used when the bells and whistles matter.
just my .02
- when i start a project i'll work from the what we are trying to achieve to workflow to user interface and then figure out the best way to implement it. I find actually drawing how things will work and look really help.
- I don't think you can effectively project manage without some knowledge yourself and the ability to learn.
- I'd outsource security and performance testing to an external company.
- Sales is more difficult and more important that you think, if you build it they won't just come.
Hi Derek-
A teacher told me a long time ago, "it's hard to argue with success." I think it's more than fair to say that you've been successful! Thanks for the tips...I'll pass the link on to the gentleman who does my web site...
Very Best Regards,
George
Very inspiring post Derek. I plan to follow these guidelines for an I phone app... Thanks very much.
Schmidty
I especially like the idea of setting a version 1.0 expectation. That alone will save tons of development time and sets the right frame of mind for the client/owner of the site. The details in step 3 (detailed walk-through), however, is where client and developer often have different images of the end product. Although prototyping is great for this step, it can lead to problems too. Clients often don't know what they want, until you've squandered some serious time on a prototype. I'd vote for establishing a strong business case and complete definition of “what” the site will do. Then work through the details "how" with a good developer; one that has a range of skills from analysis through UI design. Think functional definition at this stage and iterate, iterate, iterate in development.
You may also need to partner the developed solution with the skills of a graphical/web designer.
This (hiring it done) sounds like an expensive approach. From my experience, outsourced projects have been the most expensive ones, with mixed results on quality.
Julian ((2010-06-20) Post #94) got it right. I don't know too many people that can effectively communicate their ideas for development or know where to draw the line for version 1.0. It's a very rare talent.
As a developer/analyst, being approached by a customer who thinks through every screen and every click is a huge plus. There are many who miss the complexity and/or inconsistency in their ideas because they haven't put the thought in up front. Outsourcing a poorly thought out design to multiple developers will probably increase the pain. e.g. one developer finds issues with the design so you'll have to redress it with all the others.
I also don't think the outsource vs find the local expert is an either/or decision. Hire the local expert as a consultant, pay them to review your design and to help you select the best of your three contractors. If there comes a point where you need to bring the coding back then at least your expert may have been able to steer the ship to some extent.
As always, the code quality requirements are always a subjective call and is proportional to how much money your customer will loose per hour its down or how many people will die if there's a bug. Engineering has always been about building the cheapest bridge the won't fall down. And to do that right you'll need at least one engineer up to the task.
Cheers
Andrew
Moin,
I'm writing with my Secondlife pseudonym, because hiring a Scripter is a typical problem for every SL business.
At first: Hiring more than one is a good idea, if you are able to attract more than none. Don't team them, because an expert programmer alone is more productive than an expert programmer slowed down by a team of average programmers. So the key questions is to make your job offer attractive to expert programmers. The 'How To Ask Questions The Smart Way' is a must read before even thinking about to hire a programmer.
Do NOT "Pay by the hour.", pay by milestones. A cubicle causes a productivity drop by factor 10, compared to best working conditions. Expert programmers are by an other factor 10 more productive than script kiddies. This results in at least a factor hundred of possible productivity.
An expert programmers knows about this difference and prefers fixed prices for impossible looking projects, that he is able to code fast, because the project is within his topic. So an expert programmer wont take a job that is payed by hour, and you only get the third class script kiddies, who want to earn money by lagging.
In real life, every project must reach prototype stage after 3 month, to enter productivity stage within one or two years. The typical prototype to productivity factor is 4 to 9, according to Brooks and others. So every project failed, that did not deliver a working prototype, suited for the pilot installation of your first customer within 3 month! Do NOT continue this project, but restart with a new programmer, or a new team, else it will likely become a tarpit and money sink.
ciao,Kephra
This is a great article. The very first tip is probably some of the best advice I could give to any non-technical person. Success with software is all about defining the unknowns and level setting expectations. I "V1" with the BARE MINIMUM required to make things happen is the way to go. I would always recommend sharing your big vision with your developer so they can understand what the future holds and plan accordingly. However, starting with the absolute basics is the best way to start seeing if your "great idea" really is great or just good or actually bad. Good article and I hope a ton of people read this.
If anybody needs software work done (websites, business automation or guidance in SEO and online marketing) I would be happy to help.
Please contact me at dan@iknowdan.net
Great post! I'm a programmer and I definitely agree with you!
In my opinion, this is really the best way for each.
good tips!
Matteo
Unfortunately, I think the whole premise of this post is fatally flawed. Let me rephrase the first paragraph:
Do you want to build a business but have none of the skills the business actually needs? Here's your key to riches!
The people who you think you are writing this for cannot possibly use your advice. I've seen the sort of overviews, specs, product plans, and even schedules they've written. They're crap because they have no idea what they're doing. I know one group of people that spent a year and a half writing a "spec" that could have been written better in a week by somebody with appropriate expertise. These sorts of people are also generally unable to evaluate developers, manage developers, etc. The idea that they would have any idea what constitutes a "day's work" is just preposterous. And I would bet most of them will be confused by a lot of what you've written, even though you've tried to put it non-technical terms.
I turn away opportunities to work with people like this all the time in my consulting practice -- people who want to start a technology business but they think the actual technology is a detail, that the value in their planned multi-million dollar technology business is in the idea (that lots of other people have also undoubtedly had). They think they'll just hire someone from Elance or outsource to India and get rich.
I'm not saying you have to be a developer. There are plenty of people in the software industry who are not developers. For those people, you have some good ideas (I've used your "I AM REAL" idea myself when soliciting outside input, and I think your start-with-competition idea certainly has merit). But the rest had better be obvious to these people or they're not competent. And your advice doesn't seem aimed at those people.
If you are a non-technical type and you really, really think you have a unique idea and you have some secret sauce -- unique content, a proprietary system, or an exclusive business relationship -- that nobody else can duplicate, first try to find a CTO-type to partner with you. You need someone who can both design and implement your first version, not someone who's just a manager. If you also outsource some work, great, but you can't outsource the core of your business. If you can't find this person, I'll bet you don't actually have as great an idea as you think you do.
For more on this:
http://www.thisdev.com/2009/10/you-cant-outsource-yourself.html
/Roy
Thanks for providing the framework. This is a great starting point.
Great advice. I tried outsourcing a version 1 of a music crowdfunding site.
Super straight forward goal, but it still blew up in my face (one tip of yours I should have followed was the hiring two programmers).
I did not read every comment but wanted to note for any that make it this far - another possibility.
Use the same steps above but direct it at students or recent grads. I ended up getting two friends on board eventually but my next best lead before they signed up came via a CS prof recommending some students.
And per the comment #109, I think folks that lack the knowledge to adequately discuss technology would do much better to find someone they can at least occasionally meet with. The occasional hands on meeting can do wonders.
You're very good at describing Agile Development without all the technical terms (Extreme Programming, Early Prototyping, Story Cards, Test Driven, et. al.).
I think the key to a successful outcome is communication. If someone implements/ develops/ programs your 1st milestone without follow-up questions, then they're doing what they THINK you want and not what they KNOW you want.
@109: You don't have to be a mechanic to drive a car.
Thanks derek. I will answer as a "programmer". Your approach will help you to find a programmer.
I think the approach is so damn hard for the guy with the idea to do it without support from technical people to ask the correct questions.
The most important thing in a software project is to align your idea with your users. And for that you need councelling wich show you your options and implications of provided examples and ideas. To develop better fitting ones.
Especially if you never worked with programmers it is nearly impossible to correctly transport your idea and intentions with just some requirements.
If you can do that like you described it you will find a programmer. But if you cannot it just won't work out and it is really hard to assess if you nailed it or not. Hard to control if you got it right or not.
To everyone who has an idea search your contacts for technical people and spin your ideas and user stories with them.
The execution, the act of programming is not as much important as the first part and that is where you should seek help where ever you get it from people you trust.
This do not have to be specialist programmers but people with the mindset and experience in software development practices.
And if you want go for the agile community and especially the method of "user stories"
@derek thanks for this post
Hi,
I've seen people trouble themselves over things that are relative simply.
Every other industry except IT, for its benefit, has managed to industrialize its procedures so people who can't get their heads organized will have to follow rules and produce a result.
What you are proposing is simple reasoning and I'm 100% with you. I really can't understand how something that simple can get confused.
I have been fighting for the last 3 years to just make understand the business owners of this simple procedure. After all, the first step to create a complicated procedure you must first create a base simplified one to build on.
Last, I would like to thank you for the perspective o hiring two people for the same job!
Thank you for you insight.
Great read! Thanks!
The previous one we had was what qualities to look for
http://www.einsteinseyes.com/blog/did-you-know/10-factors-to-consider-when-selecting-a-web-development-firm/
But yours brings it to another level.
great advice and good instruction for first time. As project analyst at DIMALEX, most important thing - that's to write down what you exactly want. Generally, every project should start with software requirements (version 1.0
) and it's can be done by customer or with some help of software developer. As more and clearly you describe what you want, as easier to analyze and say how much time and money this project gonna take.
"Leave off all details that the programmer doesn't need to know."
As a developer, I can tell you that is very bad advise. Writing software is more about design and business development, than it is a technical skill. If the programmer doesn't know enough about the problem domain, he is bound to make a suboptimal solution.
As a developer, I think you did a good job of describing what "idea" people often do wrong.
Describing wizbang features is not the way to get a good product or a good developer. You must be able to describe user stories, which you detail well in this article.
Another point. You need to either pay full price or give up a large amount of equity. Don't ask developers to work for free or dirt cheap for 2% of your "idea."
And a warning: Have someone technically strong who you trust look at the code from time to time. Code produced by cheap outsources is often complete crap. I speak to people three times a week who are in a predicament because they are 6 months and $50K in, with a buggy product. It's happened to me, even being technical, because I didn't watch closely enough. You might be better off paying a top notch developer full price, maybe $80-100/hr because they will work fast. For $50K a good developer can build just about any site.
This is great advice, but I too agree with the 'nay-sayers' who suggest that outsourcing might not be the best approach. To develop good software is an interactive process which lives or dies on the strength of communication. Outsourcing (especially via sites such as guru.com) is far more likely to build in a 'silo' mentality and any initial cost savings will likely end up coming back to bite you when the 'real' development starts.
I'm a strong advocate of Requirements Prototyping, and in fact run a blog which tries to show people the benefits of such an approach:-
softwareprototyping.net
The one thing I'd urge ANYONE building anything non-trivial is to spend the time creating a prototype - even if that prototype is quite basic - ahead of ANY development. This clarifies the objectives and produces something that can be assessed, tweaked, measured, 'promoted' (to get funding) and so on. All activities that can help prove a concept ahead of involving any developers.
I do believe that more projects fail on the back of inadequate requirements than do from less competent developers. In fact, the better and more complete the requirements, the less you effectively depend upon developers' expertise.
john
Great Article.
I love the reminder to start simple and then improve on it. Too many people over complicate things when first they should just make it work.
Great.
I would suggest putting together a first milestone and stopping your milestone list there.
Let's face it, experienced project managers have a hard time breaking down tasks into realistic milestones. An experienced consultant should be able to break down a project into milestones.
Similarly, UI requirements should remain flexible. Experienced programmers build up a set of tools they like to use and should be able to build something better and more usable than you can imagine.
Think of working with a programmer the same as you would any other professional. When you hire a hire a plumber, do you describe where every length of pipe should be and throw a fit when it's not exactly as you imagined it? Or do you describe the end product ("I want my toilet to flush") and allow the professional to work out the details?
Great points, both in Derek's post as well as the comments.
A couple additional thoughts I have:
1) Consider the capabilities of your target audience...are they all online? do they tend to use MOBILE more than computers? Are they of a demographic that might have specific needs?
2) Do a little research on customer experience... Too often we buld these things from our own viewpoint, assuming way too much... i think it's fair to say that successful businesses know (or at least try to learn as much about) who they're customers are.
3) Have an idea of what success looks like! ...even in stages, as in the milestones Derek mentions. I think it's great to be open and not micro-manage the life out of the project, but if you don't know what your goals are,how will you know what to do next?
5) Go where people already are! If "if you build it they will come" is your main strategy, you may want to think again. Depending upon the business, leverage tools that drive traffic (e.g. amazon etc.)
Just a few thoughts. I'm by no means an expert, but I spend a good deal of my day on this type of stuff. Best of luck to all!!!
Thanks for the opportunity to market Derek!
We have developed a customized data base. Its main purpose is to track assets (not money assets). Assets such as computers and other equipment. It provides maintenance records and history on each piece of equipment tracked as well as numerous reports to provide informational data for decision making.
It is in prominent use now at a school which maintains and repairs over 800 laptop and desktop computers.
Please contact me if you are interested.
I am also a musician and have been working on a data base for song writers. If you think that would be a good tool for songwriters and there would be enough of us to use it, please let me know.
Hmmm...
As a programmer that has developed 20+ web applications and maintained 10+ enterprise software deployments I do not think this advise will work.
I agree with SuperChuck in that you should treat them as any other professional. Would you tell a photographer, "I need 20 to 30 pictures of trees at various stages of there growth", or would you tell them "I am putting together a coffee table book about the life cycle of trees, which I am going to use as a metaphor for the mental states of people with Alzheimer's Disease. So I need shots at different stages, I think the early shots should be hopeful with maybe a small fish in a big pond feel. The middle stages should be very dynamic, and the last will show the decline and loneliness as the tree ages."
What you should do:
1. You should, tell a programmer what you want, be very clear and concise. Don't leave anything to the imagination. An experienced programmer will ask very pointed questions, like "What do you want to happened if they enter in incorrect data, and you should already have those questions answered.
2. Remain clam.
3. Assess the skills that are needed. You should realize that like musicians, programmers are not all the same. They have different skills. You know how County music is completely different than Rap music which is different than Operatic music all while still being music? Programming is like that too. Webpage development is not the same as web application programming, nor is desktop application programming. Security and database programming is a completely different skill level as a program someone made for a collage project. You should ask questions to determine what you really need.
3. Realize that programs are never "one and done" things, and you have to cultivating a relationship with your programmer like you would a freelance artist. When was the last time you ran a professional program that did not need update. The answer should be never. As your program grows and as the technology around it changes, it will need changes and updates to still work. Security vulnerabilities are found daily that could affect your program or the data you have collected. This is usually called maintenance. General rule of thumb, maintenance cost is usually 30% of cost of the original program. With that in mind, it is much more cost effective to go to the same programmer to get the changes. Keep in mind the programmer should still be documenting what they are doing to at least a level that you could hand the program to another programmer and they should be able to understand it.
Hope this helps.
As a web developer, I can say this is a very well thought out post -- and accurate.
Web developers hear from so many people with a "great idea". It's amazing how someone can go from a basic idea, to a project requiring dozens of developers in just a few minutes.
I find every one of these "great ideas" doesn't seem to be well thought out. Everyone can dream, it's the select few who can make a dream happen using realistic goals, and weighing the benefits of decision that actually succeed.
Yes it's great to implement "task A", but will it drive revenue? How much effort will it cost? Is implementing it cost effective? Important questions to ask yourself before dragging that poor young web developer along with you.
Keep it Simple. Complexity often hides a poor business model. Complexity SHOULD be for improving a fundamental business concept (Sell Computers Online, Translate English to Spanish, etc).
Also keep in mind, there are millions of people "thinking" of ideas. Try to think of why someone else thinking of your idea would fail. In truth virtually none of us are "that brilliant" to come up with something no one has thought of before. Why are current offerings inadequate?
Hello Derek:
Your compassion for others is so wonderful. It's good to know there are still people who care about others.
Helping people to bridge the gaps to allow them to succeed is one of the kindest things people can do for others.
Imagine all of the Artists of all sorts and even people seeking professions that may have caused themselves personal harm or frustration just because they didn't know how to get there and no one was showing them.
That's what I get out of your offer of communication. You're making it easier for people to find their way and make their own success. That is amazing. You live in the kingdom of Heaven My friend.
As you know I make music and have really created a great deal of music.
Visual Art has always lead the way for me. Recently I was accepted at The Agora gallery in New York. There are so many things that I have to do right now that relate to the info you offered and more. Your e-mail and communication came at a perfect time. Being accepted in New York is only the beginning. It's like getting a song released to radio. Now I need my patrons to support the work and help me. More than ever I am humbled before my peers and the public. My Art is my inner most feeling and expressions. I feel like I'm standing naked in front of the world. KNowing there are great folks like you to help me along the way with things eases the challenge.
I'll follow your advice once again and once again wonderful things will happen.
Thanks buddy..What a wonderful journey we are on living at the same time in the world. I'm glad I'm alive at the same time as you. You briighten up the world and my life.
All the best always,
John David Hart
Derek, wonderful advise. I especially like the methodical approach.
In my biz, we are hired by other web designer and developers and we also hire freelancers all the time. So, other than amplifying on all the superb content, let me push back only a little.
The push back is that for the great majority of web projects, that I like to call, 'the base of the pyramid,' no programmer is necessary. These types of project can be done by any low level web wonk, or even self built.
Secondly, for these types of projects, build it using WordPress. Period. Don't be distracted or seduced by free or proprietary, or online content management systems. WordPress is the way to go.
Spend the $70/year to register your domain and buy hosting. If they do not offer WordPress in the hosting package, keep looking. (You're off the 'beaten path' anyway!)
Of course, if you need heaving lifting like a robust eComm site or application development, you need a programmer.
I would go with Derek's methodology, but I would also see if I could find someone reliable and local. If the price is not that much more, and they demonstrate they can do the work, you're almost there.
Caveat lector: Derek is totally on the money when he recommends that you run the first step of the project with a couple of vendors in paralell. Sadly, you never really know if you have the 'real deal' unti you work with them. There are ways to filter vendors, but if you're in business, you know how to do that. (Hint: ask for and contact customers.)
All the best,
Al
Really good post. I've made the mistake of trying to go for v3.0 right off the bat. Thanks for breaking this down for everyone.
The article is a perfect springboard for the lively discussion. Well done by all presented viewpoints.
My 2 cents is John Boyd theory of agility. It is not how large and powerful or well planned. It is speed to first impact, to next iteration.
If time and money are no object, expect them both to be wasted.
Local communications, face to face trust relationships, single point of contact is important for speed and continuity, when time matters. At the pace of the Web, time matters.
With todays tools, if somebody can't sit in front of you and deliver prototypes in practically a real time conversational mode, you need to keep looking for Web developers, or go back to step 1.
A great post having tips for entrepreneurs for executing their ideas. I agree with the simple or v1.0 thingie but at times things are not so simpler. You have to give the stuff which shapes your product.Half cooked apps will never be appreciated. On other hand you must have a team to do your work.

"Fortunately",I am a developer cum wannabe entrepreneur.I am often invaded by so many ideas that it often makes thing difficult. I started an app 3 months back which is blend of user demands and social network but yet to finish it. I am dreaming to sell it to someone in few millions
BTW,I am turned on by exotic ideas so if you are looking for a programmer who can also help you to act up like an entrepreneur and could put some spice in your dish then do buzz me. My contact details are given on my personal site.
Thanks
Adnan
My Lab:http://sidlabs.com
it cost a lot to hire a programmer . i need one to start an online tv but dont know how much it taktes .please give me just two names of priogrammers to help me start my online tv .just thier websites or emails /phones .you are now an advisre ,consultants.thanks for hitting it bigest online bussiness first b/4 others knows about it.
god bless you with your new ideas.see you anoon.
This makes a lot of sense actually. When I get to this stage I will definitely come back to this for a little review.
D
Hi,
I work at a successful consulting firm. I'm going to send this article to a few of our newer clients. I have the same conversation with almost every new client working on their first project. And as many times as I stress it, new clients still try to get everything perfect for version 1.0 and it delays the projects by weeks and even months.
Fixed cost contracts (i.e. we'll pay you 10,000 for the work) vs. time and materials (hourly rates) have very different purposes from a consulting viewpoint. A fixed cost contract means that we have to push back when a client changes ideas or wants more. Any deviation from the original contract means more work and in a fixed cost contract, developers will fight against changes. Time and materials will allow you to change your requirements but the cost will be passed on to you.
Thus, the more thought you can put into your project plan and keeping version 1.0 simple, the more money you'll save.
And I won't knock the guys on Odesk or other freelance sites. Many of them are very good. But the more successful firms aren't on Odesk for a reason - they don't need to be. Do a google search for developers in your area or who have done a project in the industry you're looking at. Contact a few.
And two things that need to be highlighted:
1. How well can you communicate with your developer? Have at least a phone conversation and see how well you click. Communication makes or breaks a project. If you can't talk to your developer easily when you go live and something goes wrong, you've got a big problem.
2. Simply, do a gut check. Do you trust this developer? If you don't, find someone else.
Good luck, all.
As always - great ideas. I'd like to add two things:
1) Now that we have wordpress and plugins - most people don't need a full blown programmer for a basic website where you put up an EPK, sign people up to your email list and sell your music. Just find someone who's good with wordpress to get you set up and just about everything else you can do yourself.
2)Derek's advice is suitable for just about every job you'd ever want to hire someone for - including players for your band, engineers and producers, agents/managers, PR folks, yes, even business coaches like me.
I recommend you interview and do a session with several coaches before you hire one.
Great advice, but what about the fact that the developer might not program with a bigger project in mind, since he thinks it's only a small project, because he only saw phase one, especially when it comes to db design?
Derek,
I'd even say your strategy works for hiring freelance workers on non-programming related tasks too.
Thanks
I've heard folks suggest trying a similar strategy of hiring multiple contractors, but instead hiring new ones with few reviews and low balling them on the price. That way you could hire even more than two if needed. I'm not suggesting this, but it's an interesting perspective that I bet can also work.
usually a "brilliant idea" that can be implemented by an average elance programmer is not that brilliant at all
really brilliant ideas are hard to implement, and definitely not for the average programmer
the advice you gave here is perfect for average projects; top (read: brilliant) projects are not created with hired programmers
as Paul Graham wrote it:
"when I think about what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That's actually much harder than it sounds—almost impossibly hard in fact—because business guys can't tell which are the good programmers. They don't even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy"
sorry guys, that's the bare truth
"In practice what happens is that the business guys choose people they think are good programmers (it says here on his resume that he's a Microsoft Certified Developer) but who aren't. Then they're mystified to find that their startup lumbers along like a World War II bomber while their competitors scream past like jet fighters. This kind of startup is in the same position as a big company, but without the advantages.
So how do you pick good programmers if you're not a programmer? I don't think there's an answer. I was about to say you'd have to find a good programmer to help you hire people. But if you can't recognize good programmers, how would you even do that?"
the rest is here: http://www.paulgraham.com/startupmistakes.html
Great post. Great responses.
Great post.
I highly recommend screen mockups. This will help clarify UI and UX. I usually do mockups in Visio or OmniGraffle and then a list of functions.
I've been through some horrendous experiences, so speak from experience.
Am going through a long process for my first iPhone app right now.
More here: http://projectheresy.com/featured/getting-it-shipped-a-lesson-from-my-wherespresso-com-makeover/
Tim
Hello Derek,
Wise advice! I'm a programmer in writing, audio, video, PowerPoint, Camtasia, and podcasting.
http://videocdradio.podbean.com
If you have an urgent project, and you honestly cannot afford my services, then, chances are I'll help you for free.
Sincerely,
David A. Boyington
Radio Producer
VideoCDRadio
One of the most valuable lessons I've learned as a project manager in this line of work is thinking through the business requirements, and your objectives BEFORE even getting into design elements.
Even in enterprise situations, brands want (iPhone Apps, facebook pages, flash, etc) because it's what 'everyone' is always talking about, but ask them what they are hoping to accomplish with these tools and you find that they haven't thought through the basics...
who are the customers?
what do they need?
what's the best way to accommodate?
Assuming one is trying to launch a business (and not just a hobby) I think the business model and planning is, by far, more important than pretty much anything else.
thanks.... you left me no more excuses. :D
Derek,
One thing I'd suggest adding - clearly communicate to the round 1 programmers that what they're building is only the start of the project (which you mentioned), and that it should be built in a way that will make future extension easy and logical.
I really, really like the suggestion to hire multiple programmers for the first small step. Awesome way to get real, relevant work samples.
If it's a website project that is going to be monetizing directly from that site, you will be well served to hire out your information architecture stage.
Derek pointed out a few bits and pieces of what that includes, but this is the roadmap for your entire site and this is the point where all your business decisions are made. Too many people leave their business decisions to coders and designers.
I have a couple of thoughts on this...
1. Elance is a rip-off (as are many similar sites), and it is extremely difficult to make a reasonable living freelancing there. This results in low quality of work much of the time. I've had much better luck posting "computer gigs" on Craigslist with very specific descriptions of what I need - that also lets you meet people assuming you are in an area that has a reasonably sized local talent pool.
2. I would be concerned about hiring a developer for phase 1 without presenting all planned phases. What if the developer can handle phase one, but not where you want to take it. Switching developers mid stream can be a real nightmare, as most people who write code disagree on small fundamentals no matter how standards oriented they are. I've seen several projects cost three times what they should because the programmer who started couldn't finish.
3. Making a clear technology plan before consulting a programmer can be costly as well - you might have features you want that in the end cost more than they are worth, and only a programmer can really give you a clear idea. For example, if you want a freelance site like elance.com, there are open source projects that mimic 99% of the functionality of that site. If you have a programmer who is familiar with the open source world, can quickly assess available code bases and can pass on what can be done at minimal time and cost, you might find that you can achieve your objectives in slightly different ways than you might originally envision, but at much lower cost and in less time.
Just my thoughts - I've been programming and setting up teams for the last 10 years - if anyone here needs help getting a handle on a project feel free to get in touch at http://narasopa.com.
A solid list, overall. I'd add:
1. Don't put too much emphasis on reviews without context. On a lot of these job sites, the providers with the most reviews are the large Indian outsourcing firms. They work on lots and lots of very small jobs ($100-500), and accumulate many positive reviews. This does not indicate skill; it indicates that they can do many simple jobs successfully. If you have a serious project, all these reviews are meaningless. The people with zero reviews are often unwilling to take small, unchallenging projects. Pay more attention to actual websites, blogs, and portfolios.
2. Be open to changes and suggestions from your designer or developer. Many people get so hung up on their initial document or outline that they panic at any departure from it -- even if the departure is a movement in the right direction. Many clients like to feel involved as much as possible, even if their involvement is ultimately detrimental to the end product. Try to avoid these self-destructive habits.
excellent advice
ive been doing this a long time
even so - derek's advice is right on target and i am going to take it for my next megaproject.
small initial steps! what a concept!
g
I think this is fantastic advice. As someone who runs a programming firm I see many clients who come in who don't know how development works and want to try to put everything in the 1.0 version. Its the sure death of a project.
We try to advise them to narrow the scope. Then narrow it again. Then determine the most important features. That's what we start on.
The only thing I will say about developing like this is make sure that you have REVISION CONTROL that you own that they use.
An article on Revision Control:
http://en.wikipedia.org/wiki/Revision_control
This way, if you higher a single programmer, they finish the first two milestones and then move to a south american country, you have everything they've done, and how they did it stored. In general I find a programmer that works alongside other programmers are far more efficient. They have someone to ask when they get stuck. Being stuck is expensive. It kills developers and projects.
Todd Edman
great advice
h
Hi Derek!
Thank you for sharing wonderful idea.
I have read this article and thought for 2 weeks.
I wonder how can I apply it.
Would you give me any other example in order to understand and apply it to other fields.
Yoshio
Hi Yoshio. You can see my own examples at thoughts.pro. Hope that helps! -- Derek
It's all about feedback! For a developer the client's feedback is very important in order to get the project going on the right track. Some times bad communication can affect the final outcome.
Recently, I was asked to write a blog article about remote management - "Remote management and working from the road – is it for you?". Toward the end of that article, it describes how to locate developers and programmers. Perhaps this is helpful information to others as well. http://blog.ebookpie.com/
Very timely advice. Thanks Derek.
The tricky part in my own case is getting the first step of the project down to a small enough size so that the initial investment of paying several programmers isn't more than the cost of the whole project.
I just realised I'll need to reduce my big idea to “Version 1.0”. Cheers
Hi Derek!
This is very useful post. And I have a question: how should I choose programming language for my project?
Let the programmer use whatever language they want. -- Derek
Dear Derek:
You left out the most important last step. Hire the very best SEO
(Search Engine Optimizer)and your sight will be at the top of any search. I looked all over America, and got quotes from $1,500 to $2,300 and with monthly upkeep fees. I ended up hiring these guys out of New York:They cost $400.00 and I only used them once about three years ago, and never went back for a tune-up. They kept me at #1 until just recently, I've slipped to #3. Yep, you bet I will get back to them for an SEO tune up.
WebCanDo.com
e-mail infor@webcando.com
I am so sorry but I cannot find the name of the three guys that helped me three years ago ($400 bucks for 3 guys? Wow!!!
Their names are around but I would have to raid the garage archives. Just contact them--they are the best in the business and most amazing grace--the cheapest.
Hi Derek, Great article, I wish I had read it before I spent &k+ on a website that wont do what I want.
One concern though. If you just put out for a 1.0 version you might risk what happenned to me. That is after spending thousands you find that the platform used (In my case Joomla)won't do what you want and you have to go back to the drawing board and start all over again.
I AM REAL
Derek, Great process. As a programmer working on some of those sites, I totally agree with this process, except for 1 thing. If the programmer doesn't have a lot of history on the site, thats not the same as hundreds of bad reviews. Just ask to see their portfolio, everyone hears about working this way in their own time and may have just started working on elance, even though they've freelanced locally for years. Personally I stayed out of elance for a long time because I thought it was all spammers and I couldn't get taken seriously on it. I was wrong, and its awesome, but I just don't have that much backlog on elance even though there are many sites that I've done still in production, with minimal changes, after years of doing business.
Thank you Derek, that was a very informative look at something many people need these days. I found it very useful and helpful.
The one thing I thought I might point out, only because of my own personal experiences, from using some of the freelancer websites.
Occasionally, I look for work, or small projects to do using some of the named freelancer websites. One problem I have run into a couple times, is a provider that has agreed to use my work, only to come back at the time of payment to tell me that it is not authentic and refuse to pay me.
I don't know how authentication programs work, but it can be frustrating when you know it is.
Just a warning, that there are those people that will try to get out of paying for your works appropriately.... Not that many of you didn't know this.
Great post. It's nice to have a step-by-step guide for people to follow that may not know where to start.
Can't suggest enough the early book by the 37signals folks. Getting Real.
http://gettingreal.37signals.com/
The goal here is to get 1.0 out the door!
Kindly,
Noah
Tell him/her about your big plan from day one. So he/she knows what to think about when developing the domain model. And then tell him/here what you had in mind for version 1. If the database and domain model are not built to meet your big plan, you will run into trouble later on.
Thanks for the links to those project bid sites and how to navigate through the responders...Many Thanks, D!
I wrote a similar post at http://www.deserettechnology.com/journal/writing-a-good-job-ad-for-a-programmer not too long ago, though it targets more of a traditional classified placement than Elance et al.
Also, today on Elance I saw a job that follows this article exactly.
Can you cite any example of a web site that was built using this philosophy and is successful?
Thx
One thing I've noticed, as a sometime contract programmer:
The programmer does not care about your company's position in the industry. Ads that start "Fortune 500 widget manufacturing company seeks..." might as well say "Blah blah blah blah blah, seeking..." As a programmer, I care about what the job is and whether I'll get paid.
I also recently worked with a recruiter who wanted to hire me full-time for a startup. He could talk extensively about what the core idea was and how to monetize it, but when I said, "What kind of a software stack are you building this on?" -- because I probably have all of about 20 minutes' experience on .NET and ASP. He couldn't tell me, which made me wonder just how much research he had done before deciding I was perfect for the position.
Summary: If you want to hire programmers, think about things that matter to programmers. If you write your ad in a way that will attract a salesperson, mentioning the company size and status, the message you send programmers is that you don't speak their language and don't understand their concerns, and that's not what you want to impress upon a potential hire.
like the post .. thanks for sharing!
I think something important to add is the share the ideas with the programmer and be flexible about what the programmer may bring in.
Most programmers are not graphic designers, keep this in mind.
Also, once you decide for one of them, keep in mind that developing software is an somehow an art, therefore it may take a bit longer that you are waiting for and also the cost may not peanuts as most people think.
If people need to talk to a programmer please visit us http://www.phidevinc.com we always give free estimates and may throw a few ideas for your project.
Great post Derek. Some suggestions from me:
Set up a source code control repository for the project, either on your own server, or at github.com (if you use git for source code control), or other
places if you use SVN or CVS (for example repositoryhosting.com). You can do it, or the programmer can do it, but you must have complete access.
Recently saw a programmer job that was schitzophrenic to the extreme-
They said. "We've got a totally laid back work environment. You WILL be in the office 7:30am to 6pm Monday through Friday." "We respect your creativity! And you might clean out the toilets, so hope you like eating urinal cakes."
Craigslist, how you make finding the wrong job so funny!
If you do want to tell the programmer exactly what you want when it comes to UI, that will be helpful. And read "Don't Make me Think" by Krug, before hiring them as well. That way you'll not try to make the site too complicated. Your programmer is usually not a designer, and you need to know what will get you the most sales at a design level.
This site shows a good example of UI design. Simple, clear, effective. And of course, the programmer is top notch too. http://stevehavelka.com.
Mazarine
Good article Derek! I've just added it to my delicious
One addition (quite obvious but necessary imho): ask the programmer to update you periodically regardless of the news.
Great post, just a comment about this part:
"Be succinct. Programmers love that."
Plz, DO NOT confound 'succint' with 'incomplete'.
Incomplete descriptions of what to do in a project is a huger problem!
Many people wish to hire at the lowest cost. Mistake no. 1.
Also it's very important how you deal with the person whom you hire. It's not just being friendly but being fair and reasonable with respect to 'performance'. Don't kill the guy with your demands. Here you apply the rule ' Do unto others...'. Most hirers forget this basic courtesy. I'm talking from work experience at Elance.
Also you can hire a 'newbie' if he can show you some of his work otherwise new people wouldn't get a chance and often they are hungry to perform!
Mostly you'll get excellent work done just by being FAIR and assuming nothing!
Derek - I have an idea and I am using this guide to a tee - it is wonderful. But what do you suggest in terms of legally protecting my idea before I explain it to a programmer/developer who can then just do it themselves and take ownership?
No need to “protect” the idea. (I'll write more about this some day.) -- Derek
I've heard a lot of people swear by VWorker (it used to be RentACoder). They seem to have more diversity to offer than any other website. What I mean by that is that you get more diversity in terms of the freelancer's skill levels, professional niche, and salaries.
This might be a touch off topic, but as a developer one of my pet peeves is an entrepreneur coming to me with an idea and offering 20% equity (instead of cash) if I'll build it for them. If the developer is going to take 80% of the initial risk, don't offer them 20% of the equity. That's just not nice ;)
Nice article. Very useful. Now I see that is a whole community that is developing their big ideas such as me.
I have only one question. How do you avoid the freelancer developers to stole your idea? Is there any way to protect the idea?
Hope you can answer me. Thanks
I have done a little programming and am starting my degree in a few weeks, and quite frankly, your advice is to treat a 'programmer' like some unknown being. THEY ARE A PERSON JUST LIKE YOU AND ME. With the programming I have done so far, if you told me things like this does, I would ask questions to fill in everything this says not to tell. I would ask why you want this translated from english to arabic, I would ask why you want the user to have to click 'done.' A programmer will know tricks and things that you may want, but dont want them simple cause you dont know of them. Pros: following these instructions will give you exactly what you want, but you wont be given anything that you didnt know you wanted! The key is to make cutting edge software, and there is no way a non-programmer will know all the cutting edge capabilities. Basically, put the programmer in the cockpit, not the other way around. Look at Bill Gates, look at Mark Zuckerberg. If you know these two gentlemen's stories, you should now realize that if you get your programmer exited about your idea like you are, they will work for free or much less than they otherwise would. This is all coming from a genuine geek and a real-world entrepreneur.
I agree. To be clear: the process described above is only for the initial hire - how to get started - taking into consideration that many people you try to hire will disappear. But once you've turned nothing into something, you can get good people involved more deeply. -- Derek
@Derek: Congratulations! Your advice reached the masses so now there are quite a lot of job postings on these freelance sites copying your words *verbatim*. Not that there's anything wrong per se, but it seems immature to me. You also said that "people you try to hire will disappear" but unfortunately that's exactly true for the clients as well. A lot of the job ads will expire, clients will fail to communicate in a timely manner, etc.
@developers-crapping-on-freelance sites:
1. You *can indeed* find smart developers there (disclaimer: I worked through oDesk before). There are guys I know of doing some impressive open source work and they are certainly able to provide high quality service to the clients.
2. You *can indeed* build products with distributed teams. That approach is advocated by 37signals and they talk about it in their recently released book http://37signals.com/rework/
Also check the new blog on the subject from Avdi Grimm http://wideteams.com/ (of course distributed != offshore exactly here)
I want to reinforce the idea that what Derek has outlined (quite succinctly) is Information Architecture. I would only suggest that instead of going directly to coders/programmers, who in my experience are notoriously poor designers, you first take your idea to an information architect. You wouldn't take your idea for your dream house to a carpenter first, would you? You'd want the expertise of an architect -- someone who knows not only about the nuts and bolts of information systems (be they websites, programs, whatever) but also has a firm grasp on user interface issues, information organization, and the other pieces that go into a well designed system. In other words, someone who has training and experience executing the steps that Derek has outlined. Check out a book on IA, there are several that are very approachable such as "Information Architecture: Blueprints for the Web" (ISBN 0-7357-1250-6) by Christina Wodtke. I use her book in my Intro to Information Architecture course in the School of Library and Information Studies at FSU (from which, by the way, you can earn an ALA accredited MS completely online.)
Please add one important point, that I wish all people seeking architects/developers would employ. PLEASE learn just a tiny bit about computers and development. I've been asked to make WOWC clones in three weeks, make ridiculous functionality changes that "should only take a couple of minutes to change right?", etc.
I'm not saying go and become an expert, just to try and understand what it is developers actually do. To the average non IT person, software development is still the work of magic (thanks hollywood).
Other than that, great information.
excellent post. have followed it (almost) to the letter and waiting for results
Derek,
How would you plan for the budget for a milestone project like this? Do you have an estimated amount of time that you would expect them to complete it in? What would you expect to pay in terms of hourly?
Just curious,
Jeremy
About time: see Step #4. About budget: see Step #6. (They will bid.) -- Derek