Staying Viable In The Software Design Business: A Case For Deterrence

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.

Similar Articles