IANAL, this is not legal advice. If you want to do this by the books, get a lawyer. If you want to wing it, take the advice. This is my experience contracting for small to medium business and startups. YMMV, especially with large companies.

Contracts mostly don't matter. Communication matters. Getting paid matters. Everything is negotiable.

The wikipedia article on "work for hire" is informative. Read it. You (generally) have to specifically sign away rights to anything you create, so if you want to resell, you don't need permission, because you already own the copyright. But it will kill your reputation if you screw them.

Take deposits. Get paid +10 days. Work your way into trusting them. Stop working once you get a certain amount of hours ahead of your last invoice, until the check arrives. For a new client, the amount of credit I will extend is about 5 hours. For an established client, I still try to keep it under 40-50 hours.

First thing to know is - there is no such thing as a "standard contract". It's always useful to have a lawyer look over a contract before you sign it. Then - never be afraid to request changes. I've found employers are usually happy to make reasonable contract changes and clarifying things like termination notice periods can benefit both sides.

I've been freelancing since 2002. Some of the common "gotchas" I've seen in contracts to look out for:

1. Anti-competitive clauses (eg. After you work for us you can't work for a competitor for a certain amount of time). I never agree to these and fortunately here in Australia they're illegal in most circumstances.

2. IP ownership This relates to your question. I've found employers are most concerned about lock-in. They want to make sure any project work you deliver is their's to use and modify as they please when you're gone. Not unreasonable. It's when they ask for exclusive ownership that you need to be careful. I've often added a clause that distinguishes between project specific deliverables which can be exclusive and the tools and techniques you develop to deliver the project which you share but can also take with you. I've never had an employer refuse that.

3. Termination clauses Make sure the timeframe for termination (by either party) is in reasonable proportion to the contract term. Eg. I had one contract with (initially) a 1 hour notice period for terminating a six month contract. I asked them if they'd mind extending it to 2 weeks and they were happy to do so. Remember, it's protection for both sides.

I am not an attorney, but I have negotiated both sides of freelance software agreements in the past.

Has the company you will be working with hired any freelancers/contractors in the past? If so, they may have an agreement they've used in the past. Starting with their agreement may save you some time because it will usually already include the stuff that is important to them so you know all that upfront.

In the case that the company doesn't have a preferred agreement, here is a pretty straightforward work-for-hire agreement template that is well annotated and may be helpful:

www.jian.com/software/Contracts/Work-for-Hire-Website-Development.pdf

Things get more complicated if you actually want to retain IP rights (i.e. be able to sell the product you are building to other companies as you mention) since your contract will need to clearly lay out who owns what. I would definitely consider consulting an attorney if that is a route you would like to go down.

Getting paid out can be painful. Make sure do everything possible to make that easy. Properly document your time/efforts and send proper invoices at the proper time.

Definitely document your time - very well, I like web-based apps like Freshbooks to handle my time tracking and invoicing.

Also, make sure your communication/planning between yourself and the client is fully documented. Often times what the client says, and what they actually want, are two entirely different things. You may need to fall back on your previous communication quite often - or at least have a place where you can outline "here is what is going to be done."

I find the combination of Freshbooks, Beanstalk, Basecamp and Highrise to be unstoppable.

I work for FreshBooks, and I second this motion. :)

But in all seriousness: 1. Expect to lose money on your first couple projects. 2. Treat your first 10 clients as if they had a 1 in 2 chance of becoming a major deity.

I'm not exaggerating at all here. Your first clients will know that they are your first clients (or should know) and they will spread the word if you are good. Be good. Be extra good. Be extra super cost saving, awesome customer service, really nice guy, ran the extra 3 miles, good.

Also, stay organized. Make notes about every expense, every 15 minute block billed to client. This was my huge burn when I first started doing my own thing. I figure I have wasted about 4 or 5 grand not being organized. Change orders that didn't get billed because I was "too busy" to keep records tax refunds lost because I could have written off that business meeting lunch. McDonalds has a saying "if you have time to lean, you have time to clean," well apply that to your personal business: "If you have time to breath, you have time to get organized. Actually, just make sure you get organized, even if you don't have time to breath."

I would also, personally, find a really good accountant. I know some good ones around Toronto, but if you have a good enough network you should be ok. Accountants pay for themselves, seriously.

As for lawyers - in my experience you shouldn't need them. But I'm not you, so ask your accountant.

I'd recommend writing your own contract/agreement if you can. Keep it short and simple, what you'll do, how much you'll get paid, when you'll get paid. Also, that you own the code.

I'd recommend being up front about possible reselling. Your customer may gripe about it, but better to talk it out now than make an enemy out of your first customer later. Surprises are bad.

Another option is to find a standard agreement. The other guy mentioned one, there is a book from Nolo Press,

http://www.nolo.com/product.cfm/objectID/2C02C865-21E7-497C-...

and there are surely others on the web.

Be careful about Work For Hire. I believe a Work For Hire agreement transfers ownership of your code to the purchaser. Not what you want in this case.

In Germany I have heard writing one's one contract can have disadvantages: if you happen to include anything that later turns out to be "illegal", it will be interpreted against the person who wrote the contract. "illegal" not meaning something you would be punished for, but there are some things you can not write in a contract (for example "the client agrees to work as a slave for the other party for the rest of his life" - a contract has to be "appropriate").

IANAL, though - not sure how much it really matters, it is just something I have heard.

It might be good to have a checklist for things to watch out for.

I usually try to change the parts about who owns the right to the code. I don't mind the client to be allowed to do whatever he wants with the code, but I don't want to be prevented from using my code. It is hard to describe exactly, but I try to be explicitly allowed to keep using standard practices of coding. Otherwise, a client could put my out of business for good after the first project (I guess that is paranoid, but I just want to get that right), because he owns the rights of my "for loop pattern".

Another thing is accountability. German law knows several degrees of accountability, something like "neglect" and "accidents" (not sure how to translate it). It is possible to make the contract tighter than the standard law, so that you are only accountable for neglect, but not accidents. (roughly something like that...). Also maybe one could write in the contract something along the lines of the client being responsible for testing the software?

[Not legal advice] General tip - always remember everything is negotiable. Just because someone hands you a form contract doesn't mean you have to sign it as is. IP's tricky, but basically you own what you author until you assign the rights (unless it's a "work for hire", which generally doesn't apply, see the Wiki). The company you're freelancing for likely expects that you'd be signing over all the rights to the work product to them -- they're paying for it, after all. If you expect otherwise, then you should document that you're only providing them with an indefinite license to use (they'll probably want the right to modify and own all mods).

I HIGHLY recommend adding a LOT of language to the contract that deals with the exact terms of payment. Some things to consider:

1) What are the late penalties if they don't pay on time?

2) What are the penalties if they (or you) cancel the contract?

3) What happens if you can't meet a milestone or deadline because they didn't give you a deliverable on time? Make sure you aren't held accountable and make EXTRA sure that you'll be paid for the extra time you have to waste in catching up.

4) (If they are not local) Spell out how they send you payments. Priority Mail with Delivery Confirmation is only a few bucks and will avoid any headaches with "We sent the check, we swear"

5) If this is your primary source of income, then Net 30 is NOT good enough. They need to pay Net 15 or better and you should be invoicing every two weeks. Big companies have a real problem with this, but standard monthly invoices and Net 30 will cause you to starve for several months before ever getting a dime.

The BEST way to arrange payments is to spell out the exact date that they will send a payment (and how much). It should be so precise that you don't even need to invoice them because all the info is right there.

6) Specify how long you will wait for a late payment before work stops all together.

In 6 years of contract work, I've NEVER had a contract that successfully avoided all of the situations above. Every one has run into one of these caveats, which are 'conveniently' left out of most boilerplate contracts. If these issues aren't addressed, you will be waiting for money for a LONG time.

Break your projects up into milestones

for example:

Milestone One (Prototype, wireframe, database development (if it's dynamic, or just design) then make them pay up front before you start this.

Milestone Two (Slicing and Integration, programming, etc) break that up into another payment.

and usually I make a final milestone for launch like:

Milestone Three (Testing, debugging, content integration, etc) and have them pay you before you launch the website on their server.

Some clients request contracts, use docstoc.com to find "standard web contract" or have a lawyer. As you get better at giving new customers a sense of trust you don't really have to bother, if they don't bring it up.

If you haven't been heavily client-facing inside a large company please, for your sake, remember to make sure you have written signoff from your clients at every stage re: expectations and deliverables. Clients spending their own money or with an incentive to keep costs low (been at this 10+ ys) have all read the same book, from single owner businesses to major international shoe brands: everything for nothing, yesterday, and "oh how about we make this little change, that won't affect anything, right?"

Also make sure that if it's a fixed price contract, you factor some expectation of hours in there and have a clause handling the case that if you go over by 10% you'll need to renegotiate, or as others have suggested, you pause until payment has been made.

Dealing with small companies, I usually start by suggesting a simple NDA to protect them and make them feel safe. If they don't want more, I skip the administrivia and we move on to solving their problems.

It's been my experience that you're a lot better off being informal about the legalese and just invoicing as often as you can (bi-weekly at longest).

Companies without a legal department generally appreciate being able to do business in a straightforward manner.

Putting yourself in the client's shoes always worked for me. For first time clients, it is the best way to gain their trust. I have never met face-to-face most of my clients. I live in the Philippines and they are either in the US/Canada/Australia. I have a day job and work mostly at night and on weekends. I have been doing this for almost 6 years already and in those years, I only had 2 contracts (both from France).

As someone also in the Philippines and looking to do a little freelance work, how do you negotiate your prices and look for prospective clients? My main problem is that I never really know what to charge, and don't know what the "local" vs. "international" rates should be.

I recently had been contacted by a client thru Philweavers - try to register there too. Charging clients is a little bit tricky. You can charge per projec or per hour. I prefer hourly rates because there is less pressure - you don't get paid unless you work.

I am assuming that you have a steady dayjob. So charge you're client to what _you_ think is worth your extra/rest time. And don't overdo this :P spend some time for yourself -- hack a pet project or learn something new :P Once you get into it, it's hard to back out :(

Hey ballpark, I wanna help you out. I just wrote a rock solid contract for my web dev biz.. Email me and I'll hook you up - graham@somethingpretty.ca

Check Elance, they have several sample agreements you can choose from. In fact, many of the rent-a-someone services will offer these.

Personally, I kept an agreement around for years. Over time, I would add or subtract from it, but in general, once you have an solid contract agreement, you shouldn't need another.

Thanks so much everyone. You guys are great. I have some reading to do. :)

Contracts are to keep honest people honest. But if you are dealing with a con the contract doesn't matter.