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!
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.
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.
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-...