The Ruby Freelancers Show 049 – Contracts with Attorney Jared Richards

Download MP3

Panel Jared Richards (twitter 801-438-2040) Eric Davis (twitter github blog) Evan Light (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 01:21 - Attorney Jared Richards Introduction Bennett-Tueller Johnson & Deere of Salt Lake City, UT @UTStartupLawyer 03:37 - Things you should have in a contract Who owns what Work for hire/licensing 10:40 - Prospective Liability and Disclaimers of Liability 13:07 - Risk Management Tools Warranty and protection against data loss Limitations on liability 16:25 - Copyright & Patent Infringement 19:57 - Getting paid for your work Cash up front On-going retainers Escrows Credit card authorization forms Interest penalties Collection costs 29:18 - Acceptance and Rejection Procedures 36:25 - Is a Statement of Work necessary? 40:20 - Subcontracting 42:25 - Client turnaround and response time provisions 43:24 - Purchasing of services/expenses 46:21 - Using client contracts instead of your own Jurisdiction Indemnificaton Liquidated Damages Provision 52:20 - Conflicts of interest 58:56 - Arbitration, Mediation & Litigation 01:05:05 - Subcontractor Agreements Insurance Regular reporting Picks Growing Developers - Curated Conversation About Building Developer Talent (Evan) Mastery: The Keys to Success and Long-Term Fulfillment by George Burr Leonard (Evan) Exercise (Evan) Take Time Off Work (Eric) Breathe (Eric) Fire Up Ember.js | PeepCode (Chuck) Meet Chef (Part 2 of 2) | PeepCode (Chuck) Google Advanced Search (Jared) Next Week Better Prospecting for Freelancers with Steve Kloyda Transcript JARED: I prefer keep away from the attorney jokes. They get told behind my back, I don't really get to hear them in person. [Are you a busy Ruby developer who wants to take their freelance business to the next level? Interested in working smarter not harder? Then check out the upcoming book “Next Level Freelancing - Developer Edition Practical Steps to Work Less, Travel and Make More Money”. It includes interviews and case studies with successful freelancers, who have made a killing by expanding their consultancy, develop passive income through informational products, build successful SaaS products, and become rockstar consultants making a minimum of $200/hour. There are all kinds of practical steps on getting started and if you sign up now, you’ll get 50% off when it’s released. You can find it at][hosting and bandwidth provided by the blue box group. check them out at] CHUCK: Hey everybody and welcome to The Ruby Freelancers Show, Episode 49. This week we're going to be talking to Jared Richards, he's an attorney, about contracts. Before we get started, let's introduce the panel. This week on our panel, we have Eric Davis. ERIC: Hello! CHUCK: Evan Light. EVAN: I'm back! CHUCK: I'm Charles Max Wood from This week we have a special guest, as I said before, Jared Richards. JARED: Hey everyone! CHUCK: Jared, you want to introduce yourself really quickly so people can know who you are and how to find you? JARED: Yeah absolutely. Jared Richards, I'm with the law firm in Salt Lake City, Utah called Bennett-Tueller Johnson and Deere, more casually known as BTJD. We have a large corporate practice and a lot of our group focuses on startups, more specifically technology startups. So we handle wide array of things from IP protection, contracts, venture capital, and sales of businesses. That's where we spend all our time, and thanks for having me on the show. You can find me on Twitter @UTStartupLawyer. CHUCK: Yeah. So I met Jared a year or so ago...nah! I think it was longer than that. Anyway -- JARED: Yeah I think it's been a couple of years, yeah. CHUCK: Yeah, it was at launch up,


JARED: I prefer keep away from the attorney jokes. They get told behind my back, I don't really get to hear them in person. [Are you a busy Ruby developer who wants to take their freelance business to the next level? Interested in working smarter not harder? Then check out the upcoming book “Next Level Freelancing - Developer Edition Practical Steps to Work Less, Travel and Make More Money”. It includes interviews and case studies with successful freelancers, who have made a killing by expanding their consultancy, develop passive income through informational products, build successful SaaS products, and become rockstar consultants making a minimum of $200/hour. There are all kinds of practical steps on getting started and if you sign up now, you’ll get 50% off when it’s released. You can find it at] [Hosting and bandwidth provided by the Blue Box Group. Check them out at] CHUCK: Hey everybody and welcome to The Ruby Freelancers Show, Episode 49. This week we're going to be talking to Jared Richards, he's an attorney, about contracts. Before we get started, let's introduce the panel. This week on our panel, we have Eric Davis. ERIC: Hello! CHUCK: Evan Light. EVAN: I'm back! CHUCK: I'm Charles Max Wood from This week we have a special guest, as I said before, Jared Richards. JARED: Hey everyone! CHUCK: Jared, you want to introduce yourself really quickly so people can know who you are and how to find you? JARED: Yeah absolutely. Jared Richards, I'm with the law firm in Salt Lake City, Utah called Bennett-Tueller Johnson and Deere, more casually known as BTJD. We have a large corporate practice and a lot of our group focuses on startups, more specifically technology startups. So we handle wide array of things from IP protection, contracts, venture capital, and sales of businesses. That's where we spend all our time, and thanks for having me on the show. You can find me on Twitter @UTStartupLawyer. CHUCK: Yeah. So I met Jared a year or so ago...nah! I think it was longer than that. Anyway -- JARED: Yeah I think it's been a couple of years, yeah. CHUCK: Yeah, it was at launch up, which is kind of a social gathering where they usually have a couple of companies that are kind of just startups that are talking about what they do. And they have somebody who's experienced in building a business, or in some aspect of building a business, come in, and kind of do a quick explanation of some of the stuff that you want to do with building your business. Anyway, they're usually pretty good, pretty interesting. I haven't been for a while, though. Are they still doing them? JARED: Yeah. The first Thursday of every month, we have between 85 and 200 people show up, and it's a good event. CHUCK: Yeah. That's why I haven't going; it conflicts with the Utah JS, Utah JavaScript group. JARED: Got you! CHUCK: So I have to pick. But, they're a lot of fun, really great. Anyway, so I was talking to Jared at one point and I asked him about contracts for sub-contractors and he gave me kind of a template 1. And then I actually hired him to take some of the non-competitive language out of it because a lot of my sub-contractors are also my competitors. The language in there would have basically allowed me to push them out of the space, which isn't my intention. JARED: [on the background] Yeah that was not your fault. CHUCK: So it just put some "definitive" in the sense of "if you steal the client that you've been working for for me -- if I introduced you to one of my clients and you steal them, then you're in trouble", was the gist that I wanted. Let's talk though real quickly about the contracts that we have with our clients. Are there specific things that people tend to leave out of their contracts? Or put into their contracts that'll get them in trouble? JARED: I guess the first thing in the contracts with your client -- the first thing to understand obviously is "who owns what". I think that's going to be the most important thing. From a developer stand point, there's kind of this "pre-existing IP concept". You all have your own bags of tricks that you probably incorporate into multiple different projects. And depending on the client, you're going to have some who make the large, be amiss, large corporations who are going to insist that they own the code that you're writing for them. And the big thing there that you want to make certain that you have is at least the carvel that allows you to retain all the bag of tricks that you used across all of your clients - that pre-existing IP. So that's definitely something to be aware of because it would be a real shame; and I'm sure that there are many people who done it unintentionally and unknowingly. Maybe it won't come back to bite them, but it certainly could. And they may have assigned certain parts of that toolbox over to a client unknowingly, and they may be using it for other clients now in violation; and essentially, breaching the copyright of the client that owns that code now. I think that would be kind of the first heads up that I would certainly be aware of. CHUCK: So how do you differentiate that? JARED: The way that it typically done is "just try to finding pre-existing intellectual property". So you could say "Hey, yes I maybe building this for you, this maybe work-for-hire, and everything I do specifically for you, maybe owned by you once I deliver it to you. However, I'm retaining all rights in my pre-existing intellectual property". And you can have it broad and vague so that could mean "all intellectual property that you created prior to the date that you began working on this project for the client". Or you could specifically enumerate it if there's a tool that's going to have main stage in this client's project, but it also may play main stage in other client project. You may specifically call it out and say "Not only that IP that I've created prior today, but specifically this thing". Specificity always goes to reduce uncertainty. So if it's really important, it doesn't hurt to write an extra couple of lines in the contract to make it clear so that there's no doubt as to what you own. I don't know what you guys find as most typical in those hiring Ruby guys, whether it is a work-for-hire of assignment where the client owns everything at the end, or if the client receives just some kind of a long-term license and you retain rights to all your codes. What have you guys found as most common for you? EVAN: Usually work-for-hire. ERIC: Yeah. EVAN: For me, it's mostly licensing. JARED: Is it? CHUCK: In my contract, it says that they got a perpetual license to the code that I wrote for them. And that they can modify it however they need to, obviously, for their business needs. But I think I retain ownership. EVAN: That doesn't seem to flies for me with a lot of startups because the startups often want to bank on owning the IP. So that way, when they invariably go about trying to flip, they can say that it's their IP exclusively and it makes it easier for them to sell. [crosstalk] license, then it's different. ERIC: For me, it's different. Because most of the work I was doing was on GPL code, so it's open source that uses GPL code; (it) has to be released as GPL. So most of that time, I was giving them a license even though in theory, they would have a GPL license by default. JARED: Yeah. Now that makes sense. CHUCK: I think my contract says the license thing by default. I mean if they read the contract and that doesn't work for them, I'm totally fine assigning ownership to them. JARED: Yeah. And from a developer perspective, I would always suggest and lead with the "non-work-for-hire license arrangement" that you guys mentioned, specifically "Hey, you get a license to use this; you can modify it, you can do whatever you need with it. But I retain the rights to use all or any portion of this in another project". You built that code base, you know exactly what it is, and obviously, that can be ride you great shortcuts in other projects. ERIC: One thing pulled up my contract, my attorney broke it down into 4 different things. I have like client materials, which is like stuff that client gives me. So basically, the client is giving me a license to use the stuff they give me like images or PS or stuff like that. Then there's the work product which is the actual custom thing I'm building for them. But then they're also call it out general purpose libraries, which in the Ruby world, would be like gems or kind of comment code that developer share across projects. And then I also have third-party materials, which kind of -- it looks like it includes general purpose libraries, but it's a bit more broader in like somewhat use like bootstrap, and bootstrap has like images and stuff that might not fall under a library. But it basically separated us up because he's like "you do a lot of open source stuff; you have a lot of GPL licensing so let's grip it out like this", and this isn't in my master services agreement. And then in my statement of work, it say like "Okay, for this one we're going to use these general purpose libraries. I have this existing code that is my stuff", and I basically kind of slop things into one of those [inaudible], "Here's how the licensing and how the ownership's going to end up of the project". JARED: And that's a great way to do it, not only fo you, but also for the client in the end. Often these startups when they go through any kind of due diligence for financing or any kind of sale, one of the questions that they're going to dive into is the intellectual property. They're going to dive into the code, they're going to be asking questions about what other open source licenses that their software is subject to. And if you've already got it broken out like that, it really simplifies and helps them complete that due diligence. It makes their lives a lot easier and they don't look stupid in front of the investor or the prospective buyer when they say "Oh no, we own all this code". Only then when the due diligence gets going and they look and they see all these open source libraries, they don't look like idiots. CHUCK: Yup. Are there any other things that come into the contracts that we need to have in there to protect ourselves other than the IP issues? JARED: Yeah. The other issues that I'd be most concerned about is "perspective liability" and "disclaimers of liability". CHUCK: You just do some big words and I'd just crossed my eyes on what -- JARED: No, no, no... CHUCK: Come on! ERIC: That's the part that's like in all caps and it's the same thing in every contract. CHUCK: Right. JARED: That's right. That's right. EVAN: It's pretty much just as provided as "is no warranty" blah, blah, blah. JARED: You've got it! Sometimes, you may have more sophisticated clients. You're going to require some representations or some assurances are guarantees from you that the code is going to do specific things, but that obviously should not be your default as a coder. As a developer, you're going to want to -- when you build out your statement of work, when you draft those specifications, probably the most aggressive representation that I would want to make as a developer would be something along the lines of "when I deliver this code to you, it'll reasonably comply with this specifications that we've agreed upon and that it'll perform reasonably free from bugs and errors for a certain period of time because we don't know how the infrastructure outside libraries, outside frameworks, browsers; other things might change which might affect the way the performance of the software that we wrote (and) all those might affect the project". So if they're asking you to make specific representations that it does XY and Z and it will always do that, that should be a red flag that either you need to charge a lot more for it and essentially self-insure against possible outcomes, or you shift the liability back to them by doing exactly what was said. You have the all caps, this is as is, "Once I give it to you, you got a chance to review it. If you think it complies and you accept it, then I'm off the hook. It's in your corp if you want to hire me to do additional work on it in the future, great you can do that. But now it's yours and your problem, and you assume any risk and liability associated with it". So, including that would be important and necessary, otherwise they may have some implied warranties. So if they're not stated then that they have some implied warranties, that could come back to bite you. ERIC: Looking at mine also, one thing that I never thought about is also kind of warranty and protection against data loss. Like if you write code that accidentally deletes data, who's fault is that? In my contract it says "it's the client's responsibility to protect against data loss, have backups", all that stuff. But I never thought about that until my attorney brought it up and called it out. JARED: Absolutely. That's a great provision to include in there as well. Other risk management tools that can be included, generally you'll find these below the all caps disclaimers of warranties, would be "limitations on liability". Talking about data loss -- I mean now we're talking about big money. If we're writing something for a large company and we've got millions of users or significant amount of data, and our tool all of a sudden even though we were paid $50,000 or $150,000 to develop this, if all of a sudden our work is responsible for deleting loads and loads of data or corrupting data and the value of that data is in millions of millions of dollars, we want to be protected so that we're not going to be liable and responsible for that. And so we can't place limitations on liability; kind of capping the amounts that a client could come back against you for in the KC - your software is what caused them actual or some kind of damages. CHUCK: So do you limit it by the type of problem that they have (because it sounded kind of like that's what Eric was saying)? Or do you limit it by like a dollar amount? Or both? JARED: Yeah kind of both. So the ways you can do that is: one way you can do it is by limiting the damages specifically to actual damages suffered by the client. If you have actual damages suffered by the client now, we're getting away from consequential damages; we're getting away from damages result or punitive damages. Those are the kinds of damages that can really start to add up and be of greater concern to use the potential liability bearer. The other way you can limit it is specifically by including a dollar amount. You could say "the maximum liability that I can incur arising out of the software I delivered to you is x amount of dollars". You could make it a fixed amount, you could tie it directly to the amounts they pay to you, you could tie it to some multiple of the amounts they pay to you. But if you have insurance and you understand the policy limitations of that insurance, then tying that limitation on liability to somewhere under your insurance maximums, (then) that's a good way to do it to make sure that you're not going to exposed personally or your business beyond the maximum limits on your insurance policy. ERIC: Yeah. Mine has a clause that basically limits my liability to the amount in the fees. So if it's a $50,000 project, like that's my liability for negligence or any of that stuff. JARED: Yeah absolutely. And that's probably most common, limiting it to the contract amount. Another kind of scary one often for clients and one that you may have them push back on is you maybe super transparent with the client, but they don't know what they don't know. And one of those larger liability issues can come in the form of copyright or patent infringement. So they may ask you for a representation that the code that you're delivering to them does not infringe upon any intellectual property rights of the third-party. And sometimes, because we see that representation so often, it may be like "oh, that's just a broiler plate representation that everybody agrees to", but that's one where you could be potentially exposed to some serious liability. And may we talk through those scenarios real quick: Copyright infringement is probably going to be less likely. You're only going to be subject to some copyright infringement if you've actually taken, stolen, borrowed, used code from somebody else that wasn't open source code, or under some kind of open license that you're allowed to use. And essentially, if you built something for another client, and that client you delivered the code to them under a work-for-hire, they own all that code, and then you go around and turn and use it in another client project, there's a possibility that that former client could come after the new client for infringement because there's duplicate code that they now own. That's going to be probably a more limited narrow case scenario. We see those come up often with kind of former-employee-type situations; we got the employee who wrote code for company then they took their code base, separated off, built a competitor, and instead of rebuilding from the ground up, they took some of that proprietary code from their employer, and then there could be some copyright issues. The other kind of less certain risk is with respect to patent. We all know the patent system is a very slow system. Things that are issuing now are 4, 5, 6 years old when they were filed. So often, especially in this software realm, patents are often outdated, often irrelevant. But because everything is built on something from the past, often you could build something and unintentionally -- well build something the client takes it and later a patent issues a process, perhaps, that is violated by what your code now does. And so at the time you developed it without being aware of the patent, without being aware of the pending patent application I should say, you built something the client receives it and then later down the road the client gets sued for patent infringement and they turn to you and say "you made a representation and warranty to me that it wouldn't infringe upon anybody else's intellectual property rights". And because patent operates in that slow manner, and because it takes so long to come out, and because they can get patents issued on stuff even if you independently developed it, if it was after the date that they filed their application, it could be problematic. So I guess that's a long way of going about to say "be careful about your representations and warranties about the code not infringing upon third-party's rights even though you're the only one who ever touched that code". CHUCK: That makes sense. So I want to change tactics a little bit because there are other parts of the contract that I think are important. For example, the whole part about you getting paid for your work, how do you write that without putting loop holes in it? JARED: Getting paid is like the old saying "A bird (in the) hand is worth more than two in the bush", right? And so, if you could swing it, retain of agreements are obviously better than invoicing a client. Obviously you can't always have that - having a substantial portion of the project paid upfront. Any methods that you can employ to get cash upfront are always going to be better - giving a discount off the project by paying a substantial portion upfront. CHUCK: I thought about that. That's an interesting -- JARED: Those are not legal concepts. But just from a practical stand point, if you can get paid upfront and you don't have to worry about the headache of collecting on the project later, I mean you're going to save yourself so much time and headache and -- EVAN: Remember how Evan Palmer always saying "at the very least, collect a deposit upfront", not entirely dissimilar if it's going to be a long-term project. JARED: Yeah absolutely. EVAN: Just like you're saying, it's a risk mitigation. So just in case they don't pay you, you can part ways with them and you still at least get paid for the period that they gave with the deposit and ideally, you haven't lost any round. CHUCK: Yeah. It's not a new concept, either. I mean my Dad's a dentist and he offers a cash discount. So if you've given cash when the service is performed, do you like 10% off. And it's because then he doesn't have to worry about collecting - you're paid up. JARED: That's right. EVAN: Well, sure! I mean it's really not all that different in terms of comparison. I don't remember exactly where I got the idea from, sure I wouldn't know because you see it all the time with apartment rentals. There's security deposits in case you run wild on the apartment, then they already have some money from you that they're not going to get back in order to do repairs. In this case, it's essentially the same thing that is that they don't pay you so they do damage to your relationship, and you can walk away and you still have that deposit. JARED: Yeah. And I know quite a few development shops that do require an ongoing retainer. So even though the project, maybe a $100,000 project, they say "That's going to be a 9 months project, we know what our monthly expenses most likely are going to be. So we want a $7,000 retainer". So it's kind of like that deposit, and they say "You're going to put that $7,000 here, it's not ours yet, but as we do work we get to draw from that. We'll send you an invoice detailing our time, detailing our progress doing whatever we do with from a project manager stand point. And then if there's no undisputed charges listed on the invoice, we get to draw against that $7,000, take our payment", and then the client pays in that same amount back into the retainer so now there's still that $7,000 retainer sitting there and I got paid. EVAN: Is that only retainer? Or is that an escrow? JARED: Well a retainer/escrow. You can call it that; it's probably just semantics there. You can call it escrow -- EVAN: So it's a matter of "who holds the money", is what I'm getting at. JARED: Yeah. Again, you could hold the money; the way that you usually do it is not to put it in your operating account. You could set up a new account with your bank, and it could be specifically for holding client escrow funds. Right? So it's funds that are still technically the client's, but you get to unilaterally draw from after you've issued an invoice and there's no disputed matters on the invoice. So that gives you an easier way to draw. That was very popular in the pre-electronic payments era. The other way you can do is have a pre-authorized ACH authorization or credit card authorization. We build that into even from our perspective. All of my client engagements as an attorney, I include (if you have not paid) a pre-authorization for collection via credit card. So you put a credit card number in there, you've authorized me to draw from it IF after I've send you an invoice, if you haven't paid within the net 30, net 45 terms that we've agreed upon, then you've authorized me to go ahead and deem your credit card for the outstanding amounts owed. It's really interesting, contracts do affect behavior. Maybe I'm revealing a little too much, (I) hope that none of my clients are listening here, but just by merely including it on your contract, having the authorization form there, people think that they have to fill it out. They don't think often that it's a negotiable point. And so I found just by sending over the client letter, which indicates how we bill, that they're agreeing to the services much like your master services agreement "Oh and by the way, here's a pre-authorization. So if you don't pay...", more than 9 times out of 10, they fill it out. And now we've got a great back stop for collections, which saves you a lot of time and headache. And the clients don't feel it as a -- there's less heartburn  than putting up $7000 in an account that they no longer have access to. EVAN: Although you have to pay the small overhead of doing the credit card transaction, right? JARED: You do. But man, that's something I'll take the 3-4% hit any day -- EVAN: Sure. Yeah over not collecting anything, yeah! CHUCK: Yeah. And so is it just the form that they put their credit card information on and then you just go, you run it through like a virtual terminal on or something? JARED: Yeah that's right. CHUCK: So you manually enter it. But's in the contract that says "I can run your credit card for this amount" JARED: That's right. So if authorized or whoever your merchant processor is comes back and the client has an issue, there's always a dispute resolution process. They don't just reverse those payments automatically, they'll go back to the person who charge and they'll say "we've got notice that there's an issue here", and all you have to do then is provide your contract and say "Look, here's the authorization they provided me, here's evidence of the invoice I gave to them on this date. It's been a lot of period by which they agreed that I could charge their card" and then they won't legally be allowed to reverse the charge. Person could still take in the next step, they could file suit, they could do other things, they got their legal remedies, but that time you've got the money and you're sitting on it, and they need to get it back from you at that point. EVAN: Yeah. And I don't, for our part, it's an interesting point. For our part as developers, clients (at least my clients) are often giving me access to resources that they're paying for on ongoing basis and/or on an as used basis, so whenever I use these resources, they're paying additional money anyway. So it's not entirely dissimilar to just giving me access to their credit card directly anyway. So that's to say they might be our clients are actually stand a reasonable chance or our types of clients in a reasonable chance of being open to that. So it's a first thing idea. JARED: The other things to include in your payment section is obviously -- I mean you're maybe good and reasonable people, and so it may seem hard to put in interest penalties. But interest penalties aren't there to just work your client over, they're really there just to provide and sent as for your client to pay. And so including interest in there, it's a standard practice, not that to do, despite your philosophical thoughts on interests as it may be. The other point to include in there is in the off-chance that you haven't collected upfront, you don't have a back stop to collect it, including a provision, a one-liner that says "If we require to pursue collection actions, you'll be responsible to reimburse us for our collection cost on attorney's fees". That one line can be the difference between 'no money' and 'a lot of money'. By default, if you prevail outlaw in the United States, you're not automatically allowed your attorney's fees unless there's a statute that specifically allows it. Or unless the party has agreed by contract. So that one little extra sentence can really help you regain some money. It also makes your case more attractive if you -- there are firms out there who specialize in collections and they will do collections work on a contingency. And if you have collection of attorney's fees in there, that's much more attractive for a collection firm to potentially take that collection matter for you. You don't have to be out-of-pocket, but you're not going to collect the full amount because you're going to be sharing it with the attorney. CHUCK: That makes sense. Are there other sections of the contract that we haven't talked about that need to be in there? JARED: The major other one, and you may have this in your master services agreement or you may have it specified within your statement of work, and that would be your acceptance, your delivery and acceptance procedures or your acceptance and rejection procedures. If you don't have any acceptance or rejection procedures, you may open yourself up to the possibility that the client just refuses to accept your product because it doesn't comply with the specifications. Therefore they may also make the argument that "if you haven't delivered a product that complies, then they shouldn't have to pay you anything". And I've seen those disputes and they're really nasty and really ugly. So if your statement of work is divided up into milestones, and there's amount of money, project cost associated with each milestone, and you deliver a milestone in accordance with some acceptance, delivery and acceptance procedures, you are reducing the risk that your client can come and say "You didn't deliver what you told me you were going to, I don't have to pay you." Because we divided it up into more manageable pieces where the client is probably going to accept things or more likely to accept small pieces along the way, then the whole project, if there's one little thing that they don't like and they've absolutely rejected. So that's probably not a foreign concept to you, I know. What do you guys typically do -- it's nice to have a default provision that would say "I give this to you, you've got 14 days to review it. If you don't come back with a rejection or any comments or fixes, it's deemed accepted and now I've earned all my money and can assume with that deliverable". What (do) you guys typically prefer to do? CHUCK: What you said makes sense. One thing that I do with a lot of my clients is that...I'm really terrible about giving a them a statement of work, and maybe we can talk about that in a minute and why I ought to do that or why may or may not matter, but typically I'm using some kind of system that has some kind of discreet story or ticket that explains the feature or bug that they want handled in the software and then there's a procedure for that. So I usually won't go into my statement of work, but I do like the idea of saying "For each thing in the system that we're using to track features or track bugs, if you don't accept within a certain amount of time, then it will be assumed that you've accepted the work". EVAN: The potential problem with that, speaking we've got a lawyer on the call (Jared could talk, too), but the potential problem I see with that is the system that you're talking about Chuck is, obviously I use it, too, and Eric uses systems like that as well, is that they're modifiable. CHUCK: Yes. EVAN: So, they record or something that we done could be deleted or modified after the fact, and there is not necessarily any evidence of that. So that will be problematic. WIth that said, I have the exact -- I operate in almost exactly the same way that is that by stabling at work. Because usually something in effect of that I'll do work for them as requested by the client, and sometimes it's work-for-hire, sometimes it's not. But it's really on a individual-small-tasks basis, not a here's-a-set-of-requirements-of-front-go-build-it basis. ERIC: I'm a bit different. Like I'll use the systems like a bug tracker or whatever to keep track of the task, but this isn't in my master services agreement. When I tell them I'm completed with the project, they have 30 days to basically accept or tell me there's bugs or defects or something wrong. And if they don't tell me within that time, then they basically default to "accepted the project as it is". And so I used to lay project, and I used to lay project to mark stuff as "this is done and have the client accepts stuff in the project", but I don't actually tied that into the contract. When the contract's done, I send them an email or call them and say "Look, the project's completed. The contract's over...(you have 30 days or whatever) to get back to me on things and we can re-negotiate or open up stuff if there is things". EVAN: But you're not doing that with your current client. Are you the one who were doing stuff augmentation? ERIC: That's a bit different. I'm actually using their contract due their size -- EVAN: Ah okay. ERIC: And it's transitioned more into a retainer model, than a here's-a-well-defined-requirement. So it's more of "We have Eric for this amount of time; when he's around, every hour he works, he does stuff for us" type thing. CHUCK: Yeah. Those kind of the situation I'm in right now. I'm using my contract, but we're using their bug tracking system and yeah, it's really just -- track's going to put in so many hours of work on our project, they have an acceptance criteria for the team, and there's no really warranty that's applied or anything. I think it'd be pretty difficult for them to come in and say "you didn't deliver in these ways" based on the fact that there's so many people with their fingers and code anyway. But with other projects, yeah I could just specify in their "of deliver you will list of the stories of whatever that have been completed within this amount of time", and then you have a certain amount of time to accept or it will be assumed that the work's complete. But usually, it's a pay-by-the-hour kind of thing. And so what it really comes down to is "I'm going to send you an invoice for the hours I worked, and you'll pay it". JARED: Yeah. So if it's more project-based than hourly-based, that's where this kind of acceptance and the default "if you don't get back to me within x number of days, it's deemed accepted" is really more helpful. And it's really an alogist to the kind of the real estate realm where "Hey, I build out something for you. When I say it's done, we go do a walk-through together and we start making a punched list and we figure out any final changes you want. And if you don't bring it up, then so be it". And if you want to make any additional changes, now we're talking additional skill, we're talking additional payments. If you're working on an hourly basis, then it doesn't matter because you're just working until the client is satisfied and the client's incurring additional cost anyways. CHUCK: So my question I guess is, the statement of work makes a lot of sense to me if it's "hey, here's the project, here's what we're going to pay you for, and we're going to pay you a certain amount", more kind of a fixed-bid thing or just kind of setting the scope on "you're going to work hourly and tell 'this set of work is done' and then when we negotiate a new contract for the next set of work". My question is this: if it's an hourly thing, do I need a statement of work? And if so, what would I put on? JARED: No, if it's an hourly thing, I don't think you need a statement of work. Often you may have clients find that it's helpful, pretty to provide some budgeting to them to say "hey, I anticipated it's going to be this much time". But if that's the case, if I'm on an hourly basis, just looking at the default in sentence "if I'm on an hourly basis, then I want the project to go as long as possible because it means I can feed my family for a little longer", CHUCK: Right. JARED:"If I'm on a project basis, then I want to get it done as quickly as possible because I make a better hourly rate". So if I'm on an hourly rate with the client and they want some kind of budgeting, I want to be able to give them the budgeting so that they internally can understand probably what's it's going to be. But I still want the flexibility to say "this is not a guarantee; the project may take more or fewer hours", and you want to have that flexibility open so that you're not really closely working on a project basis. ERIC: For me, I kind of use it as like -- my master services agreement's kind of like the general like "these are my standard procedures", and in the statement of work is like the specifics. And so kind of like inheritance in programming; my master services agreement might outline that I do AB and C, but then the statement of work can say "well, we're not going to do A and we're going to do B differently". And so I even use the statement of work on hourly just for that to say like "okay well, this project were changing the license in the ownership". And if it's like the feast and stuff, I'll just put something kind of vague in their words. It's going to be an hourly amount; the scope would be like "Eric's going to work on the scope as determined and agreed upon between the client and developer" and kind of keep it very open and friendly and just use the statement of work as a way to overwrite my main agreement. The big reason I do that is, probably 80% of my clients are repeat clients where we have kind of the same agreement on all the projects, but each project's a little bit different. And so I give them one master services agreement, which is 10 pages, and then I give them a dozen different statements of work that are 1 or 2 pages for each project. And so they found that it lets my client review the contract; they don't have to actually send it out to their attorney to re-review like everything each time. They just have a quick thing like a sheet to look in like "Oh yeah, this is good. We're going to go and move forward". JARED: Yeah absolutely. You nailed it on the head there. If you'd take that approach and they don't have to send it to their attorney, you save a lot of time and you get the project approved a lot quicker, and yeah, I employed the master services agreement with statement of work frequently. Now, do make sure because often you'll have statements of work that are superseded by the master services agreement. So it sounds like you've made it specific that the statement of work will always overwrite the master services agreement, not vice versa. EVAN: Yup! JARED: So make sure that there's those consistencies if you plan to use it as an overwrite. EVAN: Yeah. I mean the first actual sentence paragraph of the statement of work basically says like it overwrites master services agreement. And then there's actually a whole section in the statement of work that says modifications like "this section with the master services is replaced; this section doesn't apply; this section's amended", so it's pretty well visible through the whole document. JARED: Couple of other things that may be think about is -- I guess maybe a question for you guys first. When you guys contract out, are you contracting out as an agency, as an entity with multiple employees, etcetera? Or you're contracting out on an individual basis like personally, in your real name? ERIC: Agency. EVAN: I quit out as a company. Yeah! I think we all do it as an agency. CHUCK: Yeah I have an LLC, and that's what the contract -- the contract's between my LLC and the client. JARED: Okay! Because often if you have a personal services contract, then sometimes you have certain non-delegable duties. I don't know if you guys use a lot of sub-contractors as well or if you're performing all of the services for client, but if you do it tend to sub-contract some of it out, you may want to call out that your contract isn't going to precludes you from doing exactly that. That your contract is not a personal services contract, and that you can sub-contract out one more or even all of the project to other people. CHUCK: I'm pretty sure that my contract says that, but I need to go and check that. Because I haven't -- EVAN: I have to be sure that my contract says that because we have the same contract basically. CHUCK: Yeah! [laughter] EVAN: I'm pretty sure I've looked for that before. CHUCK: Yeah I'm almost positive -- EVAN: Basically, it says that we could sub-contract at will, it's just that -- actually I'm 95% sure because I had 1 or 2 clients pushed back on that and say that they wanted to be sure I wasn't subbing any of the work. JARED: Got you! Yeah. CHUCK: Yeah. JARED: From the client's perspective, that makes sense. If they know you and trust you but they don't know the person you're subbing to -- EVAN: Well not only that. I've heard tale of enough organizations where they get contract and will deal the work, and really all they do was to turn around and outsource it. JARED: They're just a broker, yeah. EVAN: They have tried to appear to be something more than a broker, but often they're just a broker. They're just the middle-man who collects money off the client and uses a rate arbitrage essentially to make a buck. JARED: Yeah. How often do you find that the clients are slow to cooperate, slow to respond, and that has an impact on your turn around time, etcetera? Is that ever become a problem with you? Have you included provisions to that respect that the client may be in default if they're not cooperating or providing timely responses? EVAN: No, I haven't. And now that you're saying that, oh my gosh! I would like to have something like that. I don't know about you Chuck and Eric, but you've heard me go on before about some of the clients I've had who've been derelict. CHUCK: I've had that a few times, too, with some of my clients where it's not that they don't have things that they want me to do, but they aren't communicating them to me fast enough to keep me busy. Yeah, that's a problem. I didn't think about putting that in the contract, but I kind of like it. ERIC: Yeah. JARED: Yeah maybe something to consider. Earlier, it sounded like there are times where you are also purchasing or making, almost acting like an agent of the client to purchase certain services for them. Do you typically mark those up? If you do mark them up, do you typically disclose what your markup's going to be? Or you pass those through on a pure cost basis to your client? CHUCK: I'm going to jump in and just say "it depends". I mean if it's like a designer or something, sometimes I'll treat them like a regular sub-contractor so I'll mark it up a little bit. I usually will disclose what the rate that they're going to pay is, but I don't tell them what the markup is. EVAN: Right. CHUCK: Sometimes I do. I mean it just depends on how transparent it is and whether or not they're going to be really mad that I marked it up 10% or something. But mainly, it's really just as much communication as they need to be happy with the work. As far as like other services, if it doesn't fall under kind of a sub-contract thing and there's any kind of ongoing purchasing of that service, I'll make them buy it. JARED: Got you! EVAN: That's what I tend to do. On most case, I expense it and I usually just do what it cost, just like Chuck. I think the majority of us when we sub-contract, we take a little bit off the top because we found the work and we have to mainly serve client; and the amount varies from contractor to contractor, 10-12% or what amount they take. Chuck said exactly what I do. I tried to get them to buy the services especially if it's a monthly payment because I don't want to be responsible for that invoice monthly; especially for whenever their client relationship ends, I wouldn't want to maintain it. Or otherwise, if it's just a one-time expense, sometimes I'll just buy it and expense them. JARED: Yeah. CHUCK: Yeah. But again I mean if it's a one-time expense, and like I said, it's not a sub-contractor type of thing, then I don't want to get in to the whole argument when we part ways as to who owns what. And so I'd still rather than pay for it if I can help it. EVAN: Oh sure! Always. CHUCK: I mean because expensing it, it's another line item; it takes me another 10 seconds to add it to the invoice. But I don't want to have to worry about the relationship after we're done; after I get things done for them. I want them to be happy with everything they have; have clear delineation of "what you own and what I own". In that way, I can come back to you later and say "Hey, I've got this other potential client, can they call you?" and "Have you tell them I'm deliriously happy with Chuck, I'm deliriously happy with this company. I got eveything I wanted." EVAN: It is not just all materials, Chuck. I mean I'm talking about things also like travel expenses. CHUCK: Yeah. EVAN: Because I expense those as I incur them and they just appear on the next invoice. CHUCK: Yeah that's fair. The travel expenses is something I really haven't had to deal with. [Evan inaudible on the background] CHUCK: Yeah. I want to change tactics again a little bit. We've talked a lot about our agreements with our clients, I'm a little curious, what are some of the gotchas that will come from the client if they insist on using their own contract? Because I mean we're giving them a contract that's kind of skewed toward us. It gives us the security that we want; it gives us the working conditions that we want. Sometimes the client is a big client or there's some reason why they really want to use their own agreement. So what did they put in there that we need to look out for? JARED: I think that's best answer, just going back through the list of topics that we discussed, are warning to include in our contracts. First off, it's going to be the "ownership" question. Because you live and die by your code, if all of a sudden we're unintentionally assigning all ownership in our code to them, that's tragic. So absolutely, you're going to need to watch out for that. The other provisions would be "provisions that are very one-sided". You're going to see a middle-of-the-road contract if you see that a lot of the miscellaneous provisions, meaning the provisions that are kind of the broiler plate that come at the end. If they are even-handed and mutual, you usually can have a sense that the rest of the contract is pretty fair. If you skip immediately to the bottom of your contract, the end of your contract, and you find all of a sudden that the governing law provisions are only in their jurisdiction, that they require you to go there if you need to sue them and you can't sue them in your home jurisdiction if they're in a different place. If you find that they're requiring that you indemnify them in the case that their damage as a result of your code, but they're not -- CHUCK: What do you mean by that? JARED: Indemnification is one of those weird, funky, big legal words, but what it really means is "you reimburse me or you'll pay me back if I get injured by your stupidity, or your bad axe, or your negligence". CHUCK: Oh okay. JARED: So for example, if the client gets injured or they sustained damages because of the code that you write, they're saying "we want you to reimburse us for damages that we sustained because of XY and Z that are your actions". CHUCK: Okay. JARED: But it also makes sense if it's an even-handed contract to have them say -- and because you're agreeing to do that will also agree "if we do anything stupid with your code, we misuse it, and it comes back to bite you, we'll agree to reimburse you for that". So it's kind of "we should have the damages and the responsibility for those damages" really lie with the responsible party. But in a client who's really pushing their paper, often you're going to see that it's very one-sided. You're going to see the indemnification; they may have some non-competition or non-solicitation provisions. Essentially, it's saying "Hey, if you're working for or sub-contracting especially for another company and you're doing all the work on the project, they may prohibit you from then working directly with the "in" customer for a time so you couldn't just serve, convent, and really provide better services probably in the more attractive price to the "in" customer. Another provision you'll want to especially look out for would be kind of a "liquidated damages provision". Now liquidated damages, we've talked about this concept of damages like client getting injured, but often it's very hard to pinpoint what monetary damages the client sustain, right? I mean if they lost some data, how do you really monetize that? Is it the cause of recovering metdata? Is it the cause of duplicating that data or going out and getting that data again? So it's really hard to monetize so often. Maybe not often, but sometimes you will have a liquidated damage provision which says "If we're damaged at all, we know that it's difficult to determine and that would take expert and legal fess, so we're both going to agree upfront that the damages that we sustain are going to be $100,000 or $200,000", right? So in advanced, you're essentially agreeing "If I don anything wrong, I have to pay you X amount of dollars". And those can be really really problematic. CHUCK: Wow. JARED: Because essentially then all they have to do is go into court, prove some kind of default, and suddenly the amount of liabilities are already set. So pay attention to those and pay attention to any kind of non-compete provisions. Obviously again, with any trade or profession, the more we do something, the more efficiently we do it and the more expertly we do it. So if you're working on a project for a client, and they say "you cannot work on a project for anybody else that's similar in nature for a period of X number of years", obviously that could also be problematic if that's become your kind of area of specialty even if you've retained your existing toolbox and you've only assigned them a certain portion of the code that is necessary for them to operate their system. If your hands all of a sudden are tied and you can't build out code of particular domain, that particular field of expertise, that could be very problematic. But often your clients will say "Oh man! They have real heartburn and they feel like it's a real conflict of interest" if you build something for them and then turn around because you're an independent contractor and build something for a competitor or an indirect competitor along dissimilar lines. So how do you guys generally deal with those types of conflicts of interest? I'm sure, you've got clients that bring up those issues. CHUCK: I've been both passive-aggressive and I've just -- by passive-aggressive I mean I take the PDF and I chop out the pieces I don't like and then sign it and send it back. So they only have a signed copy with the parts that I'm okay with, or I've actually gone and asked them to remove them. EVAN: Every single time I'm just -- Oh sorry, Chuck, you weren't done. CHUCK: Well, I've never had a problem with either approach. I like being open and communicative. I only made the changes like on my very first project, and then I realized that I probably should have talked to them first. So, now that's what I do. And I've never had a problem going in and saying "Look, I can't sign this". One of them was a non-compete, and the non-compete was a separate agreement from the contract that they sent me. So I said "Look, you need to take these pieces out of the contract and I'm not signing your non-compete", and they were fine with that. EVAN: That's kind of what I've done. I mean every single time I've had an issue with, it's either be something detailing NDA or contract like that, I've just gone directly to the client and say "Look, I'm okay with all these, except XY and Z, and here's why I'm not okay with it". Like I literally had one NDA where their NDA was so, I guess it was just done so badly, but I would literally break the NDA the moment I got to get clone. [laughter] EVAN: Yeah. So I told them "Look, I literally cannot do my job if you don't change it this year", and there were a few other parts like that. But I'm okay with, I'm not a fan of non-compete, but I'm okay with a certain amount. I can understand them not wanting me to take domain knowledge I gained working on their project and turning around and working with a competitor that it take to prove it competitor in their space. What I'm very clear with the client about is that we have to tweak their non-competed wording so that way, it's very domain specific because I don't want them putting me out of work just because I worked with them. JARED: Absolutely. CHUCK: I've seen some NDAs that read like non-competes. ERIC: I'll have a horror story of one. This wasn't my client, I basically said no and meet her go away. But she asked for a 10 year one way in the air where she could talk about everything I say, but I can't talk about any of her stuff. And it was a 10 year non-compete, but it was so general that I couldn't work in software for 10 years. [Evan laughs] CHUCK: Yeah. I've seen stuff like that, it blows my mind! It's like -- EVAN: You should have told her you're open to it if she's willing to pay you the sum of several million dollars. [Chuck laughs] ERIC: Yeah. I've checked in on her business afterward, and it went bust in like a year and a half. EVAN: Well, if she had paid you for 10 years worth of income, she probably would have got busted right away [laughs]. CHUCK: Yeah. But that makes sense. JARED: In that same light, we're talking about the client wanted to protect the knowledge that you gained on their project. Likewise in your own contracts, a very specific non-solicitation that if you do have other developers that are working with you through your business and that have direct access to the client, it's very appropriate and very acceptable to have a non-solicit so that during the project and for some term after, the client can not directly go and approach your team members and then bring them in house and hire them away from you and essentially take the contract away from you. EVAN: That sounds like a really worthwhile clause to add about sub-contractors. CHUCK: Yeah that's what demise sub-contracting; and I think it's for 12 or 18 months or something. JARED: One other provision that, it's probably not good for the attorneys because it discourages litigation -- [laughter] JARED: But if you have a provision in your -- it's essentially your dispute resolution provision. And it says that "If either party wants to sue under this agreement, they have to go to the jurisdiction of the defending party". So if you're not working in the same state as your client, and they want to sue you, all of a sudden if they're in New York and you're in Utah or you're in Maryland, they didn't have to go to Maryland (if that's where you're located) and sue you there. And if you wanted to sue them, you have to go to New York and sue them there. It's just a [inaudible] incentive such that now, you have to think about that additional cost of finding somebody not local, paying outstate fees, thinking about if you do get in to any kind of litigation and depositions in other things, now you have to travel to that state, working with the body of law that you may not be as familiar with. All of those things combined, it can that extra layer to disc overage, otherwise, we should just work out as reasonable people. ERIC: Well on the other thing is they have -- EVAN: [inaudible] the check line of that same provision, where it's a little more skewed to us. If they want to sue, they have to come to us to do it. That's just the contract that we got, especially the one you described to Eric's more even-handed. JARED: Yeah. And obviously, you probably want to leave with the one "hey, you have to come to us". But if you want to get that halfway between, it's a good even-handed approach to say "okay well, if I want to sue you, I have to go to you; if you want to sue me, you got to come to me". CHUCK: I have to say I'm a little bit torn as to whether or not I hope my clients are listening to this because they'll know so many things that they can negotiate with me, but at the same time they'll also know some of the things that they can't pull over [laughs]. So they won't even try, right? JARED: Yeah. CHUCK: I don't know. Did you have something to add, Eric? ERIC: I was just going to say where the laws interpreted, that's pretty much the basis of the stereotypical software patent roll. I think it's in Texas or some place, there's very very different -- JARED: Omaha, Texas. ERIC: Yeah. If there's like different laws for how patents work them so that's why they sue everyone there? And so that's something to watch for. I mean unless you want to say "you have to go to Hawaii if you want to sue me, just so you can kind of vacation if get sued". CHUCK: [laughs] I like that approach. EVAN: Is that maybe a reason not to live in Hawaii because then if you want to make your client come to you to sue you, then they get to go to Hawaii? [crosstalk] CHUCK: Yeah that's true, I don't know [laughs]. Kind of funny. So Eric put something in the chat and I'm a little curious, what's the difference between arbitration and taking somebody to court? JARED: Arbitration is not litigation. If you take somebody to court, you're bound by the laws of the state or the federal laws depending on whether you bring it and stay to federal court. Most of these are going to be contract claims that you're going to be dealing with, unless you're dealing with intellectual property violations like copyright or patent, which will be brought in federal court. So arbitration is essentially a sped up process that the parties contractually agreed to "here's how we're going to resolve disputes". So it's like a quasi court, but the arbitrators are not representatives of the state; they're not voted in judges. Generally they typically are ex-judges or practicing attorneys. But unlike mediation, arbitration is contractually binding upon the parties. So we really have these 3 flavors; we have mediation, arbitration, and litigation. In mediation, the parties can say we're going to go before we can file anything in arbitration or litigation. We have to hire a mediator, an independent third-party who's going to help us try and resolve all our disputes. But at the end of the day, the mediator can't make any decisions; and unless we agree upon something, it's over and we still have our dispute. In arbitration, it's kind of -- I'll make one more point about the court system. The court system takes so long and in such a time, it's so backlogged that if you want to really go the distance on filing a complaint and going through discovery, finally getting to a trial and getting a decision, you're talking about years, literally multiple years in most states and most jurisdictions, unless you're dealing with small claims. Generally in Utah, the threshold is $10,000 so if you got a claim for less than $10,000, go to small claims court. For more than $10,000, though, and you want to collect on more than the $10,000, then you need to go to the regular court process, which is going to be a very long process. So arbitration then is these ex-judges, current attorneys; and the parties in their contract say "okay we're agreeing that we won't go to, we'll go to arbitration because we can get this thing resolved a lot quicker. But we're agreeing that this independent third-party can actually -- CHUCK: Make a decision for us. JARED: Make a decision, and it's binding upon us. Now if you have an area of law that has a lot of new ones and you want somebody with that particular expertise to be making decisions about the dispute, arbitration is a very good route to go. Because in your contract, you can spell out in the arbitration provision that "okay, we'll submit or dispute to arbitration and the arbitrator will be somebody who has at least 5 years, 10 years experience with software, who has been a former judge, something along those lines. So then you can guarantee that the person making decision is somebody who speaks the same language as you. If you go to a court and you file, the judge that gets assigned to your case could be somebody who's 80 years old, who is around before software was mainstream, who just doesn't understand the lingo, and it's really a luck at the draw.  So by choosing that arbitration and specifying who it can be, obviously you can make sure that somebody (is) a little more qualified to be making those decisions; and you can get it done a lot quicker. The problem, the downside though is sometimes you don't want it to go a lot quicker. If you're on the defending side, you may want to drag it out! And the other problem is this, because it is a more condensed legal proceeding because the time tables are a lot shorter, you often end up incurring a lot more legal fees a lot more quickly. So from a cashflow perspective, it can often be more difficult to manage. CHUCK: Alright. I know Evan has to leave since, so Evan do you want to gives us your picks really quickly? I have a few more questions for Jared before we wrap the show up. EVAN: Oh okay. So my picks! I guess I have 2. One specific one, I started doing a podcast with Zee Spencer, I guess it's really a screencast. And Zee Spencer, Ashe Dryden is on it; sometimes Dave Hoover, Ike Sanders, and we're talking about how to basically "grow other software developers". So it's really about mentoring, training, and that sort of thing. We've gone a couple of weeks and it's going to be in every other week thing. We're also going to be taking our open to live questions during the screencast. We broadcast it over Google+. The other pick is more generalized. I think I mentioned "Mastery" by George Leonard last time I was on the show. I've used that book to restart my exercise habit, and I've been exercising pretty much every day for over the past month. And the difference it's made on my energy level has been huge. I'm not sure we've ever talked about that as a pick. I know we've discussed "sleep, eat" before, but "exercise" is right up there. So if you aren't, you probably have heard it before, but if you're not exercising, you're doing your brain at the surface. That's pretty much it. So you're just doing me as a pick so I can get going and then you're going to get back to the show? CHUCK: Yeah. I don't want to end it without talking about sub-contractor agreements. EVAN: Now I wish I could stick around for that. Alright well, I guess I can listen to it later. CHUCK: Yup. EVAN: Jared thanks for being on the show, really cool insight! JARED: Yeah and all thanks for having me. Great talking with you. EVAN: See you later, guys! CHUCK: See you! Alright so like I said, sub-contractor agreements - agreements with our sub-contractors. JARED: Yeah I mean the biggest thing I'd say there is, all of a sudden all those things that you're watching out for in your client contracts are the same things that you're probably going to want to be imposing upon your sub-contractors. You're going to want to make sure that they're not circumventing and going directly with your clients. That's a big concern especially if they're real through outside parties. Over home, you don't have a lot of oversight when you were having direct client contact. There are circumvention would be very key. The other would be representations and warranties from them especially if they're, again, outsiders, you know them from online, you've seen some of their code or what you think is their code. But in that recent story about that guy who, I can't remember what was he working with, I can't remember who he's working for, but he essentially had outsourced his whole job, right? And he's sitting there at work, on Facebook, watching videos, doing whatever. His employer, it took him a long time to figure out that he wasn't actually writing the code, wasn't doing what he's supposed to. So with the same thing with your sub-contractors, having representations and warranties from them that they're the original authors of their code so you're not unintentionally putting open source libraries that you don't know or understand are open source libraries that could compromise the representations that you're making to the client, are obviously would be very critical and important. Having your sub-contractors carry insurance would also be a really important thing because you don't know what you don't know and you don't know what they might have put in there; any backdoors, any kind of elicit code, any kind of issues. It seems like today, there's all sorts of -- we learn about people's double-lives that on the surface it seem great, and we just don't really know. I was shocked about the Olympic athlete, the Pistorius, today about the murder of his girlfriend. Seeing an Olympic athlete give us a double-life and ends up doing something like that, it calls in the question everybody we work with and although we like to think and have the best intentions for the people we work with, we just don't know. So protecting ourselves by having an insurance in case we get burned by their mistakes and their follies, or by their intentional misconduct, is certainly important. The other thing, just from a practicality stand point, requiring them to make regular reports, regular reporting on not only where they at or at from a project management's stand point for client management expectations, but also from a "here's the hours I worked, here's the time I really was spent", you can figure out quickly how efficient they are. Or as if you're only looking at deliverables and lump sums of time, it becomes more difficult to really evaluate their performance and efficiency among other things. That's just a general high level, but any specific question have the answer. CHUCK: I don't know if I have any. Eric, do you have any specific question? ERIC: No, I don't. I don't do much with sub-contractors; I don't even have a sub-contractor agreement. CHUCK: Alright. Well I don't know that I have any other questions other than, there are couple of other legal topics that I'd like to cover, so I'm wondering if you'd be willing to come back for future shows? JARED: Oh, absolutely! CHUCK: Okay, we'll get you scheduled then for probably, I'd like to go a little deeper on intellectual property, patents, and copyrights, and stuff like that. And I think there was another topic that I was looking at, so if we could get you back for that, that would be awesome. JARED: Sounds good. CHUCK: Alright so let's get into the picks then. Eric, do you have picks this week? ERIC: Actually I don't because I took this entire week off from work; this is the only that I could work for later thing I'm doing. So I haven't reading or doing anything at all. So I guess my pick would be, "take time off work". CHUCK: Alright, cool! ERIC: And to kind of base off Evan's exercise, my other pick would be to "breathe", so we cover that base. CHUCK: [laughs] Nice! Okay my picks this week, I bought a couple of the screencast off of PeepCode, so I'm going to pick "PeepCode". The ones that I bought -- I got there a chef video not too long ago, their part 1, I just picked up part 2 today. It's really really good so I'm going to pick their "Chef" video, and I'm also going to pick their "Ember.js" video, which I haven’t' watched, but I'm excited to see. So Jared, what are your picks? JARED: My pick, since we're talking about contracts, is the "Google Advanced Search" function. If you do your Google Advanced Search, it can limit obviously by document type, and you can limit to PDF and .docs. And if you do a search for any of these provisions that we discussed or general high-level contracts just the contract title, and you limit it to PDF and .doc, you can get a whole array of wonderful contracts for free. You don't have to go to legal zoom, you don't have to call an attorney; and if you get a few of them, you can quickly find a lot of those good gem provisions that you probably were looking for. CHUCK: Alright, cool! Alright well, if that's all we've got, the only thing that I have left to bring up is that I'm teaching a Ruby on Rails course; you can go sign up at It's only going to be available until March 6th, to which is when the first lesson will be. So if you're going to sign up, I would sign up quickly. And if you used the code "podcast", you can get $200 off. So anyway, thanks for coming Jared! I was really good to talk through this and there are definitely some things that I'm going to have to go back through my contract and see if and where they fit and how I want to approach them. JARED: Oh thanks for having me! And I hope it was somewhat helpful, so thanks again! CHUCK: Yeah if people want to find you or hire you to do contracts for them, how do they do that? JARED: You can get me at -- I'll shoot over chat here my contact. You can find me on Twitter @UTStartupLawyer, you can email me at and I get a lot of phone calls so 801-438-2040. CHUCK: Alright. Good deal! Thanks again for coming! JARED: You bet!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.