For years I have always approached the design of software projects with “fixed price” contracts. I have used this type of contract since 1994. Frankly, it has always been a “hit or miss outcome” with these set price contracts. Sometimes I found nice customers to work for, while other times I wound up with undesirable people.
During most of the 1990s, the wrong people were not really terrible to deal with – they just weren’t good. Beginning in 1999 and 2000, this began to change for the worse. When I fell in with someone bad, they tended to be even worse than they had been during most of the 1990s. This trend repeated itself during the next dozen years and the bad customers seemed to get progressively worse with each passing year. Finally, in 2013 I began doing some programming work for someone who seemed nice at first. Before long, this person began to take advantage of me and I quickly put a stop to it. Next, I was receiving hostile voice mails and emails from this troublemaker. I finally went to court a while later over this and recovered about 64% of the money I was owed. To make a long story short, this debacle made me realize something. I needed a new contract for my programming engagements.
If 80% to 90% of my fixed price contracts attracted people who were undesirable to work for, then that was sending me an unmistakable message. The only other option was to charge by the hour. I have tried to avoid this for years, because I knew it would make it harder to find work. But this thinking becomes irrelevant if almost all of the work I do find with fixed price contracts isn’t even worth doing from an economic vantage point. The problem is that fixed price contracts seem to attract people who will never pay by the hour. They tend to demand far more work than what they are paying for with regard to the face value of the contract. The industry term for this is “scope creep”. To me, it’s just plain creepy and very bad for business.
Next, I began to revamp my existing contract so it would be geared for an hourly rate instead of a fixed price. I then made an appointment with my attorney to review and make any needed updates to it. The new contract states that I must be paid for every 10 accumulated hours or less than 10 accumulated hours if I have reached the end of the current programming engagement. The liability disclaimers between the old and new contracts didn’t really change that much, because they always did a fine job of protecting me from liability exposure. The real problem was offering fixed price agreements for my custom software projects.
I have learned one thing the hard way in all my years in this business. You can’t make money unless you are first preventing the headaches that cost money. In other words, the people who cause so much of the trouble need to be deterred from entering my business from the outset. Don’t get me wrong - there are a lot of nice customers out there who are great to work for. There are also a lot of kooks who seem to think I owe them the bargain of the century. When one of these shysters gets into my custom software business, he or she will show absolutely no respect for me, my time, my contract limitations or anything else. The scoundrel will squeeze me for every last drop of unauthorized labor. Believe me, I saw it happen too many times back in the old days!
In my mind, the real purpose of a contract is to deter undesirable people from entering my business to begin with. The conditions of the contract have to be strong enough to send them away from the outset. And if one bad apple does get in, I have to be able to stop the shenanigans very quickly and get out of there with no legal strings attached. My new hourly labor rate contract should facilitate this capability. Predictability is what I really want, because that keeps the money coming in. My new hourly labor rate contract is designed to keep things on a predictable and consistent track.
Join the conversation! Your thoughts help the community grow.
Sign in to leave a comment
It is the same account you read, post and publish with — and you will come straight back to this page.

Sam HobbsPosted Jul 25, 2014, 11:52 AM
I assume that you lump the analysis and the development together. I have always considered it to be better to not do that. I do not have experience such as you so you know better than I but it seems that doing the analysis as a separate project would solve many problems. For one thing, it would lock in the design such that if there are any design changes then that would require another design and enable a renegotiation of the contract. Also, if a client were to be unreasonable then you would learn that sooner before getting too involved. These days, there is an abundance of programmers but good designers are limited. You can offer your clients the opportunity to use the system design to shop around for developers. They should be willing to pay well for a good design and with a good design they might be able to the system developed for less than what is profitable for you.