[fsk]

Recently, I did a couple of hours of work for a client, WITH A WRITTEN AGREEMENT, and didn't get paid. It isn't worth the hassle to sue and collect for a couple hours of work. So, I wrote the experience off as a loss and moved on.

My rules now:

1. If you want me to write a specification or project plan for you, I expect to get paid for it. If you want me to formally review your wireframes, I expect to get paid.

2. I'm willing to risk a couple hours of work to find out if a client is a deadbeat or not. If it reaches a certain limit, no more work until I get paid.

Basically, you did the work of writing a specification for free (which can be harder than implementation), and now he's shopping around for someone cheaper to implement it. That's why I'll never write a formal specification for free.

If the client is too cheap to pay me for spending a day or two helping him write a specification, then there are going to be other problems later.

[aasarava]

This is good advice. I've been freelancing for 7 years. When you're talking with potential clients, it's reasonable to spend an hour or so talking about the project requirements and the client's needs and expectations, not to mention discussing your own background experience, to see if it's a good fit. I might then spend another hour or two looking at the client's specs and putting together an estimate.

But I don't do unpaid work for them. If they don't yet have a spec and are still exploring options, I let them know that one service I provide is consulting on a strategy and helping write a spec, creating wireframes, etc. They can hire me hourly to do that, and then decide later if they want to hire me to build it out.

Now, when you start bidding on much larger projects, you may spend more time reviewing specs. And you'll have to decide whether you want to get involved in the RFP process that some clients require. I typically opt out of those because they do require lots of unpaid work upfront. (I saw one RFP recently that wanted design mockups; no thanks.) And sometimes it seems as if clients have already chosen their vendor but need to do the RFP paperwork to make their decision seem legit.

[fsk]

Another rule for a small freelancer: Bill hourly. Never accept a fixed-bid contract. These small clients will withhold payment until every last detail meets their desires. Plus, it's NEVER a good enough specification. Also, most clients will change their mind about they want when they start seeing results.

Suppose you take a fixed-bid contract that you expect to take a month. You do your month of work and deliver it to the client. Now the client asks for changes X, Y, and Z, and says they aren't paying you until it's done. Now your options are (1) Argue about whether that was covered by the original specification, which does no good even if you're right because they're refusing to pay. (2) Follow the sunk cost fallacy and do extra work for free, hoping to get paid for the work you already did. (3) Walk away, and don't get paid for the work you already did. Also, if there was a deposit, now the client may try to sue you! (4) Sue to collect, but they know that you, as a small freelancer, don't have the resources to lawyer up and sue. Even if you hire a lawyer to write a tight freelance contract, they may refuse to sign it or attempt to negotiate it, and the lawyer fees are more than your revenue.

For example, at my last job, my employer hired a freelancer (not me) to do a WordPress site. Even though the site was done, he refused to pay, because "his business was having cashflow problems". I pointed out "Hey! The guy did the work! Why aren't you paying him? It's not his fault that you're having financial problems!" He did, several months later, pay. Then, the guy put a logic bomb in the site that I had to remove. (Owner: "WAAH! My site was hacked! Fix it! I'll pay you extra if you fix it now!" [I was not there that day.] I fixed it, no bonus was paid.)

[aasarava]

That's an interesting take on the reason to bill hourly, and I know a lot of developers who do that. Personally I've switched to mainly doing fixed-bid contracts.

Rather than selling my time, a fixed-bid contract allows me to sell my expertise -- and that often is more lucrative. For example, a client may need a solution to putting hundreds of documents online and making them searchable. That may only be 40 hours of work, but it's a problem that has been costing the client tens of thousands of dollars in lost productivity each year. As an expert, I can sell them a solution to their problem in a way that saves them money and is still profitable for me.

Beyond that, a well-written fixed bid contract lets everyone know exactly what the costs and expectations are, and what the schedule is. No more having projects drag on and conflicting with other projects I need to be focusing on when we all know that there's a set deadline for the delivery of a specific solution.

Of course, doing this successfully requires knowing what questions to ask to get a detailed spec, understanding how long it'll take you to really do something, and anticipating the gray areas.

I also like to build in "flex time" into fixed-bid contracts. For instance, I might specify that the contract includes "20 hours of revisions" to the requirements once the client has had a chance to review the prototype. I'll price this into the estimate. This way the client knows they'll have a chance to make changes, but they also know there's a limit after which the project cost increases.

[fsk]

The problem with fixed-bid is that the client almost never has a decent specification. If I write the spec for free, I know he'll then just shop the spec around on freelance sites, and I wasted my time. They always get insulted when I say they should pay me for 1-3 days to help the write the specification. One guy expected me to give an estimate without telling me any of the details first.

I noticed that small businesses who want fixed-bid contracts tend to be cheapskates and they're the type of person who'll haggle every little detail and look for an excuse to refuse to pay.

I'd rather target the higher end of the market than the bottom of the barrel. Also, the work I prefer tends to have greater complexity than just churning out a simple site quickly, making fixed-bid less sensible.

[jpd750]

Fsk - do you think this is what happened here to me? "If I write the spec for free, I know he'll then just shop the spec around on freelance sites, and I wasted my time"

[fsk]

Probably yes. You learned a valuable lesson.

I don't know the details, so I can't be 100% sure.

From your description, he handed your spec to another employee, and now that employee is trying to implement the spec YOU WROTE FOR FREE.

[psyklic]

I have also experienced the problematic client you describe. The client had neverending revisions. He could never present me with a final list, even after all items in the contract were complete. He then refused to pay, unless I added additional features not included in the contract. Even after adding some of these, he was never satisfied. He made a long list of false claims against me and threatened to sue unless I added more features. After this, I immediately halted work and (successfully) pursued the rest of the money in court.

My conclusion is that fixed-price bids are bad only if there is a lot of risk -- in this case, the bid amount was far lower than it should have been, the client was underfunded, etc.

Nowadays, I recommend making fixed-price bids that are large overestimates. I am taking a risk in making a fixed bid, and in return the client gets the surety of a fixed amount. If my fixed bid is supposed to literally be my average expected time times my hourly rate, then there is a 50/50 chance (or likely more depending on the client) I will lose money on the deal!