The contract matters most in the work you have not done yet
It is easy to read an agreement with your attention fixed on what is happening now.
Ownership. Role. Compensation. Board seats. Delivery. Exit.
But some of the most consequential sentences in a contract are really about what you will still be allowed to do later.
That becomes especially important when you enter a new company, partnership or client relationship with more than your time.
You may already bring methods, models, frameworks, code, workflows, AI architecture, commercial logic, analysis approaches, customer experience and years of accumulated know-how.
Then you start building something new together.
A contract may say that the company owns ideas, concepts, methods or other intellectual property that arise from, relate to, or can naturally be connected to the company's business.
That can sound perfectly reasonable.
Until you ask a different question:
What does this sentence mean for the work I have not done yet?
That is the question I have started to find more useful.
Using something in a project does not necessarily mean the project created it
A consultant can use an existing method to solve a new problem.
A developer can use an existing library, architecture pattern or tool while building a new product.
A commercial adviser can apply a model developed over years of previous work.
The new company or client should, of course, own what it has actually commissioned, paid for and created with you.
But that does not automatically mean it should own the underlying toolbox.
The distinction is easy to miss because the two are often intertwined in practice. A new product can depend on old knowledge. New code can build on reusable components. A new commercial model can use principles that existed long before the engagement.
If the agreement does not distinguish between those layers, a very broad IP clause can reach much further than anyone intended when it was signed.
The real test is the next assignment
When I read an IP or non-compete clause now, I try not to look only at what it gives the company today.
I ask what it could prevent me from doing in the next assignment.
Could I still use the methods I had before the collaboration started?
Could I continue developing my general tools and frameworks?
Could I use the same kind of architecture to solve a different problem for a different market?
Could I keep doing the business I was already doing?
And what happens if the company later expands its own scope?
That last question matters more than it first appears.
A restriction tied to "the company's business from time to time" can become broader without the contract itself changing. The company moves. The boundary around you moves with it.
The same can happen with IP language that captures anything that can be "related" to the company's activities.
The wording may look harmless when the company is narrow. It can mean something very different three years later.
Four questions I want answered before signing
Before signing an agreement involving meaningful IP, know-how or competitive restrictions, I increasingly want four answers to be obvious:
- What did I own before this collaboration started?
- What will the company own because we are creating it specifically for the company?
- What does the company need a licence to use, without owning it?
- What am I still free to use in future assignments and businesses?
If those answers are unclear, the solution is not necessarily a longer contract.
Often the cleaner solution is a better boundary.
Background IP: what already existed, or is developed independently as reusable capability.
Project or company IP: what is created specifically for the new product, company or engagement.
Licence: what the company needs to use in order for its product to work, without transferring ownership of the underlying reusable asset.
That separation can remove a surprising amount of complexity.
This is not mainly about mistrust
People often resist this kind of precision because everyone around the table knows what they mean.
And they probably do.
But agreements become most important when circumstances change.
A new investor arrives.
The company is sold.
One founder becomes passive.
Someone starts another business.
The product expands into a new market.
A relationship that was easy when everyone shared the same assumptions suddenly has to survive without those assumptions.
That is when an ambiguous sentence written years earlier starts doing real work.
A good agreement is therefore not primarily a sign of mistrust. It is a way of preserving the relationship when memory, incentives and circumstances are no longer identical.
Read the agreement forward
The lesson I am taking with me is simple:
Do not read an agreement only from the perspective of the work you are doing today. Read it from the perspective of the work you may want to do three or five years from now.
Especially when the agreement covers intellectual property, know-how, competition or future business activities.
Because you are not only signing an agreement about who owns what you are building now.
Sometimes, without noticing it, you are also defining the boundaries around what you may build next.
What changed: I started evaluating IP and non-compete language against future work, not only the current collaboration.
What I think matters: The cleanest agreements distinguish ownership of the product from ownership of the reusable toolbox that helped create it.
What remains uncertain: The boundary will never be perfectly obvious in every case. But if the parties cannot explain that boundary in plain language before signing, the contract is probably not ready to sign.
*This is a practical reflection on collaboration and contracting, not legal advice. Agreements with material IP or non-compete consequences should be reviewed by qualified legal counsel before signing.*