Ask HN: How to protect against non competes? | Hacker News Reader

Ask HN: How to protect against non competes?

6 pointsflying_colours9 comments

Hey HN community! Again thanks everyone for your help back at https://news.ycombinator.com/item?id=31683412 Much appreciated! So sorry I haven't been able to respond to everyone's messages - thanks again though!

For context, I've been doing some engineering consulting and other work for people. With the help from HN, I've been armed in negotation, and everyone's advice was super good! I can know easily and swiftly tell people what we're worth per hour! It was super hard at first, but it really helped!

So recently a startup with no cash, no funding came up to me to ask me to create an AI product. I managed to create a mini demo, in which they showcased this to investors and they were very impressed.

However we chatted about a contract between us. I came to understand that they're offering 15% to me, with the 3 founders taking 85%. I was trying to negotitate a higher equity portion, since I believed the work I did was worth much more than 15%. They don't seem to want to budge.

They then mentioned a non-compete clause, in which I declined. I run a consulting arm, so it's nearly impossible for me to sign a non-compete clause. That's essentially locking us out of future roles.

They then mentioned on time committment, however, it's near impossible if they're asking me to be a cofounder to determine "how many" hours. I told them I have other consulting roles, and so time commitment will be random. However, I've already spent 40 hours or more working on the product.

I mentioned another alternative solution which was contracting or freelance. I charged them the market rate * the hours we offered, but they seem to not want that either.

I told them very clearly it's extremely difficult to find an engineer to do any software work, yet they feel like the components I'm doing aren't valuable. I assume they're trying to undervalue the work.

I'm in an extremely confused and depressed position. I'm not too sure what to do anymore! I suggested if nothing works out, then the code is protected since no contract was written.

What should I do in this situation? Thanks again to the wise HN community! It feels like I'm been used again. I tried this time - I guess a mistake is I should have at the start wrote a contract, and not 40 hours of work later.

This does not sound like a relationship that will work out. What you want and what they want do not overlap.

You want partial infequent engagement while keeping your other projects going. They want a fully engaged cofounder. Neither side is wrong, but you do not want the same things.

Ye - it seems like it won't work out for us oh well.

> So recently a startup with no cash, no funding came up to me to ask me to…

Why would you sign a contract with people who have nothing to protect except your work?

Do they have a copy of the source or any ability to reproduce your work? If not, just take your ball and go home.

Ye I did share some of the code - it's not fully functioning yet. I have now unshared the stuff temporarily until we lock in a contract.

Sounds like a terrible client. I suggest finding new clients after leaving this one.

Oh well! It feels like the partnership / relationship is very one sided.

I wrote a mini-thread you might like: https://twitter.com/jugurthahadjar/status/131066829330549965...

I'll reproduce it here:

0. Form:

0.0. It pays to provide services through a company. Companies write large checks to companies without blinking; not so large for individuals.

1. Contracts:

1.0. Get a lawyer to prepare contracts for collaborations. Someone at some point might disagree or have trouble remembering what they have agreed to pay you, make sure to have a mnemonic device in the form of a clear contract.

1.1. Companies have typical contracts for collaboration: don't sign anything without legal counsel.

1.2. Retain intellectual property to amortize engineering and sell what you make to others.

1.3. Companies might ask that you do not sell to competitors: define them and contain geographic zone and duration. Get paid for the opportunity cost.

1.4. Split project into tranches for which you get paid. This can help cash-flow and reduce risk, especially in the beginning.

2. Presentation:

2.0. Your company solves problems and being open minded about these problems is useful; so it's not much about finding problems for your solutions, but more like finding solutions to clients' problems.

2.0.0 After enough problems you built solutions for, patterns emerge and you can abstract a solution that serves several use cases. See "Abstraction" section.

2.1. General presentation with broad strokes of your capabilities, including previous work with other clients

2.2. Conversation with the prospect on their worries in a given space

2.3. Conversation with the prospect on their worries in a given space

2.4. Extract problems from that conversation and send a list of N problems to solve/ideas to explore.

2.5. The client finds one problem urgent/highest priority/highest value

2.6. You get together and talk about "desirability, fasiblity, viability".

2.7. Once you agree on what to do, prove the concept.

2.7.0. e.g: organizations give us data and ask us to predict something, say customer churn or subway car malfunction. We return predictions, they validate the predictions, and we can then start the project because they have proof we actually can predict what they want us to.

3. Execution:

3.0. Your opinion on what is valuable for the client does not matter. It doesn't have to be valuable to you, only to the client. A client who gets excited by a functionality that took one hour to implement because it solves a real problem is a learning experience.

3.1. Go above and beyond. Some sectors/clients are hard to get in, but once you're in, you're in.

3.2. Listening and assuming the client is smart goes a long, long, long way.

3.3. Send meeting notes to the client. It clears ambiguities during/after the project.

3.4. Press to get the client's domain experts' collaboration. They will actually use what you're building. Get them at the table.

3.5. Some of the most valuable insights are gleaned after a meeting and not necessarily with your "counterpart".

Don't build the wrong thing.

4. Abstract:

4.0. When you solve many problems, some patterns emerge. You built custom products for your clients, but you can abstract functionality and build tooling to scale your services, and enable others to do the same.

4.0.0. e.g: we we built machine learning products for enterprise clients. After many projects, we built iko.ai, our own machine learning platform to "Get Data Products Released".

4.1. One advantage of this approach is to explore the space while being profitable. Some problems exist not for lack of a nice front-end or lack of knowledge of the target audience. Coming at them from a purely "webdev"/"devops" mindset can bring bad surprises.

All the best,

OMG thanks so so much! This is a super rich list! Thanks so much again!

Agreed totally on getting a contract done. Lawyer maybe necessary, but for now, we're explicity writing down scenarios and possibilities, who owns what, what happens if I get fired etc.

Agreed on finding a common thread amongst the people we help. The goal is to convert the learnings we have into a product, then sell this product to everyone else.

Reply on news.ycombinator.com