Ask HN: Freelancers, thoughts on charging by the hour vs. fixed fee? | Hacker News Reader

Ask HN: Freelancers, thoughts on charging by the hour vs. fixed fee?

I've starter freelancing recently (~4mo) and billing clients by hour. My current dilemma is regarding continuing on hourly billing vs. fixed-fee projects.

The biggest argument against charging by the hour is that you are punished for being efficient. While this is sort of true, I also find that hourly work gives you more freedom to approach the work with a "craftsmanship" mindset. We all know good work takes time.

I worry that if I start taking fixed-fee projects the incentive to make good software will be gone (the faster I deliver, the better). There's no incentive for documenting things, writing tests, creating a CI/CD pipeline or any of that. These things simply become nice-to-haves that will not matter once you deliver the project and cash yourself out.

Thoughts? Curious to hear the experience of who's been doing this for longer than me!

View on HN

Fixed fee vs hourly billing also entail different risks. Clients willing to pay a fixed fee want you to assume the risk of cost overruns. You need to price this risk into your fixed fee in the form of additional margin. So, if you estimate a job will take 100 hours, your hourly costs are 100€ and you calculate a 10% profit margin and a 10% risk margin, your quote would be for €12,000.

If you are good, and you always manage to deliver within your time budget, the risk premium compensates you for the risk you are assuming.

Fixed price contracts require stringent change management. I recommend that even zero-sum changes go through a formal change process, so that your customer understands the difference between a fixed price and an hourly rate contract.

There is more potential conflict with a fixed price contract. There will be disagreements whether a particular item is included in the scope. This means you need to be more precise when defining the work.

The items you mentioned (documentation, etc.) have no bearing on whether you are quoting fixed price vs hourly rates. If the customer wants these things, they should be included in the paid scope of the contract. Your focus should always be on delivering software that delights the customer, because only then will you get repeat work.

Some great points AlDante2. There is also the issue of how open-ended the engagement is versus clear confined specification.

I work with clients on an hourly basis because of the open-ended nature of the work I generally do. It is almost impossible to write a decent spec ahead of time. I do a weekly check-in with demos and discussion so they know what I am working on, how much progress is being made and with weekly check-ins they don't have any surprises at the end of the month when I bill them.

Recently, I added a new client where I was much faster than the estimated hours for the initial scope of work. If I had been fixed bid with them I would have made a lot more per hour. As it is they are using the remainder of the hours in the original estimate for some other work and it sounds like there will likely be more in the pipeline. Truthfully, I would rather have them turn into a longer-term client in a high trust relationship than to have maximized profit on the first project.

> I worry that if I start taking fixed-fee projects the incentive to make good software will be gone (the faster I deliver, the better). There's no incentive for documenting things, writing tests, creating a CI/CD pipeline or any of that. These things simply become nice-to-haves that will not matter once you deliver the project and cash yourself out.

The things you listed sound more like deliverables that the customer either does or doesn't want. If, as you say, most of your customers don't want them, then you shouldn't do them or bill for them. For example, if the customer doesn't even know what CI is, and they don't already use it, then if you do provide it, it likely will be ignored: it isn't part of their culture and they aren't likely to adopt it as part of their development practice just because you delivered it with your project. If they are paying you to educate them about CI, why it's important, how it works, etc., that's obviously different.

IMO, a fixed contract (I've worked both ways for large corps) doesn't mean you will produce "bad" software. But it does prevent you from futzing around too much with unimportant details like code formatting, giving variables better names, changing 10 lines of code to remove 2 duplicate lines, etc. These are the kind of things that programmers routinely do to make their code "better" (I do it myself), and as a personal project, that's great; I think it makes you a better programmer, and the next time, maybe you'll come up with better variable names the first time. But a paying customer probably doesn't care whether you name a variable n or nrows, so billing extra hours to write "good" software is not worth it. If it works and is not a maintenance nightmare, then it is "good enough" for commercial work. Another way to look at this: if you asked the customer "I need to spend 5 more hours to change the names of some variables to make the logic more clear, and need to reformat a few functions", are they likely to tell you to go ahead and be glad to pay for that or "that's not important for this project"?

Edit: I didn't write that very well. The main distinction I was trying to make is between paid-for commercial work for clients vs "craftsman" quality work that you personally care a lot about, not about hourly vs fixed.

If you're setting this stuff up when you're doing hourly billing, are you not explaining to the client why it's worth the time in the long run? Just do the same for fixed price quotes. There must be some value to the client or you probably wouldn't think of doing it.

> While this is sort of true, I also find that hourly work gives you more freedom to approach the work with a "craftsmanship" mindset. We all know good work takes time.

I feel the opposite with hourly. In the worst case, you're having to ask permission before billing hours on something (like setting up CI) and then having your timesheets scrutinised. This takes up time itself and slows everything down. With fixed price, the client doesn't have to worry about tracking your hours and just lets you get on with it.

> There's no incentive for documenting things, writing tests, creating a CI/CD pipeline or any of that

This almost sounds like you're creating a false dichotomy where fixed-fee automatically implies lower quality because there isn't a per-job incentive to do well. But, that is taking the extremely short view — as in, you're only looking as far as your current job.

What about the next job? Is your current client going to recommend you if you do a shitty job? Are you doing a shitty job if you don't write tests, documentation, etc.?

Word of mouth referrals are huge in freelancing. Your best path to success is building up a great reputation as someone who does really good work. Work that people are willing to pay a lot of money for.

Read this: https://www.kalzumeus.com/2006/08/14/you-can-probably-stand-...

In my current experience, clients are mostly non-technical and have no idea of the importance of documentation, what is an automated test, or what a CI/CD pipeline is for.

You can perfectly develop software without these things. Just test things manually, deploy from your computer, and memorize a few commands to develop locally. I'm also not saying fixed-fee will result on complete garbage software, it's just that there's no incentive to go beyond mediocre.

It is going to make things worse for the next freelancer or whoever maintains the code, not you.

Reply on news.ycombinator.com