4 ms·

At the beginning of my contracting career I neglected to think about all the time I'd spend on non-coding tasks. It wasn't insignificant. I also found that th

At the beginning of my contracting career I neglected to think about all the time I'd spend on non-coding tasks. It wasn't insignificant. I also found that the 4x full-time hourly wage is about right. A few other things I learned: Almost never take a fixed bid contract. They're pretty much always a net negative. Give clients discounts for paying early. Everyone loves a discount. Never discount your hourly rate though, because once you do that once for a client they'll never stop arguing with you about it. There's a line on Schedule C for recording discounts. If you turn over raw source code to a client, stress (in written, contractual form) that if any other contractor/employee changes the code, then you will charge them a premium rate for any changes or fixes.

kod 9y ago
The flip side of never taking a fixed bid contract is when it turns out someone really just didn't RTFM, and it takes you 15 minutes of real work to fix their problem. Thousands of dollars of benefit to them... and one billable hour to you.
- TaylorGood 9y ago
  Exactly. The most recent work I shipped was on a fixed-rate retainer. I based it on the value and not time. Internally, I knew how many hours it would take and was pleased with the ROI.
kfcm 9y ago
I only do fixed bid projects (plus expenses). In my experience, clients want to know up front what they'll be paying (or a very tight range, with expenses). Hourly, they get nervous they'll end up with The Never-ending Project, it's impact on their budget, and start haggling over hourly rate vs project value.
ryanwaggoner 9y ago
Almost never take a fixed bid contract. They're pretty much always a net negative. This is not the best approach, honestly. No one would pay me the effective hourly rates that I make off fixed rate projects, and everyone is happy. Clients almost always prefer to know what they’re going to pay upfront. Additionally, hourly seems simpler and low risk, but it’s all downside for you. If you’re way more efficient, you get penalized. But if it takes longer than your estimate, clients get pissed. At extremes, they may just refuse to pay. Tell a client your estimate is $10k and then try to bill $30k, tell me what happens :) Just like value-based pricing, flat rate takes a bit more skill to learn, but it’s dramatically more profitable in the long run.
- kazinator 9y ago
  I did some fixed software dev contracts many years ago (1994-1995 time frame). I cobbed the agreements together myself and put in late penalties; as in, I get paid less for being late, with an increasing scale by the day. In some industries, you cannot avoid flat pricing. E.g. bidding on any sort of construction or renovation project. You may have workers under you who work by the hour, but that's your problem.
snowwrestler 9y ago
The last sentence strikes me as sort of old school and somewhat client-hostile. Unless you're working on an embedded system that will ship physically and never be opened again, your code is going to have to change--if for no other reason than to accommodate changes in the underlying technologies. This is especially true considering the libraries and dependencies that are baked into software projects today. If a critical security patch requires a change in the code, your client is going to have to either change it themselves or get you on the job pronto... and do you really want to set the expectation that you will be available pronto, forever? I think the days of write the code, launch, then ride off into the sunset are over. Code should be considered temporary and perishable, and IMO consultants should acknowledge that upfront and help their clients plan for it.

kod 9y ago

The flip side of never taking a fixed bid contract is when it turns out someone really just didn't RTFM, and it takes you 15 minutes of real work to fix their problem. Thousands of dollars of benefit to them... and one billable hour to you.

TaylorGood 9y ago
Exactly. The most recent work I shipped was on a fixed-rate retainer. I based it on the value and not time. Internally, I knew how many hours it would take and was pleased with the ROI.

kfcm 9y ago

I only do fixed bid projects (plus expenses). In my experience, clients want to know up front what they'll be paying (or a very tight range, with expenses). Hourly, they get nervous they'll end up with The Never-ending Project, it's impact on their budget, and start haggling over hourly rate vs project value.

ryanwaggoner 9y ago

Almost never take a fixed bid contract. They're pretty much always a net negative. This is not the best approach, honestly. No one would pay me the effective hourly rates that I make off fixed rate projects, and everyone is happy. Clients almost always prefer to know what they’re going to pay upfront. Additionally, hourly seems simpler and low risk, but it’s all downside for you. If you’re way more efficient, you get penalized. But if it takes longer than your estimate, clients get pissed. At extremes, they may just refuse to pay. Tell a client your estimate is $10k and then try to bill $30k, tell me what happens :) Just like value-based pricing, flat rate takes a bit more skill to learn, but it’s dramatically more profitable in the long run.

kazinator 9y ago
I did some fixed software dev contracts many years ago (1994-1995 time frame). I cobbed the agreements together myself and put in late penalties; as in, I get paid less for being late, with an increasing scale by the day. In some industries, you cannot avoid flat pricing. E.g. bidding on any sort of construction or renovation project. You may have workers under you who work by the hour, but that's your problem.

snowwrestler 9y ago

The last sentence strikes me as sort of old school and somewhat client-hostile. Unless you're working on an embedded system that will ship physically and never be opened again, your code is going to have to change--if for no other reason than to accommodate changes in the underlying technologies. This is especially true considering the libraries and dependencies that are baked into software projects today. If a critical security patch requires a change in the code, your client is going to have to either change it themselves or get you on the job pronto... and do you really want to set the expectation that you will be available pronto, forever? I think the days of write the code, launch, then ride off into the sunset are over. Code should be considered temporary and perishable, and IMO consultants should acknowledge that upfront and help their clients plan for it.