I'm a founder of GroupTalent, so we've seen a lot on this specific topic...

I'd say the two biggest challenges for hackers who want to take projects is lead-generation and sales. They sound simple, but they aren't and you'll waste a lot of time talking to a lot of tire-kickers.

For lead-gen, that just means finding work. Where do you start? There's a few ways to go, you can network with friends, college alumni, startup circles. You could contact incubator companies and ask if they need any extra help, etc. I have to mention GroupTalent too because this is one of the biggest problems we solve.

When it comes to sales, you don't land projects just because you've got "software developer" in your job title. It still comes down to convincing them that you're not going to botch the project, and that's based on what you've done before. They want to see examples of your work, including anything at hackathons (those are good examples of how quickly you can crank out prototypes). The closer it is to what they've done the better because buyers don't buy you, they buy the thing you'd be building them. It's easier to visualize success with you if they see something close.

On the question of whether to work by yourself or as a team, I'd say go as a team. I've seen first hand that not only will you be happier working with a friend, but the idea of getting a package is a big perk for clients. Speed is often a big deal for them, and 2 is faster than one.

Also, clients gravitate towards hackers who can build web apps, not as much static sites. Anybody can code up css/html, but can you build functioning prototypes? Push that as your core skill-set and you'll have a better chance at finding gigs.

Most developers and designers hate spending half their time shmoozing, networking, meeting and dealing with people who just want to meet for the free advice. It just sort of comes with the territory. In the end, success will come from getting access to the right clients, and traditionally that has meant knowing the right people. This is one of the reasons we're building what we are.

Lastly, don't take projects you aren't interested in. When you're building your own product, and working on the side, it needs to be interesting enough that you can power through the finish and earn the paycheck regardless of what's happening with your company.

Oh – and one more thing, payment can be a huge hassle. Make sure to establish payment terms before starting or you might get burned. I know folks who just don't get paid. We make project owners pay up front for teams, we hold it in escrow, and pay out on a per sprint basis. If you want to do something similar on your own without an escrow-like service, you might do half up front before a sprint starts, and then half after each sprint. But seriously, break it down into sprints that deliver functionality costing no more than $5k. More sprints at lower cost is better, it's easier to get them to pay for $3k + $4k +$5k know what I mean? It's progressive cost increase for progressive emotional commitment. Otherwise things have a tendency to go unchecked, and then people change their minds, and it's wasted work, and oh should we pay for that or not, etc etc.

If you have any questions, tweet me @superkinz