I'm not in love with any scheme that causes you to resist quoting prices your clients will understand. They want to know how much the project will cost. Tell them how much you think it will cost.
There is a huge premium to be captured by consultants simply by eliminating the appearance of uncertainty. Clients pay extra for perceived determinism.
I agree giving the project owner the appearance of certainty will make him feel safe and comfortable - however it is not good for them. The longer and more complicated the project the more likely your estimate will be wrong. So giving the customer a sense of overall effort is good - misleading them by telling them you know how much the overall project will cost is bad.
So provide a conservative estimate billed in week-long increments. You come in way under the wire, they get a week or two deducted from the final cost of the project. Customer dicks around with requirements, you get to say "I am happy to do whatever you'd like and make whatever changes you'd like but I need to remind you that we have a fixed schedule for this project".
All this stuff about "what's best for the customer" tends to be an elaborate justification for complicated pricing schemes that alienate customers while ironically undercharging them for the services you provide.
Avoid customers for whom a week's worth of your time is a make- or- break- the- business decision.
Good point. the way I was thinking about it was more like this
1- you provide an overall estimate on where you think you could come in at. you do this to give all clarity on how you are thinking about the problem, anchors your estimate and the functionality you are about to build, and allows the owner to get a sense of price
2- only commit to a week or 2 at the time. this allows the client to tweak things, see quick progress, and add or subtract features as you make progress. Or even stop, test features on customers - and pause.
The customer wants you to commit. When you say "let's do a week at a time", the customer does a mental calculation of what one week of your time is worth if the project doesn't complete, arrives at the number $0, and responds accordingly.
That doesn't mean you work a fixed-price gig. It does mean that you give serious thought to a conservative estimate of the whole gig and then confidently offer that as your price for the engagement.
That's solid advice, but only follow it once a sense of trust and rapport has developed between you and the client.
There's far too many things a potential client may not be telling you about the project, and it's incredibly hard for the independent freelancer to do enough business development, or for the client to do enough vetting, to know which random internet person is trustworthy. This is especially true when you're just starting out.
A one week sprint that solves a small, immediate need the client has will keep the project manageable, and protects both the freelancer and the client from a potentially bad situation. Worse case scenario, one of you is out a week's work. Best case scenario, after a few sprints a rapport and trust develops, and you can start providing your clients with estimates for larger pieces of work, knowing they'll be treated as estimates and not fixed bids.
Don't eliminate the appearance of uncertainty when you're legitimacy uncertain. That's bad communication. If a client needs solid estimates out of the gate they don't need an independent freelancer. They need a full-service agency.
Extra related point: some clients will really appreciate to have a higher quote that doesn't risk to go up afterwards, because the budget will be locked at project startup for internal reasons (vs. having a lower cost planned, but extra cost afterwards).
If I had to give a single tip, it would be "don't bill hourly".
The simplest fix for this: give clients proposals that quote an estimated price for the whole project in units of person/weeks, and have your SOW say "time beyond N weeks can be billed at a cost of $X/person/day".
We do "a couple day" projects sometimes, and somewhat more commonly do projects that are longer than a week but don't end on a week boundary.
If I sell you a day of my time, the remainder of the week is then shot for my more typical N-week projects.
That doesn't mean we round 1 day to a week (nothing is more miserable than being stuck on a project that "morally" already ended but demands that you find something to do for the remainder of the time) but does mean we avoid proposing work that is likely to fragment our schedule.
Now, take that logic and apply it to hours: none of our projects are for N hours. There's no such thing as a "partial day". Almost uniformly we'll just do something and not charge for it instead of billing for half a day.
Furthermore, context switching is brutal to hourly schedules. It can take more than an hour just to mentally switch from one task to another.
If I charge hourly, the better I get the less money I make. I can offset this by raising my rate, but a high rate can be intimidating to clients.
They'd rather hear that a project will cost them $1,000 and they can assume that is 20 hours @ $50. In reality, it might take me 5-10 hours. They would've balked at a $200/hr rate, but don't blink at the $1,000 project fee.
Working hourly means your own interests are directly aligned against the client's.
I agree you shouldn't do fixed priced contracts for larger, long-term projects. But a fixed price for a 1-week long project seems to work out pretty well. That's why we developed the 1 week long sprint payouts.
Really good post, I'd just like to add one more piece of advice:
Don't over-extend yourself. When your paycheck is directly proportional to the amount of work you put in, it is very easy (and indeed tempting) to take on more work than you can comfortably handle.
Avoid the temptation. You are no good to your clients if you're always tired.
There is a huge premium to be captured by consultants simply by eliminating the appearance of uncertainty. Clients pay extra for perceived determinism.