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

First off, we presume that the projects in question are not large or important enough for the parties involved to establish a formal contract, and that the parties are not able to meet in person.

So, how can the programmer(s) be sure that they will be paid(in full), and how can the client be sure that the their requirements are met, e.g. testing it without acquiring the full source code?

share|improve this question

closed as off-topic by durron597, MichaelT, Snowman, gnat, GlenH7 Jul 11 '15 at 12:41

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – durron597, Community, Snowman, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

"First off, we presume that the projects in question are not large or important enough for the parties involved to establish a formal contract." Well first of, this presumption is always wrong. F**k you pay me. – user16764 May 28 '12 at 0:53
up vote 11 down vote accepted

By asking this question you are basically underlining the fact that the project in question is indeed important enough to justify a contract. Really, all projects where money is involved, and even some where it's not, need a contract.

Drafting a basic contract which covers the scope of delivery and payment is probably less work than devising and implementing some kind of questionable "safety net".

I recommend reading this 24ways article on the topic of contracts:

share|improve this answer
I am not familiar with how things work with (beginner) freelance programmers who make software on their own or in small teams, but are not registered as a company in their country. I guess another question comes to mind- does one have to start a real business (a firm) or is it enough to just put one's name on the dotted line for the contract to be valid? I ask this because establishing an international contract sounds like a real hassle, and some sort of version control software for the final transaction sounds more appealing and more feasible. Does such a thing exist? – Goran_Mandic May 27 '12 at 21:58
You would have to find out what the laws are in your country, and perhaps that of your client? As far as I know it's perfectly reasonable to make a contract between parties who can be either companies or individuals. – bernk May 27 '12 at 22:07
@Goran_Mandic: The most important thing you'll need is an actual, physical contract that names the two parties, the work to be performed, and the money paid. The reason is that when a disagreement arises, such a document can serve as the basis for legal action, but also for mediation. – MSalters May 28 '12 at 22:07

A contract is a good way to ensure you are paid. If you are concerned about payment, then why are you avoiding contracts?

By your own self-imposed limitation you must use non-legally binding agreements based off email or word-of-mouth. At least make sure there is an agreement of some sort.

For testing... Don't let them get their hands on it until they have paid. If it's a website it's already remote with the important stuff hidden away on your private server. If it's a client side, or embedded into custom hardware then make they test on-site in your office.

And the final option... make a product and sell it. No contracts, meetings, or agreements. Just sales!!!

share|improve this answer

Short answer is you can't. For small transactions, the best form of contract is a handshake and trust. Don't pay in advance, or do work in advance of payment, for more than you are prepared to loose. Make payments based on outcomes, at a granularity that reflects the risk and trust in the relationship.

A formal contract is a good way to establish "rules of engagement" (i.e. who does what for how much), and using it, enable enforcement of those rules as it is recognized under law. However contract enforcement is quite a different beast altogether. Although it's cheap to draw up a contract, it's expensive to enforce a contract using the law, even if you win, you still need to enforce the courts decisions..... Cross international boundaries, and the costs and complexity skyrockets, with little hope of any useful outcome.

As a rule, draw up a contract so you both have a clear understanding of whats expected, then put it in the bottom draw and forget about it, as needing to refer to it means the deal has gone bad. It's your very last resort when all else has failed.

share|improve this answer

A side note. Whether or not you have signed pieces of paper in any English speaking country you have a contract.

Legally a contract is implied whenever two parties agree to exchange goods or services. So you have a contract by default and the great mass of case law and precedence will apply. In general this case law favors the receiver of the goods and services over the supplier so by not having a formal agreement you will place yourself at a severe disadvantage should any dispute arise. Even a simple cut and paste "software is supplied as is and the author is not responsible for any damages resulting from the use or misuse .... " could save you from a world of grief.

share|improve this answer

You could rely on third party escrow services that hold your client's money until they approve payment.

It works by them placing the funds in the escrow account and you delivering the work. They test the deliverable and if they accept it, they release the funds from the escrow.

If they don't accept it and you need to fix some existing issues with the code, you'll have to do so and send them an update, which undergoes the same cycle.

If at any point you do not reach an agreement, due to unrealistic claims from them or from you, either party can initiate an arbitrage process with the escrow holder, in which both of you present your sides of the story and the escrow holder decides in favor of either you or the client.

In the end, this avoids having a formal contract between the two of you, but poses the risk of having the end result depend on who has the best argumentation skills, not on who's actually right.

share|improve this answer

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