Ask HN: We are shutting down our startup, I get our code. What now?
My co-founder recently decided to shut the company down, focusing on what he/she does best rather than being reliant on tech/design loops by making our amazing designer create a Shopify site that he/she can manage him/herself.
Without going into details, it is fair but we will need to have serious talk once everything has settled so I can move forward.
Anyhow, as my payment for these past years, I get to sell whatever we have created, code wise, and get the dough for it.
The problem is that I have no clue how to properly handle a sell like this.
There is a bunch of new startups that has recently popped up, doing what we initially did with a caveat; they lack an app for it, currently hustling to make things work. So there might be a pretty good possibility for us to sell it.
To give you an idea what we are doing; an React Native app that sell and connect a very specific type of workshops with costumers over custom WebRTC Video chat(fork of React Native-based Jitsi Meet). What I can tell, I haven't seen another custom Jitsi-Meet integration yet that gives the ability customize the UI that we have.
We use Firebase as our backend and Stripe as our payment integration. Data entry / workshop scheduling is managed using a custom built CMS. We have custom emails + in-app notifications work through Firebase Cloud Functions.
Should I contact these startups? Anything I should do first, legally wise?
I'm clueless.
227 comments
[ 3.2 ms ] story [ 228 ms ] thread- Decide who gets the data: users, you, someone.
- Sanitize servers and services by trying to overwrite data with junk values before canceling.
- Cancel monthly services and free services.
- If it was good, don't let the team relationship go to waste. Talk with whoever's left / worked-with previously about doing something else.
---- Then and only then ----
- Do "consultingish" work or solve a problem you have to find a problem worth solving.
- Sell something good people want before you invest too much time/money/mental health building something too much.
- Keep it real: building "your amazing idea" without a feedback loop gathering critical data from paying/potential customers is #fail.
- Someone though will have to step-up to be the sales/buzz builder or one will need to be found (hopefully, someone you've known for some time or a friend-of-a-friend). No useless "idea guys" allowed.
- Sales/buzz person or someone will need to be the captain of the ship ultimately in-charge of everything.
- Iterate fast, executing based on feedback and sales numbers. Prefer the best one you can get into if you can. (YC, hihi.;)
- Everyone at the beginning gets equal equity vested over 3-5 years. First employees should get ~1% equity, more if it's an employee-owned co-op.
- Don't pray for funding, sales/profit cures all.
- Raise funding only if you could definitely grow faster with more money.
- Skip accelerators unless you need a network and/or are relatively inexperienced.
- When you get big enough, incorporate (California or Delaware C-corp). If it's s consultancy, LLP or LLC. https://clerky.com
> If it was good, don't let the team relationship go to waste. Talk with whoever's left / worked-with previously about doing something else.
Some of my best times at work have come from the relationships left after the company crashed and burned. Companies disappear, people don't have to.
All it takes is one oops at a client to have a $1m judgement hanging over your head. LLC (in your state, don’t get fancy) sooner than later. Business insurance is typically another $500-800/yr for software startups, but I wouldn’t recommend that until you have something to protect (like money in the bank)
I.e. not the formation, but year to yeat maintenance?
Similarly, as a single-person company, any action that could cause liability was presumably performed by you, personally. That makes it much easier for a litigant to sue you personally instead of/in addition to your company.
Creating one can help enforce some separation too: different bank accounts, different AWS accounts, etc. This feels pretty good, unless the company is some tax dodge which also places increased transparency on some things.
Whatever someone does, they can make a fair attempt at running their business professionally and it will limit significant risk and liability. This means taking boring paperwork and bureaucracy seriously. It means recognizing mistakes and fixing them before they get serious. Good companies don't generally get sued and lose. You can also seek outside advice so that you make better decisions. When you take reasonable measures these will get recognized when you are in a situation.
“ Personal Liability for Your Own Actions
There is one extremely significant exception to the limited liability provided by LLCs. This exception exists in all states. If you form an LLC, you will remain personally liable for any wrongdoing you commit during the course of your LLC business. For example, LLC owners can be held personally liable if they:
personally and directly injure someone during the course of business due to their negligence fail to deposit taxes withheld from employees' wages intentionally do something fraudulent, illegal, or reckless during the course of business that causes harm to the company or to someone else, or treat the LLC as an extension of their personal affairs, rather than as a separate legal entity. Thus, forming an LLC will not protect you against personal liability for your own negligence, malpractice, or other personal wrongdoing that you commit related to your business. If both you and your LLC are found liable for an act you commit, then the LLC’s assets and your personal assets could be taken by creditors to satisfy the judgment. This is why LLCs and their owners should always have liability insurance.”
Your advice to register an LLC is very good. I’ll add:
1) Costs are very state specific. And if you register in the state you live in you can act as your own registered agent and eliminate a lot of the yearly fees. In my state I can register directly for $90 with the Department of State (of my state, not federal) and there are no recurring fees.
2) Follow the rules by keeping all finances separate or you might as well not have registered the LLC.
I would be interested if anyone knows more about how the co-op idea would work, also assuming you took investment. Would a corporation be formed as well as a co-op, and the co-op would be a shareholder in the corporation?
When it comes to making decisions many employees won't care too much about the direction, and will slow down the process.
Give your employees a fair share, but keep ownership amongst the founders.
2 Structure the way I have seen this work the coop owns the company (or a controlling interest) which employs the members of the coop
Coop structures can get complex normally most countries have special laws for this and it can be tax advantageous.
Coops can take outside investment but they have to maintain 50% +1 shares to remain a coop
The idea is: shares aren't devided by capital, but by heads.
But you can usually add some clauses to the contracts, that people have to work for some kind of period, before they are considered "comrades".
If they wanted a detailed question of what to do AND WHY, they could pay a consultant. A consultant would go over around the same points as duelingjello, but also explain why. As an Internet forum answer, it honestly goes above and beyond.
The answer basically strips into two -- first get rid of any and all 'ball and chain' from the old company, existing customers setups and data. Then put the IP to work, making money.
The answer does skip over the general unasked question of "Can I just sell the code?" to which the answer is generally "no." You'd need an existing enterprise or source that knows the code, wants the code and can use the code, which in the modern age is just not going to happen: Startups come and go and everybody wants to make their own solution. Most engineers I know would look at "existing code" as bloat or a hindrance in general, and would look at it as "a sales team problem." If anything, you'll get peanuts for selling the actual code itself.
Building a new enterprise that has a technical team to handle the code and a sales team to sell the code, potentially with an existing customer base sounds like a much better plan. Does it involve risks? Yes. Does it still answer OP's question of wat do? Absolutely.
A side note here: that can be impossible on a cloudy service where your data may have moved between many nodes over its life, and difficult to guarantee in other circumstances. On future projects consider encryption at rest for all data then all you have to worry about is destroying all copies of the relevant keys. Still try a wipe at the end of course, in the name of security in depth, in case there are keys errantly floating around out there.
If you are performing a secure wipe, don't go OTT with 37 sequenced passes (if your threat model "requires" that then you have other matters to concentrate on!) don't make the final stage zeros: fill the volumes with cat pictures/videos, or if you are feeling evil use shock images instead. Give the cracker that tries to poke around something to look at!
> ... and services by trying to overwrite data with junk values before canceling
Also impossible unfortunately, though again you should try if only to show due diligence. Always assume that once your data is out there it is out there for good. Just like a delete is not often a real delete (just a soft delete where a "deleted" flag is set), an update often only affects the current value leaving it and any previous values still present in history or audit structures.
(not that I'm saying this piece of your advice is bad, I just feel it just needs a few caveats to be explicitly stated)
For certain types of data and with experise, it might be wise to run your own servers (colo) and encrypt the drives. After surviving to a certain scale, you'll want to save money by running hybrid bare metal+cloud anyhow. Then, you'd have control to nuke your servers (DBAN), local snapshots and encrypted backups. Hybrid infrastructure should allow pinning systems to prevent migrating to or sending snapshots to third-parties.
Aye. While guaranteeing the information is absolutely gone is often impossible, you should at least do what you can make it more difficult to retrieve or be accidentally revealed.
> and encrypt the drives
If you are using VMs then full disk encryption within the VM will work just as well, and most cloud services can offer effectively the same thing with their containers.
You just have to be very careful with key management, which in some cases may be inconvenient (blocking restart until you intervene to provide keys, if you don't want them stored on or directly accessible by the same provider) depending on how paranoid you feel the need to be. Of course if you are truly paranoid, by character or by contractual necessity, keys in memory on shared infrastructure even temporarily could be an issue at which point you need "dedicated cloud" resource or colo/self-host for the affected parts of your apps/infrastructure.
Thank you duelingjello. I have a lot to learn and it's becoming obvious I need some time to grow and this will definitely help me.
If there's no interest though, then any upfront work you do now will be wasted effort.
Is the stripe integration in react-native? If so, I think it would be great to open source it and publish to npm. There really isn't a good react native stripe library out there, the only one I have dealt with is tipsi-stripe[1] which is poorly documented, poorly maintained and inflexible.
If you really don't want to open source it, I'd love to chat about buying it off you.
[1] https://github.com/tipsi/tipsi-stripe
Yikes, it sounds like you are walking away here with virtually nothing.
If I were you, I would fight for ownership in whatever is next for your cofounder. If that means it is a Shopify store, that is fine, but you should get X% of revenue, profit sharing, something out of this.
The code you have now is ultimately worthless and is not a good 'payment' for the time and energy you invested into this company.
I do not think the current arrangement you have outlined is in any way fair.
Companies are so keen to keep their own code, but most don't realise it would be useless to anyone else.
The more you know...
If the new venture is actually completely separate (or no more related than "In the process of trying to launch business X and failing, I realized that a very different business Y would be more profitable"), then yes, I agree with you.
As for the code, I wouldn't touch it after the original company ceases. The code belongs to the entity that created it and when its gone, the code is gone. If you start something new from this code and it becomes successful, guess who is going to come out of the woodwork and want a portion of it? Yes, the same guy who likely would deny you anything from his new venture.
I've been in this situation and when you've written so much code, and it's good. It's painful to separate from it. I also flip houses and there are times when it's time to just sell the house already and I almost feel sad that I'm not going to get to work on it anymore. Sometimes I feel remorseful that I won't get to see all my good work after its sold. But here's the thing, if I don't sell it, I won't replenish the capital I need to do more. And in the software sense, if I don't move on from a project after its done, I will continue to mentally and physically labor on a work that is producing nothing. And if it does do something, you'll forever be looking over your shoulder for that cofounder who will sue you for a portion of it.
All this said, there are a couple of alternatives you can consider.
#1 is to simply agree with the founder that the company should open source the code base. This gives you the benefit of letting future employers, cofounders, coworkers, etc seeing your work. And this benefits him too as being associated with the project. it puts a coda on the project so that the work you did doesn't just disappear into vapor.
# 2 you should consider both signing separation agreements and put it in writing that everything is over and there are no claims on work product, intellectual property, etc.
This is literally the reason lawyers exist. It’s not hard to draft up an agreement where the former co-founder transfers all rights and ownership and relinquishes any claim to the technology.
Exactly and this market validation has value for the "new" company. It's also not clear whether or not OP got paid during their two year jolly.
Therefore it's ridiculous to say OP deserves a % of revenue/profit/equity of their co-founders next venture. There's no legal or ethical basis for negotiating this.
But from the OP it sounds like the cofounder might be continuing in the same line of business, but wants to "pivot" and jettison the now-dead weight of the technologist.
If this is the case it seems plausible that his contributions and R&D are still relevant, even if they're throwing out his code, and so perhaps he's entitled to whatever stake he vested over those first two years.
If the co-founder is taking just knowledge, best-practices, know-how, and life experience, then the other co-founder does not have any legal basis to expect anything.
Just because your startup is worthless doesn’t mean you get a percentage of your cofounders next business. That’s ridiculous.
The business's legal structure is being closed and shut down. OP only has claim over how the assets of that legal structure are distributed.
If his partner goes on to start a new business in the same niche to do the same thing, legally and ethically there's nothing he can do or claim.
The business's legal entity is being shut down and closed. The OP only has claim over assets of that business. If he agrees to certain assets being given to the other partners, he has no claim for the future use of those assets.
Depends on whether the cofounder is using the current company's assets towards the next venture (and it seems like the answer is no, so there is really no basis for that ask).
Take a loss on this startup and move forward to something new.
Unless this IP or "Code" was written by someone else let it die on the vine with the rest of the company, write new code for your own project, use your experience to make improvements to the new code and start fresh, it sounds like you were using pieces of gpl code anyways.
Why would you bother taking the risk of creating a unicorn only to have your pokects picked by your "cofounder" that quit, then sues once it becomes profitable?
No matter what agreement you made, even if you get it notarized, your risking much more than if you just knuckle down and do the work again yourself.
Besides it's always easier and faster to do it a second time.
If you sell your code, the most it would probably fetch is somewhere in the low three digits, and it would probably be snapped up by someone who doesn’t care about the business they just want to have a beefy open source project as part of their resume or portfolio (which is basically the smart way to get open source credibility without toiling for years to no end, think about it, 300 bucks buys two years of open source experience).
If I were you, I’d beat them to the punch and open source your project and move on with your life, let others maintain it and maybe make it into something great.
What's your co-founder walking away with? If they're walking away with cash and your walking away with (non patented) IP then you got the short end of the stick.
A bunch of Reddit employees broke off years ago and started a company called Imzy, the CEO decided to shut it down and took ownership of the source code, which he then sold to someone (I want to say techcrunch) for precisely 1 million dollars.
Source: I worked with one of the cofounders of Imzy and he spilled all the tea, that's the best I got though.
https://news.ycombinator.com/item?id=14411586
As others mentioned, be sure you have clear and unhindered rights to the code and IP.
Otherwise, take your knowledge and skills and do consulting work (maybe for one of those competitors). Even if you walk away with no remuneration, you have great hands-on experience in a production environment.
For the price of hiring a react developer to make modifications + the cost you are better off letting the react developer only build what you want
...and so it becomes a huge gamble to pay for technology that doesn't have an active an immovable revenue stream.
That takes some customization, but he's not talking about a software product, he's talking about what amounts to a professional services integration of several existing products. Consulting gigs like that can make you money for your time, but the end result is too specific to the situation with too few lines of original code to have much/any value.
If OP hasn't been paid for his work and it's being suggested this software is his pay, then I'm going to agree with other posters and say his co-founder is just dumping him and walking away with anything worthwhile, including the percentage of the corporation OP had which might be worth $$$$ or $0 in the future depending and leaving him with worthless code... and if there's a no-compete written into the sunset agreement for him, he probably can't even use the code, sell it, or consult with it.
If you open source it today, and give it away completely for free, you will be lucky if one person forks or stars the repo, then never looks at it again.
Speaking as someone who not only invests in websites but authored some early studies on the fair value of micro-sites (back in 2012) that deal is utterly bogus.
The value of the business is in the traffic and audience, not the code. To be honest, getting rid of the legacy code and moving the site onto my standard platform is a major goal of the early integration process. I do not pay for code (sorry).
What you have been handed is the back-end of a potential product, the market value of which is unproven (since you haven't been given the customers). While I'm sure the technical quality of the work is excellent, there are multiple strikes against it from a business valuation perspective. Fight for your share of the store profits.
- A B2C Shopify store, with the former traffic / audience
- Some kind of e-commerce platform (not yet a business)
To your point, if they were not already actively trying to market the code as a platform, this is an EXTREMELY hard reset for the second project and your best hope (if you're going to continue this path) is negotiate an acqui-hire.
Speaking as an investor again, the commercial side of the second project sounds like a potential goat rodeo. You're basically dealing with the sales cycle for selling a B2B infrastructure product (specialty e-commerce backbone) to small companies...
Guessing at the market size, you would need an average installed price north of $5 K to make a business viable which means you need a B2B outside sales team. Given that you're selling to startups, suspect getting above $100 K ticket price is a challenge. Strong likelihood of issues with customer acquisition costs > contribution margin.
Again... hand waving BS about the business I haven't seen, but much caution would be advised. The other guy definitely grabbed the crown jewels of the remaining business.
Dump it and start something new.
It's a sunk cost.
I've got vast amounts of code from previous projects. All worthless.