You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 5: Contracts — MSAs, SOWs, IP Assignment, NDAs #

You are going to like this module more than you think you will, and I want to predict it explicitly so that when it happens you can notice it. Engineers tend to enter contract reading with the same defensive posture they bring to compliance — boring, lawyer-territory, not my job. And then about three days into reading an actual MSA carefully, something clicks. You realize the MSA is just an interface declaration. The SOW is the implementation. The IP assignment is the license. The indemnity is the exception specification. The governing law and dispute resolution clauses are the deployment region and the on-call escalation policy. The whole document is a system you have actually been building for years, just expressed in a different syntax. Once you see that, the resistance evaporates and the work becomes interesting. Not in a "fun" way — in a "this is a puzzle I can solve" way.

Here is the contrarian recommendation: do not start by writing your own templates. Start by reading three contracts you have already signed. Slowly. Clause by clause. Mark them up like you would a code review — what is well-designed, what is asymmetric, what would you have caught in a PR review, what did you miss. The first contract will take you four hours. The second will take two. The third will take one. By the end of the third, you will be reading at the speed where contract clauses produce intuitions instead of confusion. Then write the templates. Templates written without that grounding are usually overfitted to imagined risks (you'll add seven defensive clauses no Indian counterparty will sign) and underweight the real risks (you'll forget the IP carve-out for your library). Read first. Build second.

A truth the formal curriculum cannot say plainly: most contracts you sign as a small Indian consulting OPC selling to large US/EU clients are asymmetric and you will lose most clause-level fights. The big company has a legal department. You don't. The big company's MSA template was drafted with twelve hostile scenarios in mind. Yours wasn't. They will refuse to change governing law from California to India (accept it). They will refuse to lower indemnity caps below 12 months of fees (negotiate to 6 months and accept). They will insist on broad IP assignment (here is where you fight, hard, with carve-outs for your existing libraries and any pre-existing IP). The skill is not winning every clause — it is knowing which three clauses to fight on and accepting the others gracefully. Pick your fights. The three to fight: (1) IP assignment scope and pre-existing IP carve-outs, (2) indemnity caps and exclusions, (3) termination-for-convenience notice period and final payment terms. Everything else, accept the standard with minor edits.

The IP carve-out fight specifically is load-bearing if you maintain open source. Say you ship open-source libraries with real adoption. Some US client's standard MSA will have a "work product" clause that says everything the contractor produces during the engagement is owned by the client. You cannot sign that as written, because if you happen to commit a fix to your library during the engagement (you will — the library is your codebase, not theirs), you have technically transferred ownership of that fix and possibly the entire library. The carve-out language you need is something like: "For the avoidance of doubt, work product excludes (a) Contractor's pre-existing materials, including but not limited to open-source software contributed and maintained by Contractor or his/her company prior to and outside the scope of this Agreement, including but not limited to [list your libraries by name in a schedule], and (b) any modifications, improvements, or derivative works of such pre-existing materials made outside the scope of Contractor's services hereunder." Get this clause negotiated into every consulting MSA you sign. If the client refuses, the engagement is incompatible with you maintaining your OSS work and the answer is no, even if the money is good.

The Indian-counterparty MSA is a different shape. Indian companies tend to under-specify (the MSA is short, vague, and assumes good faith) where US companies over-specify (long, defensive, hostile in tone). The risks invert. With a US counterparty you risk over-committing on indemnity and IP; with an Indian counterparty you risk under-defining payment terms, scope creep, and dispute resolution venue. The MSA template for Indian counterparties has to add clauses the counterparty wouldn't think to ask for, where the US template has to push back on clauses they did. Two different drafting modes, both worth practicing.

About your studio specifically: the contracts you sign in the next 24 months will fall into about five buckets. (1) Consulting MSAs where you are the contractor (US client, governing law US). (2) Direct US client MSAs once you start invoicing in USD as the OPC. (3) Indian client MSAs (likely smaller engagements, governing law India). (4) Contractor agreements for any help you hire (designer, content writer, junior dev). (5) EULA / Terms of Service for your SaaS products as they launch. Each bucket has a template that you write once, version, and reuse. The templates are an asset that compounds. Six engagements in, the marginal cost of a new contract is fifteen minutes of editing. That compounding is the prize.

One specific thing about the open-source situation, since it is non-trivial. Open-source libraries with real downloads are a publicly identifiable IP asset attached to your name and your company's name. Any consulting MSA you sign needs to be reviewed against the question: does this contract grant the client any rights, even theoretical, to my libraries? Most US-counterparty MSAs have a "work for hire" or "all-IP-assignment" clause that, read literally, would grant the client ownership of any code you commit during the engagement. Your library's commits during a contracting period are at risk under such a clause. The carve-out language in this module is not boilerplate for you — it is load-bearing. You should have a list of your OSS projects (library names, repo URLs) ready to attach as a Schedule to every consulting MSA you sign. The schedule names them as pre-existing materials excluded from work-product assignment. This is a one-time list to maintain. Do it now.

There is a soft skill embedded in contracts work that engineers underestimate: the redline-and-respond rhythm. When you receive a counterparty's MSA, the response is not "I have a list of 14 changes." The response is a marked-up document with tracked changes plus a one-paragraph cover note explaining the three substantive changes and noting that the others are minor cleanup. This compresses a week of back-and-forth into one round trip. Counterparty's legal teams respond well to this rhythm because it respects their time. Most engineers respond badly to MSAs (either accepting silently or sending a 14-comment list that gets routed to legal review for a month). The rhythm is professional behavior — learn it once, use it forever.

Conclusion #

Contracts are interface contracts, literally. The skill is reading the type signature, identifying the asymmetries, fighting the three clauses that matter, and accepting the rest. The deliverable of this module is your template library — five templates that you can deploy in fifteen minutes against any new engagement — plus a redlining instinct that lets you read a counterparty's MSA in 90 minutes and know what to push back on. That instinct is the actual asset.

Predictions #

  • You will enjoy this module more than Module 2 (GST) and Module 6 (Bookkeeping), even though you predicted you wouldn't. The system-design analogy lands faster than you expect.
  • Re-reading an existing client contract you have already signed will surface at least one clause where you took a worse deal than necessary. The realization will be slightly painful. The next contract will be better because of it.
  • The IP carve-out clause will be the first place you push back on a US counterparty, and it will work. Big companies' legal departments expect this pushback from contractors who maintain their own OSS — they have language ready. Just ask.
  • You will be tempted to over-engineer the templates with too many defensive clauses. Resist. A clean three-page MSA is more enforceable than a defensive twelve-page one, because counterparties actually sign the three-page version.
  • The first time you redline a US-counterparty MSA on indemnity, the counterparty will counter with a slightly tightened version. You will accept the counter. This is normal — you got 70% of what you wanted, which is a win at your scale.
  • Pricing Creativity (Blair Enns) — already on your shelf if you did the Sales & Marketing path — will show up in this module too. The "options pricing" structure is enforced through the SOW. Re-read the contract chapters.
  • Within 12 months, you will have signed one contract you wish you hadn't. You will recognize it earlier than you would have without this module. The recognition is the win — escape clauses are easier to use when you knew you were in trouble.