

Ask HN: Landed my first freelance job, how should I price the project? - BTBurke

I recently landed my first freelance job based off a little side project that I had on Github.  I&#x27;m not a professional developer, I just do this as a hobby in my free time.  It&#x27;s serendipitous that I have a few months off between jobs and I&#x27;d like to make sure I don&#x27;t make a rookie mistake in pricing this job and setting up the contract.<p>The work is machine learning algorithm development and then integrating the solution into the client&#x27;s existing infrastructure.<p>A few questions:<p>* What are the pros&#x2F;cons of an hourly rate vs. fixed price?<p>* Anything to watch out for in how the contract is structured?  e.g., provisions about intellectual property, dealing with changes in requirements, or spelling out what deliverables are required?<p>* What kind of padding factor do you apply to your estimates of hours to complete a feature?<p>Based on some other things that I&#x27;ve read, I&#x27;m leaning towards pitching an hourly rate with an upper limit.  For example, quoting a high-end price of $X and charging by the hour, giving them the savings if I can implement it in fewer hours or (hopefully not) having to renegotiate if it&#x27;s significantly more complicated than I envision.<p>Any advice would be appreciated.  If someone has a boilerplate contract that has worked well for them in the past, I&#x27;d love to see it.  Thanks HN!
======
psyklic
Congrats! Based on my experience:

* Fixed-price is acceptable risk only if: (1) The project is small (e.g. <= one month), (2) The client has a precise spec (and he is hopefully technical), (3) The project is not R&D -- there is little chance of it failing or taking a lot longer than expected, and (4) Your gut says the client will be easy to work with, will pay you, won't try to add on extra features, etc. Also, I recommend the client be a business where no one is personally invested in the money they are paying you.

* If the contract is hourly, generally the contract is simpler and is much less risky to you than a fixed-price one -- I would recommend hourly for a first freelance project. (Respectfully disagreeing with agibsonccc.) With fixed-price, clients can eat you alive with revisions if you aren't extremely careful with the initial spec and being on the same page as the client. You can also easily go over your profitable window if you have not estimated software before. (A lot of it is not based on your skill, but on how particular the client ends up being.) Also, you run a good risk of not being paid at the end, unless you take precautions.

Keep in mind that with fixed-price bids, you are fundamentally at odds with
your client -- you must finish quickly to make a profit, whereas they want a
quality product. With hourly rates, you both are trying to do the project as
"value-based" as possible, and you make decisions together based on cost.

If you do a fixed-price contract, then ask for half up front. (A retainer
isn't a bad idea for hourly either.) If you make a fixed-price bid, I
recommend estimating the absolutely worst-case scenario hours required then
multiplying by even more. I tell my clients it would end up being cheaper if
they go weekly, since my fixed-price contract by necessity must be a worst-
case scenario estimate.

Also, in general don't transfer copyright (and hopefully the source code too)
until all work is paid for. Your contract should state that it must be
renegotiated if additional work is added beyond the original spec ... again,
you don't need to worry about this as much with an hourly contract with no
guaranteed finish date.

* A better pricing model than hourly/fixed is usually weekly or monthly, where you agree to work full-time for that period and you agree to goals to be accomplished. This way, you do not have to pedantically record every hour and expose your time management skills (for better or worse :)

* For padding, it depends on your experience with your own work. I recommend never to guarantee finish dates in a contract, unless you have a huge multiplier. Estimating the finish date would be fine though.

Personally, I set my prices based on how much I want a job. If I am not
excited about the project, then I am one of the highest bids (and sometimes my
bid is accepted). I do recommend that if you don't like selling, you should
take the rate you were going to ask for and ask for something higher. Much of
the time, the client just says okay -- worst case, he'll just negotiate
something lower.

* I am not a big fan of your upper limit idea. I would quote the high-end price with an hour cap. For instance, $X guaranteed for up to Z hours, then $Y/hr after that -- and you estimate it will be done by Z hours, but it's not guaranteed. If they don't like that, you could say it isn't worth your time unless they buy a Z hour block for $X, then you'll put the extra time toward improvements or whatever else they want if you finish early.

* If you are worried about a contract, do not hesitate to have a lawyer review it. If it is fairly standard, you can probably negotiate a fixed rate of around $200. This Nolo book has a good fill-in-the-blanks template on the CD specifically for freelance software consultants: [http://www.nolo.com/products/consultant-and-independent-cont...](http://www.nolo.com/products/consultant-and-independent-contractor-agreements-cica.html). The book has separate ones biased toward the employer and biased toward the contractor, so you can see the differences and what they might try to put in that would be against you. It is a pretty comprehensive contract and pretty biased toward you ... but it's always in your favor to supply the contract rather than to accept theirs.

~~~
agibsonccc
More thorough answer than mine. Go with this guy.

That being said: you bring up some good points.

This is definitely from my experience that hourly ended up being a headache.
The clients I've had in this space tend to want a race to the bottom in price
when you get hourly. I've always had it where the client wants a lot more
validation and other problems when the project isn't fixed price.

Everyone has their own experience. Let me just defer to patio11 for how you
should price contracts:
[https://training.kalzumeus.com/newsletters/archive/consultin...](https://training.kalzumeus.com/newsletters/archive/consulting_1)

It worked for him as well from what I'm seeing. Go with what works for you.

~~~
psyklic
That is a good point about hourly rates. Make sure your hourly rate is high --
in my experience, the more you charge, the more your client respects your work
and time. Plus, you can afford to give some free hours or work a bit extra to
make sure the end result is quality. Keep in mind that as a freelancer in the
US, about 1/3 of your income goes toward taxes -- plus you don't get benefits
like a normal employee would.

If someone specifically wants you for their project, then you can usually
negotiate a pretty high rate -- especially for something as specialized as
machine learning! People hire me often because they hired someone off
Craigslist at a low rate, and this time they want to make sure the project is
done right.

~~~
nickzoic
For some perverse reason, I've found clients get less uppity about a day rate
than an hourly rate. Plus that way your timesheets are simpler.

------
agibsonccc
Hourly rate will make more headaches for both of you. Fixed price allows you
to negotiate up front, take a certain percentage as a deposit.

Make sure IP is yours till full payment is received. Changes in requirements
should require a restructuring of the contract. Make the client work for being
fickle.

Get a statement of work. Clearly define requirements, again makes it easier
for both of you.

Never think in hours. Think in weeks. 3x your gut estimate should be accurate
enough.

Again: hourly is terrible. If your client is THAT focused on price you might
end up in a bad situation where it's you vs them. That's a toxic relationship.
It should be you two working together to solve a problem. Make this mutually
beneficial.

Lastly, never focus on savings. Focus on value add that your project will
bring them. If this ML algorithm will help a core part of their business, make
that clear to them.

Your value add isn't an algorithm. It's going to help their profits by a
measure of X%.

Now some machine learning specific advice: Integrate what it might take to do
data pre processing, cleaning and formatting in to your time estimate. Try to
get as much information from the client as possible about the structure of the
data, how they want it integrated etc.

Oftentimes, I've always underestimated that part of the job.

------
wikwocket
For estimation, I like to carefully calculate exactly how long I think it will
take, add some padding, then double it (for all the unknown unknowns). Then
add some padding, and double it (to cover overhead and communication and
documentation). Then add some padding, and double it (to cover changing
customer requirements, and the fact that the last 10% usually takes longer
than the first 90%). Then add some padding.

Also, here are some additional cons of an hourly rate:

* The better/more efficient you get, the less you earn for a project of fixed size.

* You are incentivized to drag your feet, while your customer is incentivized to expect superhuman feats of coding in a given time.

* People don't like being charged for phone calls, meetings, email, specs, documentation, testing, "small" changes, etc.

* Some customers are inclined to nitpick itemized time sheets.

A different approach I like is to break the project up into features of
manageable size. This forces you to spec it out enough so that you can break
it into chunks easy enough to estimate. Then you can put a price tag on each,
loosely based on effort but also based on value to the customer. And then the
customer can play "feature bingo" to decide exactly what they want, instead of
haggling about your rate or the project's scope.

------
saluki
Go with a fixed fee for a set scope of work . . .

I don't like hourly and definitely don't go with hourly not to exceed.

Break it up in to multiple mile stones with incremental delivery,
review/revisions and payment . . .

I would have early initial milestones so you make sure you and the client are
on the same page . . . and that they are happy with the initial work and
making payments . . .

If you can maybe quote 1 or 2 phases and see how the project is proceeding and
if you are making a profit . . . you could also take some time to mock up a
more difficult part to see how it's coming together and then quote that
difficult phase as you are working on the initial ones . . . if a particular
phase that you already have quoted don't be afraid to approach the client and
see if you can work out an adjusted fee so you're both happy and a quality
project is delivered.

I would setup the IP stating that you won't reuse the project in it's entirety
but that you have the right to reuse portions of the code in previous, current
and future projects. As most projects have modules you've used before, will
use on your current project and on future projects.

There are some good boiler plate contracts out there.

Good luck with your first freelance project.

