What Happens When a Freelancer Does Work for a Client Without a Contract

Just as a counterpoint to this, it's possible for a client to not pay you for services rendered and sue you for not maintaining previous accounts/services for them, and the courts might very well take their side, depending on the specifics. Whether there is a written contract or not, there is a contract when you agree to exchange services for money; the only difference is that if it's not written and a conflict arises, you're depending on the court system to guess what the agreement was based on the word of two opposing parties.

I understand what you're saying though; realistically a lot of work gets done all over the world every day without written contracts, and everyone is okay. My general rule of thumb is to never extend more than a few thousand dollars of credit to any client without a written contract, and less if the job could involve any sort of extra liabilities. For a retainer-style agreement like the one you describe, I like to have a contract in place from the get-go, but with the "terms of notice" set so that things like email count--that way, if we ever negotiate for a specific project I can do it over email and count that as a written record of our agreement should the need ever arise.

A purposeful contract makes sense in every situation but if you have clear documentation without one, you should be pretty well off when a problem arises.

The notion of hourly work is something I try to divorce from my thoughts. Yes I do base what I do on some hourly metric but the complexity has to matter to some degree. Generally more complex = way more hours but that's not always the case. Most of my problems in this area come from uncovering a hornets nest when something just seems simple enough on the surface.

I like to think of it this way. Office is still $x per seat. I may have figured out 98% of a domain but I should charge the last customer the work it took to get to that point from customer #1. I may have to do much less work if I've done my job right but there's no telling exactly what of that they'll want to unravel in the process. Unlike Office I don't have a bankroll for r&d I can charge a premium for to recoup my losses over clients. Clients need to assume that just because they want what someone else has its never what they paid - the hours it takes to just tweak it for them.

> but merely an email trail will suffice to make your point and get the other party (if honorable) to pay.

This is true if and when you are expressive in your emails. As soon as a new feature is added to the scope, it is imperative that you speak out and say "Well, this is out of scope, but we can likely accommodate by adjusting the scope ".

Far too often I see freelancers just take on the work without mentioning it's a scope change, only to have to fight for the bill to be paid later.

In fact, most of the people I see complaining about customers not paying are due to a failure of setting appropriate expectations. If timelines are changing as a result of your efforts, notify the customer. If they're changing as a result of the customer's actions, notify the customer. If the scope is changing for any reason, notify the customer.

Do not expect to be able to submit a bill at the end of the day and have it be paid -- in companies of a sufficient size, the person paying the bills is not the same person you're dealing with on scope, and the person paying the bills is likely being paid, in part, to ensure that they aren't being over billed. Where that's the case, they'll examine the contract line by line and compare it to the invoice, and pity to whomever meets someone good at that job.

They're not trying to screw you over, they're just trying to make sure taht they're not getting ripped off, and changing how you bill the customer without notifying the customer of a change, looks very much like ripping them off (even if it isn't.)

Use contracts. Use email. Speak plainly.

The SOW is responsible for laying out what work you're going to do. If a changing spec is a project risk, a typical consultant response to that would be to build some of the spec language into the SOW, so that if the spec changes in a way that materially harms your ability to complete the project, you have recourse with the client.

The typical best case scenario for spec slips on projects is a client that extends the contract to account for them, and a somewhat rigorous SOW is a good tool for making that happen.