Sterling Rose Design Blog

I get asked this question a lot: How do you write a proposal for a freelance contract development job?

First, it’s important to understand that freelancing is a different animal from working for a larger development firm (or, as I lovingly think of them, a Dev-in-a-Box). We have some considerations as independents that they don’t, and vice versa, so I don’t presume to know how best to bid jobs if you’re the Thoughtbots or Hashrockets of the world.

But if you’re an independent developer, then these tips may be useful for you.

1) Never, ever, ever bid flat-rate. Nobody is that good at estimating the time it takes to develop an application, and you will almost surely be wildly over or wildly under the amount of hours it takes you. Also, the client who knows you aren’t going over $X will tack on as many new features to the spec as you will allow them to, since they know it can’t cost them any more. Someone always gets screwed in fixed-bid development, and it’s usually the developer.

2) Make it clear to your client that your estimate is just that – you may be under or over your amount. The client should be able to have a number in their head, but also they need to understand that it might not be the number. Mine say, “I have given what I believe to be worst-case scenarios at each stage, though it should be understood that these are only estimates – actual completion times could be less or more than what is shown for any phase, as we understand the requirements in more detail.” Which leads us into…

3) Phases. I like to break a job out into phases, with upper and lower time estimates for each phase. Not only does this help you think more meaningfully about what a project entails, it lets the client know where all that money is going. If they are keeping their overall budget close to the vest, then they can look at the phases and get a guesstimate of how far down the phase list their budget will stretch, and whether that’s a reasonable investment for them.

4) Don’t undercut your rate. Almost every developer I have talked to about this has a rate range, rather than an absolute rate. The hourly figure you quote for any particular job depends on the complexity of the work, the amount of code you will be able to reuse from other projects vs. the amount you will have to write from scratch, the amount of new tools/skills you will have to learn to deliver the project, the number of referrals you think you might get from the client, how difficult the client is to work with, what the market is like at the time, and how badly you need the work. In the last two months, I have bid projects at the absolute low end of my rate, and at the (current) absolute high end of my rate. Some I’ve landed, and some I haven’t, but I feel good about the rates I’ve given out in every case.

5) Be sure the client understands that any training (them of you or you of them), client phone calls, and the like are billable hours. Add it into the estimate (the amount depends on how long the project will take overall, but usually at least an hour a week).

6) This is one area in which I know some developers will disagree with me, as we’ve had discussions of it on IRC. I do not bill the client for the time it takes me to learn new technologies or techniques. I recently needed to learn a little Prototype to deliver some nifty interactive goodness on a project. I had to read some of the Prototype API, watch a couple of Railscasts, and read several blog entries. None of that time is billable. I’m perfectly willing to bill a client for the time it takes to figure out how to apply something to their particular needs, but billing them for me learning something that is reusable feels like robbery.

7) Put an “expires by” date on your proposal. Your rates should naturally increase over time as your reputation grows and your skillset improves. You don’t want to have to explain to a client a year or two after you submit an estimate to them why you can no longer honor the rate you quoted. I usually give the estimate a lifespan of anything from one to three months.

8) Spell out whether hosting is included or not. If you anticipate any other, outside costs (logo design, image manipulation, whatever) be sure to explain that in your estimate.

9) Submit estimates promptly after meeting with (virtually or in person) the client. You want the information fresh in your mind, and you want the client to know that you deliver promptly. I usually have a written estimate in the customer’s hand within 24 hours.

10) And now, the hardest part – how much time to attach to each phase? I do not have any magic answers to this. To be honest, I’m not that great at estimating time. I wrote a proposal once that a particular phase would take me 2 hours. It took 15 minutes. In that same proposal, I estimated something would take 30 hours. I’m at hour 42 as I write this, and it’s still not done. The general rule of thumb is to take the most you think it could take, and multiply it by 2.5. Even then, the sad truth is that it’s something of a crap shoot, especially when you get into really complex applications. That is why you never, ever bid fixed-bid. When you get to the point where you’re approaching the upper limit of what you’ve estimated and you’re nowhere close to done, then you have to make a hard choice: Do you tell the client you’re going to go wildly over-budget and hope they just understand? Do you suck up the extra hours and consider it an investment in your career? Split the difference? That decision depends on your particular client and circumstances, and might be best left for a different blog entry.