On the flat rate model: I like to tell the story that the highest hourly rate I've ever earned to date was as a college student when I took on a fixed rate project to fix some department's "we have a web form that is critical to our work and backed by this perl cgi script that used to work but doesn't do anything anymore" problem.

Turned out someone had uploaded the perl script to a Linux server using dreamweaver on a Mac, and the line endings were wrong. So I ran dos2unix on it and added a blurb to some documentation on what not to do and how to fix it again if necessary.

Made $1000 for less than 15 minutes of work!

But of course I also could have spent two weeks bashing my head against an awful perl script, never figured it out, and made nothing. It's a risk/reward trade-off.

> when the client has a specific, measurable problem that they don’t know how to fix (but you do)

Then the client tells you that wasn't their problem in the first place.

In the 10 years of contracting I've never done fixed rate for the reason the client never knows what they exactly want. It's not like installing a tiled floor or drop ceiling.

Being a professional means a lot of things, but fixed rate contracting is amateur hour truly. Every software dev learns this eventually.

In software, all problems are research and development problems. (If it wasn't, it would already be solved now.)

You would be amazed to know how many problems have been solved in software, but the client has no idea what the solution is or how to implement it if they did.

Which is why you have clear boxes on that fixed-rate, and stepping over those bounds means you're back into T&M billable. The legalese on these contracts needs to be quite tight, but it's a one-time expense to set that up, and it's best done properly (and updated as new edge cases show up).

Yeah I'm honestly amazed at how many software people don't get that the optimal strategy is cheap fixed price and incredibly high margin change requests.

That being said you need a good spec to do this, and that definitely isn't normally the case in software.

There is so much work out there that is cut & dried. It's not what you'd call software engineering stuff - more the bread & butter of consultants. But you really need to know the domain space to ensure you have those cutoffs (some of which might sound very limiting). About 3-4 times after you've deployed a specific solution for a specific vertical, you should be able to productize it (on 2nd and 3rd times through you're essentially spending extra effort to determine and test those boundaries for future implementations).

Often the goal of a cheap fixed price is to show how limiting that is so they know why you can't productize a fully customized solution.

Game development adds another dimension. A musician I know helps small indie artists with music as a side business. His contract states a fixed number of hours producing the music and effects is free, until earning some 100k revenue / month, when it starts costing 0.1% of revenue royalties / month. He has fun with it, it's usually free, but if someone makes the new Minecraft with his music, he will get his share.

Good luck ever getting that share of revenue

Can't you just change the music in a silent update if the thing took off?

Sure you can. At 100k / month revenue, you have 100 currency / month or 1200 / year available for another artist, which may or may not include the risk of messing up the "feel of the SFX and music". Even at 10x that, that's a paltry sum, especially if identity is tied to it.

Honestly with it being such a small percentage you have to really hit it big to make such a dick move even worthwhile anyways

> Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client.

What about fixed price makes the client happy in this situation? It's definitely not the fact that the contractor billed "waaay more than hourly".

The upside of fixed price is that it's more predictable and it aligns incentives. With hourly, the hidden incentive is to take as long as you can get away with because every additional hour you take is an additional hour you can bill.

With fixed price, the contractor has an incentive to finish earlier.

That's the part that I find many contractors miss: They treat fixed price as an opportunity to extract more money from the customer. As someone who has been on both sides of this (I've been a contractor and I've also hired a lot of contractors) I lose trust quickly when I spot contractors inflating fixed price bids because they think I won't be able to recognize what they're doing.

The client is happy because you solved their problem. Now they can take that solution and earn money on it, or reduce their ongoing costs, etc.

If your bid is more than the problem is costing them, they won't accept the bid.

If your business model is "inflating fixed price bids" rather than "solving problems for clients" then sure, you won't do very well in the long term.

They got their problem solved for an agreed-upon price. What's not to like?

It's actually the parent that taking the risk. As they said, it could have easily been some hairy problem that took forever to solve.

Is it "inflating the bid" or "charging a premium for fixed cost".

You are welcome to haggle on price or not hire them. As a freelancer or bussiness owner, not every prospective bussiness deal goes through. That is not a failure of their model, just the realities of commerce.

What you mean to say here is that time & materials project structure makes sense when there's a lot of scope risk. Hourly billing never makes sense in our field, unless your bill rate is so high that all of your projects are denominated in small numbers of hours.