Small Fixed-Bid Software Contracts Are A Bad Idea

I went on an interesting interview. The employer needed a small custom software project for his business. However, he insisted on only hiring someone on a fixed-bid basis, and not on an hourly basis. He also wanted someone local who would work on-site, rather than some Indian outsourcing firm.

The problem is that, every time I talked to him, he gave a different description of what he wanted. He kept mentioning new features as we were talking about the project.

That’s the fallacy of fixed-bid instead of hourly billing. The odds are almost zero that someone non-technical can write a perfect specification, before seeing a demo. There always are new features you want, once you see the alpha version. I tried explaining that to him, but he insisted on fixed-bid only. I pointed out that, without a written specification, it’s impossible for me to submit a bid. Without a tight specification, I can’t accept the project, because it will only lead to an argument about whether it’s done or not. I also pointed out that, with a fixed-bid, I won’t implement anything not mentioned in the specification, although he could hire me to make more enhancements.

If it was hourly billing, he can change his mind as I work and it’s no problem. When he insists on a fixed-bid, that creates an adversarial situation, where I have the incentive to do exactly what the specification says and nothing else. However, hourly can also lead to problems, if I’m less productive than other people. I know that he’d be getting a bargain with me, but he’s to clueless to notice.

He said that he was going to write a specification, and send it to me to review. I told him that, if he wanted me to help him write the specification, he could hire me for 1-3 days and I’ll work on the specification with him. He got very angry when I said that. He said I should work on the specification for free, to help close the sale.

The fallacy is that, if I write a proper specification for him, then he can hire someone else to implement it. There is no guarantee that he will hire me for the project, after I write him a good specification. For a project like this, a good specification is more than half the work. If I polish the specification to the extent that I’m comfortable working based on it, then he could hire someone much cheaper. If I work based on the lousy specification he writes, then it will only lead to arguments when it doesn’t match what he really needs. If I help him write the specification, I’d be giving him valuable free consulting, and wasting my time.

Also, it was a red flag, that he wasn’t willing to hire me to help him work on the specification. If he isn’t willing to do that, there’s also a risk that I could complete the project and not get paid. He thought he could write a good specification, but it was obvious that he didn’t have the required level of computer literacy to do that properly.

A 1 month project isn’t really worth it, if I have to put in a week’s worth of time closing the sale. It’s better for me to focus on longer-term employment. The time I spend writing the specification for him, could instead be spent going on other interviews or sending out resumes or working on my blog.

I’m also concerned that, if I make an over-estimate bid and finish early, then he’ll be reluctant to pay me, thinking he was robbed. Why else would he demand I work on-site? For a project like this, an over-estimate bid is necessary, given all the risks, even though it’s a simple project.

Due to the inefficiency of the State legal system, if I complete the project and he refuses to pay me, then I have no recourse. It’s impractical to sue and collect.

If he takes his weak specification to someone else, they’re almost definitely going to deliver something that isn’t suitable for his needs. In effect, it’s already a doomed project. He’s fixated on fixed-bid and doesn’t have the skills to write a proper specification. He won’t trick me into writing a specification for him for free, and someone else probably wouldn’t do that or do it as well. I feel bad that I couldn’t help him, but it looks like there’s no way I can work with him without being exploited. It’s a bad idea to work for someone who’s too clueless.

If you’re an individual, a small fixed-bid software project is a bad idea. There are too many risks. Without a proper specification, it’s doubtful that a fixed-bid project would match his needs. If I help him write the specification, then he can hire someone cheaper to implement it. By writing the specification for him, I’d be doing more than half the work. There’s a risk of not getting paid, if I write something that matches the specification but he decides that doesn’t meet his needs. Because he insists on me working on-site, there’s the risk of him refusing to pay me if I finish ahead of schedule. With a very short project, I’ll be forced to look for something new again in a few weeks. I understand the desire to contain costs, but a small fixed-bid software contract pushes all the risks on the programmer.

3 Responses to Small Fixed-Bid Software Contracts Are A Bad Idea

  1. Anonymous Coward June 25, 2013 at 1:35 pm

    Every time a low-life, like the manager in a factory that asked for free parser as part of a joelonsoftware job post, scams someone out of free work, it destroys the system in that nobody can trust one another.

  2. I think if you did help write the specification with no pay you should reasonably be able to insist it is your intellectual property and if he wanted to use it for a different contractor’s bid he would have to compensate you.

    I know you will find pitfalls with that solution but it might be worth considering.

    • If he uses my specification with someone else, how can I prove it? It isn’t practical to sue and collect.

      The best defense against a shady employer is refusing to deal with them.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>