Although I’ve been developing web apps for years, I’ve been pure freelance/consultant(still deciding what I want to call myself) for about 6 months now. We had a good discussion on some of these things at the last Orlando Ruby User’s Group meetup, where we talked shop and traded war stories, and it inspired me to take a little time to reflect on what I’ve learned over the last 6 months. It’s also a goal of mine to write a little bit more this year, and I think a lot of freelancers could benefit from what I’m about to share, so here are some things I’ve learned over this time period.

1. Never do fixed bid projects, NEVER! Always go hourly.

Software projects are notorious for change. Not only that, sometimes things that you think are simple end up being way more complicated than you think. Predicting exactly what you have to build, and how long it’s going to take is probably the hardest part of software development. There’s simply too much that goes into it to accurately come up with a figure.



Whip a few wire-frames together, start the design, and start implementing the development and all of a sudden projects take on a life of their own. Clients will start thinking of new ideas, possibly better ideas, and having a fixed-bid structure in places makes it extremely hard to adapt. A seasoned developer knows how much things change, and will adapt their estimate to account for this, or get really good at saying “Sorry, this is out of scope”, making it really hard to work on that cool idea.



For these reasons, NEVER do fixed bid projects. Yes, I understand that the client always wants to know how much something is going to cost, but there are ways to keep that under control that I’ll get to later on in this post.

Also, you might think the path to profitability on a project is to bid high and hope you come in under what you predict hour-wise. Unfortunately, this almost never happens, and you’ll end up eating the costs and driving down your hourly rate as a result.

2. Divide your work into weekly chunks

For each project I’m currently working on, at the start of the week I like to come up with a “weekly sprint”, in which I’ll plan out what I want to accomplish on each project for that week. I generally like to lock this down as much as possible. This keeps the guessing game to a minimum.



At the end of the week, the client and myself can assess what we were able to accomplish, and start planning out what we want to tackle the following week. I also like to send out invoices weekly whenever possible. This also minimizes risk of non-payment from shady clients.



I also like using weeks as my chunks because as humans we already naturally divide our work into this format anyways. Work M-F, relax on the weekends and start planning the following week.

3. Avoid red flag clients

After a while you’ll begin to learn and pick up on typical warning signs from potential clients that should scare you off. Trust your gut feeling. Here are a few things I’ve encountered that will generally lead to me passing up a lead:

A) Pre-existing code bases.



MOST(not all) of the time, pre-existing code bases are just more trouble than they’re worth. I hold myself to a high standard, and have been lucky to work with some awesome developers in the past, so when I have to work with code that isn’t up to par, it just leads to bad times, and a loss of motivation. Loss of motivation = not getting things done on time = unhappy client = bad times for everybody.



Pre-existing code also makes coming up with accurate estimates WAY harder than normal.

B) Clients that bad mouth their previous development company.

Have you ever been on a first-date where the person just can’t stop talking bad-mouthing their ex? How much of a turn-off is that right? It should throw up some pretty serious warning signs. Same thing in the web development world. Perhaps it wasn’t the previous development company that was at fault, and maybe it was the client.

C) The non-developer or wanna-be developer client that wants to tell you how to write your code

We get hired for our expertise, and when a non-developer client tells you how to write your code, it’s pretty insulting, and shows a lack of trust. Trust is EVERYTHING in the consulting business. Also, it sort of makes me want to say “Well ok then if development is so easy then, feel free to do it yourself since you’re such an expert." You know it’s bad when they start telling you what to name your variables(Haven’t experienced this myself, but have had friends that have)



This is different from non-developer/beginning eveloper clients that reach out and want you to teach and mentor them. It’s pretty exciting when somebody comes to me and says they want to learn Ruby, so do your best to try to ignite the same passion for web development that you have into them.

D) The client that can’t pay you a whole lot now but PROMISES that VC funding is on the way, and if you just stick with them long enough they’ll make it worth your while

I’ve really never heard of this situation ending well for either party, ever.

E) The client that tries to low-ball you at every step

There’s nothing wrong with a client telling you that they can’t afford your rates, but it’s best to walk away from clients that don’t grasp the value that you are delivering. Oh you can get your website done for $10/hour from a team over in India? Let me know how that works out for you. Ultimately a client that doesn’t understand the value probably doesn’t trust you, and like I said above, trust is everything.



F) The NDA + Non Compete

So you want to build the next app that lets users rate things(not that unique, it’s the execution that matters), and restrict me from building an app that lets users rate things. You shouldn’t necessarily walk away right off the bat because of these things, but should be wary of other warning flags that might present themselves.

That said, a contract that dictates things like terms of payment, and that protects both you AND the client is important.

I’m sure there are more, and I’m interested in hearing some others. What are some other warning signs you’ve encountered?

4. Estimate out as little as possible.

Like I said above, estimating is the hardest part of development, and for this reason, I try to estimate out as little as possible. 1 week out a time max. Give ranges when estimating, and always estimate on the high side. I generally come in on the low side of estimates for each item, but there are other things that end up taking 10x longer than what you thought it would, and by estimating high and in 1 week chunks I can usually stay pretty accurate with this.



I, like every other developer, HATE estimates. For me, it’s the hardest part of the job, and you almost never get it right. Not delivering on an estimate is essentially breaking a promise, which will break the client’s trust.



5. No "one-itis”.

I feel like one of those douche-bag “PUA Artists” for using this term, but you should never just have one project that you’re working on at a time. Diversify, and mitigate your risk. Projects end, sometimes funding gets cut. It’s part of life. Also, it typically takes a week or two(potentially longer) to get a new project up and rolling.



I like to work on 2-3 projects at a time, that way when one ends I always have others that I’m still working on.so that I don’t lose any momentum.



Side note: A developer friend of mine had a client that wanted him to sign something in the contract that prevented him from working on other projects while he was consulting for him. Red flag right there if you ask me.



6. Be extremely transparent, and keep your client in the loop.

Communication and transparency make or break the consultant/client relationship. The worst thing for a client is for them to go multiple days or weeks without any contact from you. Keep them in the loop! Let them see what you’re working on. Keep them excited, and show them your progress.

Quickcast is great! I like to take a short screencast at the end of the day, or week, and send it over to the client so they can see what I’ve worked on.



If you run into any roadblocks, or any issues, things taking longer than expected, let them know!

So, wrapping up, these are just some of the things I’ve learned about minimizing risk over the last 6 months. I’d be curious to hear what others do as well. I’m just a one-man freelancing operation right now, so I’m sure some things that may work for me, might not be applicable to consultancies.



What are some things that help you minimize risk in your development projects?





If you need help on any Ruby related web projects, feel free to reach out to me at casey@caseyjenks.com