Ask HN: Could you share your general purpose development contracts?
15 comments
I work on small projects (from $5k to $50k) and have no formal contracts. My thinking is that:
- the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out
- if the client has to read the detail of the contract, it's probably too late to save the relationship anyway
- maintaining the relationship is everything, being honest and open and striving to maintain a service that is genuinely useful to the client, even if you're not always perfect.
I do have a contract with one client but any questions about it have been about the 'spirit' of it, not the detail.
Pricing is everything: if you're too cheap, you'll struggle to deliver and will not meet expectations. Too much, and you'll lose out to your competitors.
- the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out
- if the client has to read the detail of the contract, it's probably too late to save the relationship anyway
- maintaining the relationship is everything, being honest and open and striving to maintain a service that is genuinely useful to the client, even if you're not always perfect.
I do have a contract with one client but any questions about it have been about the 'spirit' of it, not the detail.
Pricing is everything: if you're too cheap, you'll struggle to deliver and will not meet expectations. Too much, and you'll lose out to your competitors.
Please watch this: https://vimeo.com/22053820
That's an interesting angle that I hadn't heard before. I'd still rather have a contract, just to avoid confusion about the terms of the deal.
Good intentions, terrible advice, sorry.
Contracts are not just for 'the courts'. It is a standard business practice of having some clear terms for the both parties. Not only that, but any company who could sue and, 'wipe you out' already has their own contracts and NDAs, you not showing up with one just looks unprofessional. It should be also used as a place to outline your workflow and what the client should expect from you. Clients love this, trust me.
To tell new developers that, 'go ahead and put 5K-50K of your earnings on good faith' is just a dangerous thing to say.
Contracts are not just for 'the courts'. It is a standard business practice of having some clear terms for the both parties. Not only that, but any company who could sue and, 'wipe you out' already has their own contracts and NDAs, you not showing up with one just looks unprofessional. It should be also used as a place to outline your workflow and what the client should expect from you. Clients love this, trust me.
To tell new developers that, 'go ahead and put 5K-50K of your earnings on good faith' is just a dangerous thing to say.
This is a good idea right up until something goes wrong. The client decides not to pay you -- what do you do? The client asks for revision after revision on a flat-rate job. The client refuses to buy stock photos, or refuses to provide some essential software component. The client insists, years later, that because they changed their requirements, something you did is now a bug, and they insist you fix it for free. You write software library X for a client and then the client sues you for using it in a different project. The client asks for a change verbally, later denies making this request, and insists that you reverse it (for free). I could go on but the point is that there really are some things that aren't covered by a handshake agreement that you really should have nailed down, because you have very limited recourse otherwise.
This should include the work to be performed, payment schedule and penalties for late payments (which are generally covered by usury laws, the workaround is often to offer a discount for early payment), what copyrights are transferred and when, responsibilities for providing assets, acceptance criteria, liability for defects, severability, and controlling law. Non exclusive list written from memory, IANALATINLA.
Relationships may be important, but that does not mean automatically getting screwed if the client decides to. A well-written contract protects both parties. We need contracts because this isn't a perfect world, things go wrong all the time, and it's very easy to burn relationships unless you both agree about what to do when things go wrong, before the lawyers start getting involved. And again, if it does get to the point where the legal letters start flying, without a contract you are going to be severely limited in terms of recourse.
Another way to look at it is that without a contract, you are both taking on risk; the risk of not being paid is probably the biggest factor. If you can avoid a $5k to $50k risk by spending a few hundred dollars, why wouldn't you?
If you need more than my words to convince you, I suggest either reading clientsfromhell.net, or watching "Fuck you, pay me." http://vimeo.com/22053820
This should include the work to be performed, payment schedule and penalties for late payments (which are generally covered by usury laws, the workaround is often to offer a discount for early payment), what copyrights are transferred and when, responsibilities for providing assets, acceptance criteria, liability for defects, severability, and controlling law. Non exclusive list written from memory, IANALATINLA.
Relationships may be important, but that does not mean automatically getting screwed if the client decides to. A well-written contract protects both parties. We need contracts because this isn't a perfect world, things go wrong all the time, and it's very easy to burn relationships unless you both agree about what to do when things go wrong, before the lawyers start getting involved. And again, if it does get to the point where the legal letters start flying, without a contract you are going to be severely limited in terms of recourse.
Another way to look at it is that without a contract, you are both taking on risk; the risk of not being paid is probably the biggest factor. If you can avoid a $5k to $50k risk by spending a few hundred dollars, why wouldn't you?
If you need more than my words to convince you, I suggest either reading clientsfromhell.net, or watching "Fuck you, pay me." http://vimeo.com/22053820
A contract can limited the damage from working with a bad client, but not as much as screening out bad clients in the first place. I'm not saying that having a contract isn't better than every alternative, but it doesn't substitute for selecting good clients in the first place.
If you can see them coming, yes. There are some people that even if everything goes well it's not worth working for them. But the contract is often the difference between a disagreement that gets worked out, and a posting on Clients from Hell.
But the contract is often the difference between a disagreement that gets worked out, and a posting on Clients from Hell.
I can't think of a single case where that's been true, in either my experience or anyone else's.
The contract language comes into play when everything has already gone to hell. Yes, there needs to be a contract. But you should never assume it will give you any particular leverage over a larger, well-represented client who has elected to take an adversarial position.
I can't think of a single case where that's been true, in either my experience or anyone else's.
The contract language comes into play when everything has already gone to hell. Yes, there needs to be a contract. But you should never assume it will give you any particular leverage over a larger, well-represented client who has elected to take an adversarial position.
Argument from lack of imagination. But I don't think the the large, well-represented adversarial client is as common as the clients who are simply stupid. Either way it's not something I have a lot of personal experience with, but Clients from Hell is pretty full up with stupid, greedy clients and equally stupid designers with bad contracts. As an example:
http://clientsfromhell.net/post/107004953453/me-your-invoice...
The above is clearly a situation where contract verbiage for transfer of rights would make any subsequent conversation on the topic very short. However, as to your general point, what do you suggest? Is that risk something that can be mitigated, or priced into your rates?
The above is clearly a situation where contract verbiage for transfer of rights would make any subsequent conversation on the topic very short. However, as to your general point, what do you suggest? Is that risk something that can be mitigated, or priced into your rates?
The client conveyed their intent not to pay when they asked for the special favor. I mean the special favor was not paying when push comes to shove. In general, most people aren't sociopathic, so they have to find a way of rationalizing their bad behavior. The web designer/programmer does favors of a financial type for them and stopping the favors makes the designer/programmer the bad person.
Contracts work really well for resolving problems when the parties operate at the institutional level. The people at the school board are constrained by the institution. The corporation managing the construction is bigger than the just another project manager running the job. Individuals are limited in how badly they can get away with behaving.
There were already lawyers working for both parties before they signed the contract. Nobody has to find one just because there was disagreement.
There were already lawyers working for both parties before they signed the contract. Nobody has to find one just because there was disagreement.
Seeing them coming comes with experience. One heuristic I use is does the person try to see things from my point of view when discussing the contract. If it's a finite pie at the beginning, that's the way it will be down the road.
One of the things I've learned from Patrick Patio11 is that negotiations should be on scope not price. The implementation is that clients who expect me to deliver something they cannot afford aren't worth taking on.
One of the things I've learned from Patrick Patio11 is that negotiations should be on scope not price. The implementation is that clients who expect me to deliver something they cannot afford aren't worth taking on.
One of the advantages of a contract is that it is an opportunity to bring up potential issues before they become actual issues at that phase of a relationship where everyone is googly eyes in love.
Discussing contracts is also a good way to screen clients. It can provide a tell that allows separating people who don't sign contracts from those whose word is their bond. The latter have no trepidation entering a contract.
Discussing contracts is also a good way to screen clients. It can provide a tell that allows separating people who don't sign contracts from those whose word is their bond. The latter have no trepidation entering a contract.
Say you have the best client in the world (perhaps your own brother) and you do $5K worth of work. A few years later the company is acquired, gets all new management, and now your $5K software is supporting a $500M/year business. Some noob in IT blindly updates all the servers without testing compatibility and your software breaks.
A week later you get back from your totally offline trek through Nepal to find angry voicemails and emails from the organization now depending on your software, and you're now facing a $10M lawsuit from the new management for losses incurred due to your software breaking.
Long story short, your liability isn't limited to the relatively small amount you were paid for the work. And because you didn't have a contract, you could be held personally liable and risk losing your house, retirement savings, etc.
A week later you get back from your totally offline trek through Nepal to find angry voicemails and emails from the organization now depending on your software, and you're now facing a $10M lawsuit from the new management for losses incurred due to your software breaking.
Long story short, your liability isn't limited to the relatively small amount you were paid for the work. And because you didn't have a contract, you could be held personally liable and risk losing your house, retirement savings, etc.
Under this scenario you 1: either laugh at them or keep quiet, but have new understanding of how much the problem is worth to them, then 2: offer to fix it with a project - priced at a number that reflects both your inconvenience and their need. Whatever that price is, it will be a lot cheaper than lawyers at dawn against someone who has no ability to pay.
Meanwhile the acquiring company should have done their Due Diligence on the software and these sort of loose ends would have been tidied up or deliberately ignored as part of that process.
I do not believe in contracts for small gigs - but an email chain is good to have. If you then perform work, send invoices and they pay you there is a good enough contract in place.
This is sort of terrifying. What kind of clause prevents this potential outcome?
Not a lawyer and this isn't legal advice.
I'm fairly sure it's called a limited liability clause. They are literally everywhere. Ski resorts, adventure parks, paintball facilities, and even pools. There are many ways these are worded. Keep an eye out anytime you partake in a service/activity where there is a whiff of danger.
Edit: In terms of asset protection (losing houses and retirement) an LLC, GmbH, or Pty. Ltd. will limit loses to assets owned by the company.
Again talk to a lawyer.
I'm fairly sure it's called a limited liability clause. They are literally everywhere. Ski resorts, adventure parks, paintball facilities, and even pools. There are many ways these are worded. Keep an eye out anytime you partake in a service/activity where there is a whiff of danger.
Edit: In terms of asset protection (losing houses and retirement) an LLC, GmbH, or Pty. Ltd. will limit loses to assets owned by the company.
Again talk to a lawyer.
While it's honorable to want to keep things on a handshake-and-honor level, when things go wrong, none of that matters. In my experience, clients are impressed and more comfortable with proceeding when a written agreement is in place. The only time I've had trouble negotiating an agreement is when dealing with large mega-corporations, where I'm still able to add in notable definitions and exceptions to the work that I'm performing.
> "the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out"
Just like lines of code are not a measure of quality of software, hourly rates of attorneys are not a measure of the quality or effectiveness of their legal representation. The only time that you are on equal legal footing with a large corporation is when you're both entering the relationship. If you and a client sign an agreement defining and limiting the work and your liability, a more expensive attorney isn't magically able to rip that contract up.
> "if the client has to read the detail of the contract, it's probably too late to save the relationship anyway"
I couldn't possibly disagree more. If a client isn't willing to work with me on defining the scope of the work to be done for both of our benefits, then I have no faith that they're going to work well with me at all, on anything. For a software developer, a scope of work is also just another piece of documentation: here's what I'm building, and what it does and does not do. A client should be as eager to define that as you.
Case in point: a bank recently suffered a data breach and had to spend more than $150k to comply with its notification obligations, and the bank's insurance company sued the bank's web design firm for, as they allege, failing to do proper servicing, security updates, etc[1].
Web design firms doing ongoing security, monitoring, and maintenance is totally not the norm. Usually the design firm designs the site, either has a couple developers in-house or contracted to another company to build out the front-end and do any integration with the bank's back-end, and when it launches, all is over. But here, this small midwestern design firm with a few employees is on the hook for damages and their reputation will be destroyed.
There are many details lacking in the civil complaint in terms of what their actual responsibility was, or if there even was an agreement in place. But if the design firm had a master services agreement that (a) disclaimed responsibility for doing security monitoring, updates, malware fixes, backups, contingency planning, and any costs or lost business as a result; and (b) limited liability to the amount of money the bank paid the design firm (a common business practice); and (c) indemnified the design agency against any claims by third-parties; the complaint probably would have never been filed.
None of this is legal advice, but don't risk having your reputation destroyed and being personally bankrupted simply because you're desperate for work, lazy, or unrealistically optimistic about people having good faith in all situations.
[1] Article with linked PDF civil complaint: http://www.scmagazine.com/travelers-accuses-web-firm-of-shod...
> "the client can afford more expensive lawyers than I can, so regardless of the truth they would be able to wipe me out"
Just like lines of code are not a measure of quality of software, hourly rates of attorneys are not a measure of the quality or effectiveness of their legal representation. The only time that you are on equal legal footing with a large corporation is when you're both entering the relationship. If you and a client sign an agreement defining and limiting the work and your liability, a more expensive attorney isn't magically able to rip that contract up.
> "if the client has to read the detail of the contract, it's probably too late to save the relationship anyway"
I couldn't possibly disagree more. If a client isn't willing to work with me on defining the scope of the work to be done for both of our benefits, then I have no faith that they're going to work well with me at all, on anything. For a software developer, a scope of work is also just another piece of documentation: here's what I'm building, and what it does and does not do. A client should be as eager to define that as you.
Case in point: a bank recently suffered a data breach and had to spend more than $150k to comply with its notification obligations, and the bank's insurance company sued the bank's web design firm for, as they allege, failing to do proper servicing, security updates, etc[1].
Web design firms doing ongoing security, monitoring, and maintenance is totally not the norm. Usually the design firm designs the site, either has a couple developers in-house or contracted to another company to build out the front-end and do any integration with the bank's back-end, and when it launches, all is over. But here, this small midwestern design firm with a few employees is on the hook for damages and their reputation will be destroyed.
There are many details lacking in the civil complaint in terms of what their actual responsibility was, or if there even was an agreement in place. But if the design firm had a master services agreement that (a) disclaimed responsibility for doing security monitoring, updates, malware fixes, backups, contingency planning, and any costs or lost business as a result; and (b) limited liability to the amount of money the bank paid the design firm (a common business practice); and (c) indemnified the design agency against any claims by third-parties; the complaint probably would have never been filed.
None of this is legal advice, but don't risk having your reputation destroyed and being personally bankrupted simply because you're desperate for work, lazy, or unrealistically optimistic about people having good faith in all situations.
[1] Article with linked PDF civil complaint: http://www.scmagazine.com/travelers-accuses-web-firm-of-shod...
You realize business liability or professional liability insurance covers being sued (and legal costs) right? You're not giving a future lawyer much help to run a business with no contracts. That's nuts.
Everyone who releases open source code uses contracts, which all limit liability. Contracts are hardly something just for rich folk.
Everyone who releases open source code uses contracts, which all limit liability. Contracts are hardly something just for rich folk.
https://github.com/cweagans/Contract
Fork and modify. I accept PRs too ;)
Fork and modify. I accept PRs too ;)
These days, I usually have a recorded sit-down (in person or over the phone) and discuss very specific details with the client and inform them that this recorded conversation will be the basis for the beginning of an agreement.
We then share the recordings with them, along with a written summary of the agreement.
Fortunately we've never had to go to court, but I'm told by my lawyers that this will hold up just fine. It also seems to breed a more organic agreement than a sterile, boilerplate contract.
We then share the recordings with them, along with a written summary of the agreement.
Fortunately we've never had to go to court, but I'm told by my lawyers that this will hold up just fine. It also seems to breed a more organic agreement than a sterile, boilerplate contract.
That's very interesting. Are your clients typically open to this, or do you run into any resistance?
I haven't yet, but some clients come to me with a contract in hand instead of doing a recording - I surmise these are the ones that are likely to object and I don't usually even ask.
Typically, I'll still sign their boilerplate, but I ask that things like NDA, work-for-hire, and non-compete are either eliminated or toned down such as to still clearly permit unmitigated action in the open source space.
The last time I did a "recorded contract" was over a year ago, which makes me now feel sheepish about saying "these days." :-)
I don't think it will be the last though, and I do highly recommend it.
Typically, I'll still sign their boilerplate, but I ask that things like NDA, work-for-hire, and non-compete are either eliminated or toned down such as to still clearly permit unmitigated action in the open source space.
The last time I did a "recorded contract" was over a year ago, which makes me now feel sheepish about saying "these days." :-)
I don't think it will be the last though, and I do highly recommend it.
Yes, this sounds like a good idea
Someone might have an objection to a boilerplate contract and this is always too much of a coming/going between lawyers of both parts.
With a personal discussion you can get whatever interests each part and get to an agreement faster.
Someone might have an objection to a boilerplate contract and this is always too much of a coming/going between lawyers of both parts.
With a personal discussion you can get whatever interests each part and get to an agreement faster.
Have you tried Docracy? There are a few good examples at:
https://www.docracy.com/application/dochome
https://www.docracy.com/application/dochome
This one is really cool http://tri.be/update-the-shane-peter-inc-contract/
You should try Shake!
http://www.shakelaw.com/legal-info/freelancehire-agreements/
http://www.shakelaw.com/legal-info/freelancehire-agreements/
These served me well when I owned a consultancy: http://msabundle.com
I've also used these quite a bit. They are sufficient for about 50% of clients. The other want to use their boilerplate.
I use a modified version of Ross Kimbarovsky's Contract from: http://www.crowdspring.com/contracts-for-software-and-websit...
Caveat: I've only used it with one client, with whom I have a prior working relationship.
Caveat: I've only used it with one client, with whom I have a prior working relationship.
[deleted]
[IANAL]
I come from a field, AEC, which in the US uses a lot of standard contracts. The AIA contracts, though not the only option, are very common and have been developed over the course of 100 years.
The architecture series start with B. These are, in my opinion, a good model for a software consulting project because:
+ Neither party really knows the full scope of the work when the contract is let. As my mentor Ronn Ginn told me, two people sit down and sign onto something about which neither has much of a clue. This of course emphasizes that an agreement is really a matter of trust not which court to go to.
+ Client objectives change during the process. The contract reflects it.
+ Intellectual property rights are clear. The architect retains the copyright. The client is granted license to use it for the purpose of the project. The license is predicated on payment.
+ Terminating the contract for convenience is a distinct possibility. The contract acknowledges that.
+ One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.
+ Both parties are likely to contract with others during the course of the project [architect with consultants, owner with builders]. The contract acknowledges that and one of the reasons for using standard contracts is because they all fit together. But that's too much to hope for here. The idea of acknowledging the possibility of other contracts and taking them into account is what matters.
The short form agreement, AIA B105 currently, B155 previously, is a good place to start. Both use simple plain language and cover most projects.
Having written a lot of proposals and contracts over the years, I've learned that selecting clients matters more than what's in the contract. Red flags really are red flags.
Good luck.
I come from a field, AEC, which in the US uses a lot of standard contracts. The AIA contracts, though not the only option, are very common and have been developed over the course of 100 years.
The architecture series start with B. These are, in my opinion, a good model for a software consulting project because:
+ Neither party really knows the full scope of the work when the contract is let. As my mentor Ronn Ginn told me, two people sit down and sign onto something about which neither has much of a clue. This of course emphasizes that an agreement is really a matter of trust not which court to go to.
+ Client objectives change during the process. The contract reflects it.
+ Intellectual property rights are clear. The architect retains the copyright. The client is granted license to use it for the purpose of the project. The license is predicated on payment.
+ Terminating the contract for convenience is a distinct possibility. The contract acknowledges that.
+ One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.
+ Both parties are likely to contract with others during the course of the project [architect with consultants, owner with builders]. The contract acknowledges that and one of the reasons for using standard contracts is because they all fit together. But that's too much to hope for here. The idea of acknowledging the possibility of other contracts and taking them into account is what matters.
The short form agreement, AIA B105 currently, B155 previously, is a good place to start. Both use simple plain language and cover most projects.
Having written a lot of proposals and contracts over the years, I've learned that selecting clients matters more than what's in the contract. Red flags really are red flags.
Good luck.
I don't know what these acronyms mean, but I'd hate NOT being assigned full intellectual property rights, as a client hiring a freelancer.
Is that really common in your field? What's your field's price tag between doing full IP assignment vs. a license-only?
Is that really common in your field? What's your field's price tag between doing full IP assignment vs. a license-only?
AEC = Architecture, Engineering, Construction
AIA = American Institute of Architects
Assigning copyright in the US AEC industry carries additional complexity since architects and many of their consultants are licensed professionals and therefore are professionally liable for their designs. Part of the responsibility that comes with licensure is maintaining professional control of the design. By assigning copyright the architect and their consultants might maintain liability for its execution in contexts of which they are unaware, e.g. where soil conditions or sesmic loads differ from those on the site for which the building was designed. Legally architects cannot reassign their professional responsibility...that's what makes it professional.
An analogy in software might be Software as Service in particular and licensing in general. The Software industry already has retention of copyright as the common mode of agreement.
Going further, full assignment of copyright to the client just turns the problem around. If I assign the copyright to the design to a client, I need to obtain a license back in order to use similar parts and pieces in other projects, e.g. a detail for a door jamb or the profile and reinforcing of a footing or more directly the "drawings" that show them. Likewise a software engineer needs to be able to reuse foreach foo in bar without consulting a lawyer.
While there are exceptions, it's simply easier to negotiate a useful set of licenses without transfer of copyright than to include that in the negotiation. Functionally, if the client can do anything with the work except reassign copyright the vast majority of cases are well served.
The price of full assignment? The question correlates to a Kremlin on May Day with Brezhnev in the reviewing stand parade of red flags. Screening clients is critical.
AEC usually means Architecture, Engineering, Construction.
I usually take it to mean the process of building buildings and making sure they won't fall down, but that may be oversimplified from someone who actually works in that industry.
I usually take it to mean the process of building buildings and making sure they won't fall down, but that may be oversimplified from someone who actually works in that industry.
Work for hire does not generally apply to freelancers. Please see here for details:
http://www.copylaw.com/new_articles/wfh.html
If you create basic CRUD apps it is probably not so common.
But for anything more advanced it would be wise to have the option of using the software in other projects to save time and money.
But for anything more advanced it would be wise to have the option of using the software in other projects to save time and money.
The option for reuse applies to both parties. Someone has to license use from the copyright holder with or without a transfer. In the case of software, the transfer is just an additional complication, by which I mean that the copyright to a Rails app is complicated by the license stack of Rails and the backend and other pieces. There's lots of pieces that the programmer doesn't hold copyright and therefore cannot assign it.
Indeed, but that sentence applies equally to either side of the contract!
Which is why I wonder what the "accepted standard" & "cost of giving up IP" is. I assume it varies greatly across domains -- OP's is "web development".
Which is why I wonder what the "accepted standard" & "cost of giving up IP" is. I assume it varies greatly across domains -- OP's is "web development".
> + One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.
I love this one. Anyone have ideas on how to apply this to software development? I really hate it when clients say "I want X" and I have to take an inordinate amount of time telling them why X is a very bad idea both in terms of effort and value. Generally this is during scoping so I have no way of billing for the time.
I love this one. Anyone have ideas on how to apply this to software development? I really hate it when clients say "I want X" and I have to take an inordinate amount of time telling them why X is a very bad idea both in terms of effort and value. Generally this is during scoping so I have no way of billing for the time.
The consensus seems to be "telling them why something is a bad idea at length is part of the job" and "doing it the stupid way at additional cost, because they insisted, is part of the job."
But I think we can go too far emphasizing pleasing the client sometimes. I don't think it's so rare to see genuine conflicts of interest, like squeezing for unreasonable deadlines and scopes, where the problem can't really be solved by just charging more.
If a client makes overly aggressive demands and won't listen when you take the time to tell them politely what you can do, is it better to be exploited mercilessly and risk breach of contract, or to cut your losses, swallow your pride and find another way to pay the rent?
But I think we can go too far emphasizing pleasing the client sometimes. I don't think it's so rare to see genuine conflicts of interest, like squeezing for unreasonable deadlines and scopes, where the problem can't really be solved by just charging more.
If a client makes overly aggressive demands and won't listen when you take the time to tell them politely what you can do, is it better to be exploited mercilessly and risk breach of contract, or to cut your losses, swallow your pride and find another way to pay the rent?
The best way to convince a client they are making a mistake is to do it the way they asked and do it the way you think is better and then show them both. Sometimes the client sees their error. Other times it turns out that the client has an unarticulated need that gets teased out and the final design incorporates both the ideas of the designer and the unarticulated need.
It's important to realize, that often the client is more experienced with their requirements, i.e. the business domain. And their understanding may be sophisticated in ways that are contrary to the naive take of an outsider.
It's important to realize, that often the client is more experienced with their requirements, i.e. the business domain. And their understanding may be sophisticated in ways that are contrary to the naive take of an outsider.
Be professional. Part of that means knowing how to produce reasonable estimates. That requires having a plausible roadmap at the start.
In some ways, software will always be harder because the artifact in a construction project is the building not "the blueprints". If the design is dragged out, the building doesn't get built.
On the other hand, the way an architect handles "I want X" is by showing them that it is a bad idea. Showing means providing a design that incorporates "X" and one without. The assumption that everything will be done multiple times before it is right, and indeed that doing it multiple times makes it better, is what separates architecture from engineering in AEC.
Understanding that doing things multiple times is just part of the job and that falling in love with one's own ideas is a bad habit can be learned. It ain't easy. But in the end, the architect walks away and the client lives in the building. Software is similar in that way.
In some ways, software will always be harder because the artifact in a construction project is the building not "the blueprints". If the design is dragged out, the building doesn't get built.
On the other hand, the way an architect handles "I want X" is by showing them that it is a bad idea. Showing means providing a design that incorporates "X" and one without. The assumption that everything will be done multiple times before it is right, and indeed that doing it multiple times makes it better, is what separates architecture from engineering in AEC.
Understanding that doing things multiple times is just part of the job and that falling in love with one's own ideas is a bad habit can be learned. It ain't easy. But in the end, the architect walks away and the client lives in the building. Software is similar in that way.
what you call "scoping", beyond high-level goals (< 1 hr to explain) you should refer to as "development of detailed requirements and specifications", and should be charged for by the hour just like coding.
Your ability to tease out what really needs to be done from a customer's hand-waving wishlist of vague features is a key component of what you are being hired for. That skill is worth more in general than straight coding, and should be compensated accordingly.
Your ability to tease out what really needs to be done from a customer's hand-waving wishlist of vague features is a key component of what you are being hired for. That skill is worth more in general than straight coding, and should be compensated accordingly.
The ones I use are on the sidebar of my blog; which I posted in conjunction with an article I wrote ( Deconstructing the Consulting Contract ) for a print publication called Fusion Authority Quarterly Update (FAQU):
http://www.jeffryhouser.com/download.cfm/dir/software/file/c... . I do not know if the article is still available anywhere; it is from 2005. [Maybe I should update said documents; but primarily very little has changed]
Bigger clients will have their own contracts [and sometimes very little negotiation room]. I've drive some clients crazy w/ negotiations and about what rights I refuse to sign away.
Update: Here is the original article I wrote http://www.jeffryhouser.com/enclosures/DeconstructingConsult... [I guess it was 2007; not 2005]
http://www.jeffryhouser.com/download.cfm/dir/software/file/c... . I do not know if the article is still available anywhere; it is from 2005. [Maybe I should update said documents; but primarily very little has changed]
Bigger clients will have their own contracts [and sometimes very little negotiation room]. I've drive some clients crazy w/ negotiations and about what rights I refuse to sign away.
Update: Here is the original article I wrote http://www.jeffryhouser.com/enclosures/DeconstructingConsult... [I guess it was 2007; not 2005]
What rights do they ask for that you refuse to give away?
Some of it is covered in the article; for example I once had a prospect want me to sign a web dev firm want a non-complete which said I wouldn't work in any industry they work in. I believe every client I've had before / after would classify. I'm not going to sign away my right to take on clients.
I've seen IP ownership clauses that say the client owns everything I create, whether or not it was done for them. These clauses are written in such a way that the client could claim ownership of work I did for other clients, my blog posts, podcasts, books I've written, and even things that have nothing to do with tech, such as songs I've written and/or recorded.
I try to make such IP transfer clauses as specific to the work I do for the client as possible.
I've seen IP ownership clauses that say the client owns everything I create, whether or not it was done for them. These clauses are written in such a way that the client could claim ownership of work I did for other clients, my blog posts, podcasts, books I've written, and even things that have nothing to do with tech, such as songs I've written and/or recorded.
I try to make such IP transfer clauses as specific to the work I do for the client as possible.
Here's what I used last time:
https://gist.github.com/malarkey/4031110
I like the plain language of it. For me, contracts are a necessity. The way I see it is that people who want to not pay, won't pay. You'd need an army of lawyers to craft a bulletproof general purpose contract. Instead, I go by a mutual understanding sealed by a simple contract.
From what I understand, the best tool/weapon you have is a clause that says that copyright assignment from you to them happens upon receipt of full payment. That way you hold their work until you get paid. YMMV and IANAL.
https://gist.github.com/malarkey/4031110
I like the plain language of it. For me, contracts are a necessity. The way I see it is that people who want to not pay, won't pay. You'd need an army of lawyers to craft a bulletproof general purpose contract. Instead, I go by a mutual understanding sealed by a simple contract.
From what I understand, the best tool/weapon you have is a clause that says that copyright assignment from you to them happens upon receipt of full payment. That way you hold their work until you get paid. YMMV and IANAL.
I also use Killer Contract, slightly tweaked of course. It's simple, understandable and gives me some leverage when clients don't pay, which happens a lot more often that i would like.
[IANAL]
Been using this one for a few years, wrote it with some mates, never had any issues. Attached some design images as well as the text.
http://teamgoblin.com/contract.html
Been using this one for a few years, wrote it with some mates, never had any issues. Attached some design images as well as the text.
http://teamgoblin.com/contract.html
Myself and a number of others have used this generic development and design contract: https://github.com/danielbeardsley/service_contracts
I negotiate the terms, make local commits, and include the commit hash on the print-out.
I negotiate the terms, make local commits, and include the commit hash on the print-out.
Whenever possible, I try to strike Agile Contracts where the client is given control ONE of three levers: The Scope lever (how much will be done). The Time lever (how much time will be spent). The Money lever (how much will the client spend). If you try to give your client more than one of these levers, you're fooling yourselves, because it isn't really possible. Some aspect of the project will suffer in a way that violates the basis of a good business relationship and / or a good outcome.
More information on Agile Contracts:
http://www.agilecontracts.org/
More information on Agile Contracts:
http://www.agilecontracts.org/
[deleted]
I understand that I/WANAL & YMMV etc. but it would be nice to see what people are using themselves.