Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am wondering what other contractors in the field of software development do when a potential client approaches them with a spec.. in terms of contracts. In my experience, clients will often be happy to proceed with no formal agreement. I know this is quite an open ended question, so I will break it down into a series of subquestions that can be actually answered.

If the client does not have a contract for you to sign, do you present a physical contract to them?

If you have such a contract to present to clients, how did you acquire such a thing? Obviously you can pay through the nose to have a lawyer write it, and other obvious answers, but are there other reasonable (cost effective?) solutions to acquiring such a contract?

At what stage, if any, would you require the client to physically sign such a contract? (what if the job is just one day?)

In some cases, the software you are providing to the client is a customized version of an off-the-shelf, open-source, or proprietary in-house software, how does this affect things?

I realise that the best answer is probably "It depends on the client, and other factors..", you don't need to tell me that. But what are your experiences and opinions about 'best practices' in this area? Or to put a programming slant on it, do you have a reliable algorithm for managing the contract side of things, ie keeping both sides happy, most of the time?


migration rejected from Jan 20 '15 at 18:08

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, Bart van Ingen Schenau, MichaelT, GlenH7, Dan Pichelman Jan 20 '15 at 18:08

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

The main things you want to protect yourself from are:

  1. The customer not paying you
  2. The customer suing you

For a small project less then 1 weeks worth of work. protect myself by having the customer pay a 50% deposit up front. Then once complete I demo the project and get the remaining 50% before I hand over the code. This makes it quick and easy for both parties who do not want to get scared off by contracts. I think number 2 is quite rare so I do not worry about it for small projects.

For any project over 1 weeks worth of work I have the customer pay 30% up front. Sign a contract I provide myself. Have the customer pay progress payments at every 15-25% complete. The contract I have covers me for things like them not paying, scope of work to be completed, not being libable for an damages or content they provide that may be illegal etc.

The contract also provides the customer some saftey that I will deliver on time and what will happen if I do not meet the deadline etc.

I constructed a generic contract myself without a laywer which I use for all projects (I only do small project less then 2 months work). I also attach a seperate Project specific Costing and Devliverables as appendixes to the contract. They explain in detail what will and will not be in scope.

I wrote my contract by googling other contracts online and taking sections from here and there until I had one contract that suited my needs. Probably not the best solution but it works for these small simple projects.

+1 - I would add 3. Not having to sue your customer. – Chad Jul 11 '11 at 16:18
@Chad - I would think that would be part of #1, but you may know of other reasons to have to sue the customer than non-payment. – Shauna Jul 11 '11 at 16:51
@shauna just a quick example though there are others - The customer begins reselling the solution you provided for them that you already own the sole distrbition rights too... – Chad Jul 11 '11 at 18:20
@Chad - Fair enough. :) – Shauna Jul 11 '11 at 18:26

You should present a contract quickly after you've come to a verbal agreement on terms. You want to clarify scope of work, payment terms, and liability, at least. You're better off presenting a contract your own attorney has drafted first, mostly because you'll start off with far more favorable terms than most companies will present you with in their boilerplate documents.

As an example, my attorney specifically called out a subvendor agreement I was reviewing as unfavorable to me because it required a more expensive form of arbitration than he recommends for smaller companies; he redlined it with an agreeable alternative. The choice of law can be a factor as well; one company wanted my contract to be subject to California law even though both of us primarily operate in Washington state. Also, be careful to minimize indemnification risks; most companies will try to sneak in a clause to their vendors that indemnifies them against all claims, sometimes subtly including you as a potential defendant in civil cases that may not even have anything to do with your own errors or omissions.

There's plenty of room for adjustments in most long-term contracts. If you have a clearly defined scope of work, you can reference that in the contract as an attachment. If it's less clear, you can specify the terms upon which you agree to work, what is required in order to allow a variance, etc.

I personally don't choose software contracts with one day timeframes, so I can't help there. But if you expect to do a lot of that kind of work, you should ask an attorney to draft a contract for you that can be quickly tailored to different scopes of work, so that you have a standard agreement for small projects. If this is a one-off project, and you don't plan to do similar work again, an attorney may cost you as much as the job pays, so you can certainly scribble something in Word that just covers payment terms, scope of work and what path you'll take in the event of a dispute or disagreement.

By the way, your question isn't really specific to programming, it's general enough to apply to all sorts of contract deliverables. "Consult your attorney" is probably the wisest answer.


Talk to a lawyer about a contract you can modify to suit your needs. Your contract should include an appendix detailing deliverables, scope, and liability. If a lawyer is not in your price range, look for well-reviewed, simple contract templates online.

Establish a contract with the client as early as possible. You can always agree on changes later. Request an up-front percentage (client honesty) of up to 50%. If you're being paid hourly, give an estimate (your honesty) and request a percentage of the estimate. For longer-term projects, request progress payments in exchange for progress reports (mutual honesty).


Not the answer you're looking for? Browse other questions tagged or ask your own question.