Do you actually own what you build?
You built it. They own it.
A developer signed a standard contractor agreement.
Hourly rate. Normal terms. Nothing looked unusual.
But two clauses changed everything:
The company owns 100% of everything you build - forever.
You can't work in your field for 6 months after leaving.
No negotiation. No exceptions. Already signed.
This is a pattern I've started noticing across contractor agreements:
You write the code.
You solve the problems.
You ship the product.
And when you leave - you own nothing.
And you can't even use your skills for half a year.
The clause wasn't hidden.
It was right there in plain English.
But it didn't feel risky when signing.
It never does.
Have you ever signed something like this - and only realized later what you gave up?
If you want to check your contract before signing:
https://joyful-granita-8415bc.netlify.app
The fence analogy from the comments actually points to where the real problem lives it's not ownership of what you built for them, that part is reasonable. It's the scope creep in how these clauses get written. 'Anything related' or 'anything you work on during employment' is a completely different contract than 'the specific thing we paid you to build.' One is fair, the other is a trap. Most people sign without a lawyer because hiring a lawyer for a contractor agreement feels disproportionate to the deal and that's exactly what makes these clauses so effective. The asymmetry between how long it takes to sign and how long the consequences last is the actual problem.
Well put - that gap between how quick it is to sign and how long the consequences last is the part most people underestimate.
This is such an important question. Technically, indie hackers own what they build, but in reality a lot of that ownership is layered since platforms, APIs, and distribution channels still influence outcomes heavily.
Feels like true ownership today is less about code and more about owning your audience and the problem space you serve. Everything else can shift quickly.
Curious how you think about it, do you lean more toward independence or speed when building?
Yeah, that balance definitely comes up a lot.
hey, understand your pain and struggle. In my experiences, the non-compete is quite understandable and standard for tech. for semiconductor field, it can reach 1.5 years. although I am on developer side, I still find this a reasonable protection as the contractor will see the source code and get the design ideas or specific vertical domain insight from the project. Best is to make sure projects dont have overlay to avoid legal concerns and for own product in agency, make full overview to layout the plan so everyone can properly protect themselves while staying still functioning.
Makes sense - depends a lot on how it’s structured.
As someone who’s building a tool, this is really informative.
Appreciate it.
This is amazing, does it respect the local laws, past judgements or flag what can be done as remidiation?
Still early - just exploring how it applies in different cases for now.
This is why I went the bootstrapping route instead of contracting. Built a sports intelligence platform on my own terms — every line of code, every algorithm, every dataset stays mine.
But I've been on the other side too. Early in my career I signed a contract that assigned IP for anything I built "during the term of employment" — which they interpreted as literally anything, including side projects on weekends. Learned that lesson the hard way.
Two things I always look for now:
The non-compete is the real killer. Six months sounds short until you're burning savings while your skills depreciate. In most of Europe these clauses require compensation during the restricted period — worth checking if that applies.
What's the most aggressive clause you've seen in a contractor agreement?
Appreciate you sharing that - those are solid points.
Hard to say on my side - still early, just seeing different cases come through.
Important topic. Even for solo projects — clear ownership docs from day one save a lot of headaches later. Especially if you ever bring on a contractor or co-founder down the road.
Definitely - much easier to set it clearly early than deal with it later.
The 6-month non-compete isn't just lost income. If you're a contractor, your reputation IS your resume. You stop being visible in the market, you lose referrals, and your network goes cold. The real cost is often 12–18 months of lost momentum and not just 6.
That’s a good point - the impact goes beyond just the time window itself.
Exactly. Have you ever seen it affect someone you know? I think the stories people don't tell publicly are the ones that reveal how deep the damage actually goes.
Haven’t seen it directly, but I can imagine it’s pretty rough when it happens.
I believe that it's one of those things that sounds manageable on paper until you realize your last client has moved on and your referrals have gone to someone else. Just imagine: you spend 2 years building a product, become genuinely great at that tech stack, and then are locked out of using those exact skills professionally for half a year. You don't just lose income. You lose the momentum that took years to build. That's the part most people don't see coming.
The part about two normal-looking clauses changing everything is exactly why structural due diligence matters before a repo handoff. I built a 15-minute repo audit that surfaces the same load-bearing risks. Happy to send the OpenClaw sample if useful.
This is more common than people think. most devs only focus on rate and miss the long-term clauses until it’s too late. feels like there’s a gap in how people evaluate fit beyond just the work itself. how do you usually approach reviewing these now before signing?
Yeah, that gap shows up a lot - still figuring out a consistent approach myself, just trying to be more deliberate before signing.
yeah - and that definition tends to get clarified at the worst possible moment. like when you're leaving
I’ve been on both sides of this, as a developer signing contracts and now running DictaFlow. The non-compete part was what really got me too. The IP clause stings, but you kind of expect it. The 6-month freeze is when it actually hits, you can’t work, can’t build, and suddenly you’re just waiting. My rule now is simple: anything under 3 months, I treat as negotiable. Anything over 3 months gets priced in. If they’re buying your market mobility, that mobility isn’t free.
That’s a practical way to look at it - makes sense to factor it in like that.
This is honestly scary how common this is.
What stood out to me is how it didn’t feel risky while signing — even though the terms were right there.
I wonder if the real problem is that most people don’t think in terms of long-term ownership when they’re just trying to get started or land work.
Curious — do you think this is more of an awareness issue, or do people knowingly accept it because they don’t have leverage early on?
Hard to say - probably a mix of both depending on the situation.
Checked out the product — this is a strong concept.
The real value isn’t just finding risks, it’s making people aware of what they’re signing.
Feels like a problem most people only understand after getting burned.
Appreciate it - still early, but that’s exactly what I’m trying to understand better.
ran into this too. before starting my side project, had to carve a clear lane - open-source PM tools for indie builders, nothing that overlaps with my employer. the word "related" in these clauses does a lot of work.
Yeah, that “related” wording can get broad pretty quickly.
The non-compete is the part most people underestimate. IP ownership stings, but you mentally prepare for it. The 6-month clause hits differently when you're actually trying to line up your next client and realize you're frozen.
What I've started doing: treat any non-compete over 3 months as a rate negotiation trigger. If they want to restrict your market, that restriction has a price
That’s a practical way to think about it - tying it to rate makes sense.
Isnt this normal industry practice, I am not sure about legality of this but it has been around for a while.
It depends a lot on the situation and how it’s written.
Some parts are pretty standard (like ownership of the work), but others - like broad non-competes or unclear terms - can vary a lot and become problematic depending on scope, duration, and jurisdiction.
So it’s not always black and white -context matters.
Good point. I've been thinking about this a lot lately —
especially when building on top of third-party APIs.
The moment they change pricing or terms, your margin disappears.
I try to own the customer relationship at minimum, even if the
infrastructure depends on others.
That makes sense - owning the relationship seems like the most important part.
This is a question more founders should ask themselves early. The dependency on third-party platforms, APIs and hosting means you can wake up one day and find your business disrupted overnight. What's your approach to minimizing that risk while still moving fast?
Good question - still figuring that out, just trying to balance speed and flexibility for now.
I get this a lot. I ran into the same issue when I built a demo for my SaaS: I couldn’t download it, and I had to keep paying a subscription just to keep it alive. That frustration actually pushed me to build my own SaaS to be able to download my asset.
That’s a frustrating situation - makes sense why you’d want more control over it.
This is becoming way too common. The “you build it, we own it” part is standard, but stacking a non-compete on top for contractors feels unethical.
Thanks for bringing attention to it, a lot of devs sign fast because they just want to start working.
Yeah, especially when people just want to get started - that’s when it’s easiest to overlook.
Such an important reminder. The "plain English but still easy to miss" dynamic is so real — especially when you're excited to start a project or just need the work.
The tool is a great idea. Bookmarking it for future reference (and sharing with dev friends).
Curious: are you planning to add more contract patterns beyond IP + non-compete? Would love to see a "contract health check" evolve over time.
Appreciate it - still early, just seeing what comes up most often for now.
This is directly relevant to me right now. I'm a full-time researcher at a Korean company, building a SaaS on the side. Korean employment contracts often have IP clauses that are even broader than what you described — anything you create "using company resources or related to company business" can be claimed as company property.
I've been careful to work only on my own devices, outside work hours, on problems completely unrelated to my day job. But the clause language is vague enough that it still makes me uncomfortable.
For anyone in a similar situation: the riskiest part isn't the obvious stuff. It's the "related to company business" language that can stretch further than you expect.
That “related to” language can get tricky fast - easy to underestimate how far it stretches.
This hits home. As a dev who specifically builds self-hosted tools, I see so many founders building on 'rented land.' The moment a platform changes its TOS or hikes transaction fees, your margins vanish. There’s a massive peace of mind that comes with owning your database and deployment. It’s more work upfront, but at least you’re not one algorithm update away from losing your business.
Yeah, that tradeoff shows up a lot - more control vs more convenience.
The non-compete stuff is obviously unacceptable, but I'm confused about the ownership element. If someone paid you to write code for them for 3 months, does it not make sense that they would then own that code? If I paid for someone to build me a fence, I would own the fence afterwards. Would you expect to leave with 3 months of pay AND 3 months of code that you can just go and launch yourself as a competing product?
Sorry if I'm not understanding something here.
Yeah, totally fair question - and I agree on the fence analogy.
Ownership of the work itself usually makes sense.
The issue is more around how broad it gets in practice - sometimes it’s not just what you built for them, but anything related, future work, or unclear boundaries around side projects.
That’s where it can become a problem depending on how it’s written.
This is more common than people think, at signing it feels like standard terms, but later you realize how much freedom and control you gave up without noticing. Posts like this actually help people become more aware and careful, which really increases engagement and awareness in the community.
Yeah, it’s easy to miss in the moment.
Worth a careful read — IP assignment and post-termination restrictions can be easy to overlook when you just focus on the hourly rate.
Yeah, those parts often get overlooked.
Looks standard at first glance, but the non-compete is where it gets serious. Owning the work is one thing—blocking someone from working after they leave is another. More people should be pushing back on this.
Yeah, that’s where it can get much more restrictive than it seems at first.
this is more common than people think - good you’re highlighting it
Yeah, happens more often than people expect.
seen this happen more than people admit
at the moment of signing it just feels like “standard terms”, but later you realize how restrictive it actually is
that’s where most of the real cost is
Yeah, that’s usually when it becomes obvious.