Ask HN: Selling software to company I work for as an employee
51 comments
·May 21, 2025Hobadee
Since you already work as an automation engineer, it might be a bit harder since programming is probably part of your job, but this is what I did at a previous company: I wrote up a contract basically saying that since programming large programs was outside the scope of my normal work, any such programs I wrote would not be considered "works for hire" (a legal term in the US) and not property of the company, but instead my own property that I could sell elsewhere if I wanted. I was specifically allowed to use company resources to develop the software (including reasonable time my manager signed off on) and in return the company would get a non-exclusive perpetual right to use and modify the software as they saw fit.
This contract was a win-win. My company got the features they wanted as part of my normal employment, but I also got to keep the idea and monetize it outside the company if I wanted to. The company didn't need to worry about licensing if I left since I granted a perpetual right to use/modify.
Unfortunately for various reasons the project never got completed and I never monotized it, so I can't tell you the real-world outcome, but I do know we were all happy with the terms going into it.
noduerme
Mentioning that you negotiated to keep your code from falling under "works for hire" does a lot of heavy lifting in this (very well packed) example. I recommend that the OP dig into what "works for hire" means in the US to get a sense of what they should negotiate [to avoid].
It can definitely be a win/win for the company as well as for an enterprising engineer. The general idea is simply to go outside the scope of your contract and do something the company didn't ask for, in exchange for a bit of money and the right to reuse whatever code you developed for them.
Avoiding works for hire contracts is how I built a 25 year war chest of reusable components and frameworks, each piece commissioned to an individual task but each used and modified in my next jobs for my next clients, until many versions later I would update my original clients with them.
My advice to OP is to always present your ideas to owners or managers with open ears, and explain how it will help the company. Secondly, never do the work for free. Thirdly, always retain your rights to your ideas and your code when you're working on something creative. If they have a problem with that you can also explain that it's unlikely anyone else will either fill this niche to save them money or that any competitor will ever actually know about or use what you will build for them, but that having it at your disposal is a way for you to continue increasing their efficiency (which is true). It's also a way to make them beholden to you at very little initial cost.
BobbyTables2
IANAL, but if you are trying to profit from this, you’d probably have to leave the company and make the pitch from outside.
And if they think you developed it while employed, things could get nasty. Don’t want them thinking you’re selling their IP commercially either. Formalizing the idea while employed and then taking it outside could be trouble. Probably worth discussing details with a lawyer before attempting.
If you develop an MVP while employed and gain stakeholder acceptance, you likely won’t see any huge financial gains. Maybe a promotion, pat on the back, small bonus, or can enjoy the prospect this being more interesting work for a time.
jeanlucas
Using "IANAL" outside the subreddit doesn't work that well. It's a forced acronym that in the context of the community asklegal makes sense
andyjohnson0
> I see this as an opportunity to step in and sell the idea of creating frontend for this tool, however I don't want to do anything for free.
Your employer is unlikely to appreciate your trying this.
> hence I learnt about that software
Your employer paid for the software, and you learned about in on their time. They pay you a salary to work for them. Its really that simple.
Best I can imagine working is for you to suggest you initiate a project to build in-house tooling as an employee, and maybe try to get a bonus or promotion out of a successful outcome. But its their decision, not yours.
tonyhart7
I agree. I side with OP of course but bringing this topic must give mixed reaction that you don't want at work
I personally would still build it but sell that to another company
madisp
Quick suggestion: maybe contact the vendor company and offer to create a frontend for them instead as a contract thing?
---
I've gone through the exact scenarion in your question though, this is roughly the path I took (Estonia & EU, YMMV in other jurisdictions):
- start by going over your contract - is this overall even allowed? Some companies capture all IP you create 24/7, in this case you'll need to get the contract changed or get an exception
- even if your contract allows doing other work (creating separate IP) outside of company time, still ask for written permission from your manager and possibly a skip level or two. I got a written email from my VP of eng and CTO before proceeding.
- you will probably need to _completely_ separate your own work from the company work. This means using your personal laptop, never working on this during work hours, etc. Separating this sometimes can be hard, especially if you get something like a bug report from your employer - you can't work with it until you're off the clock.
- I also completely cut myself off from the purchasing decision - I let them know I was working on a project, gave them a landing page and let the purchasing team do a decision completely on their own
- if you hope to build a business out of this it's best to be upfront about it, e.g. by telling your manager that you might leave to focus on the business full-time if it takes off
All of this assumes you're on good terms with your employer overall.
GianFabien
IANAL either. I believe that UK law would be similar to that in Australia.
To the best of my understanding, as an employee the IP of all work you produce is owned by the company. Even as a contractor you need rather specific contracts if your work for hire is not to be owned by the client.
My first reaction is to advise you to let the idea go. The most likely outcome is that you will do a huge amount of work and then get caught up in legal nightmares. Getting legal advice up front won't spare you from more drama down the track.
Assuming that there are many companies that use the same software and have similar needs, then you have the option of leaving, developing a MVP and then selling it to other companies first and eventually to your ex-employer. Even then there are risks of being accused of taking proprietary information to enrich yourself. Another scenario is that the big-name company could beat you to the market with a poorly designed but aggressively marketed alternative to your solution.
mattmanser
You're wrong.
In the UK, if you develop it in your free time it's yours, as long as you don't use company equipment.
However! It can be a clause in your contract to say sompany owns IP developed in free time, and is enforceable. Sometime there's often an extra clause saying unless an exemption is approved by the board (I assume to stop hirers informally saying 'oh don't worry about that', being legally valid).
I have asked companies to remove that clause and had it removed.
In another company a friend of mine had a small side project that was making money when he joined, and that company were fine waiving the clause. But those were smaller companies who were reasonable, bigger companies might not wiggle.
ptero
IMO virtually all tech companies have such clauses that IP employees develop belongs to the company. For example to prevent employees from using their knowledge to build a competitor and and steal clients or similar products at half price. My 2c.
williamdclt
I think non-compete clauses and existing company IP are what prevent employees from doing this, not the “anything you do in your free time is our IP” clauses
chrismorgan
Yeah, it’s completely wrong for Australia too. Never actually seen such a clause in an employment contract either, though I’ve only ever worked for smaller companies. I did once encounter a legally-unenforceable non-compete which I got removed easily. (Wish there was some sort of penalty for illegal contract clauses, because of their chilling effect.)
worthless-trash
Its not completely wrong, I have seen it in two of my Australian employment contracts.
octo888
IME it's a very common contract clause
So de facto they're not that wrong (contract law is law too)
ptero
I would not do it on the sly.
Unless the company bosses are behind this idea you will need to overcome both legal problems and selling problems. For example, instead of buying your product the execs could fire you and hire someone else to do this internally. I see only three ways you might wing it:
1. Talk to your execs (ideally, the CEO) directly and sell this. On failure, be prepared to work on this internally. If so, ask for more money/promotion, which may not work but will not hurt either.
2. Call the other company and offer to improve their product for more money/promotion.
3. Get a techie friend to front for you: he approaches your company, you do the work, he shares the money. That's really grey area (being charitable). My 2c.
schnebbau
Bad idea, no one will like that.
The only way I would pursue this is if other companies have the same need, and you can sell the same thing to them too.
eCa
> I don't want to do anything for free.
It’s called ’salary’. Unless this type of thing is common in your company, it sounds weird.
Maybe float the idea to your boss that you would be willing to do something like that, if dep B starts expressing a need for it.
segmondy
I reckon a good 9 out of 10 times, this will turn out poorly. Ask yourself if you are willing to lose your job, or get sued. What if the company assigns you to the software development team and your new project is to build this. You can be promoted against your will, you can be asked to build this. If you say no, you get fired. If you say yes and fail you get fired. As someone that has been in the industry for a while, I have often seen plenty of software that my company bought that I and the team could do better, we joke about it, but we don't. If we really hate the software, we build an alternative (rarely) and give it to the company, when we have , it cemented our position in the organization.
codingdave
You sound like you want to be an entrepreneur, but are stuck working in a corporation. Because the corporate answer is: "Seeing and working on improving your organization is already part of your job. Talk to management and get a project rolling." Do it well, get promotions and raises. And then the entrepreneurial answer is to skip all that, go build it yourself, then sell it to many organizations. But you probably cannot do that as an employee, depending on your employment contract.
So sure, the surface levels answers are to talk to a lawyer, your manager, etc. But the deeper answer is to decide on and commit to a direction - are you happy being an employee, or do you need to walk out and start your own thing?
(And as a side note, don't build a startup that is a front-end to someone else's product. It may fill a need, but you are going to be spending all your hours keeping up with their changes, and ultimately your success is tied to their decisions and they could wipe you out just by spending a month improving their UX.)
DecoPerson
Just write a clear and concise summary of a contract.
“You get: [these features]”
“I get: [money and the IP]”
“We measure success and payment milestones are triggered by: [Clear KPIs and deadlines]”
Make sure the 1-2 page doc has your name on it, and ask your boss for permission to drop a paper version on the desks of the higher ups.
You can be employed and enter into a separate contract.
Edit: I just re-read the original post and saw that the OP is a software engineer. Ignore everything I said. This sounds like a terrible idea. You’ll burn all your bridges if you pursue this avenue.
williamdclt
Why would the company say yes? Seems to me they’d say “no, but that’s a good idea we’re going to have you do that as part of your employment”
DecoPerson
If it’s outside your job description, you’re not obliged to do anything.
You’re not a slave. You can say no to your boss. You’re on equal footing (though your boss generally has more power/wealth so can bully/manipulate you). It’s up to your boss as to what they do when you say no. If you’re a good employee when it comes to your usual responsibilities, then they’ll keep you.
If your boss tells you to write software as part of your job and you’re not a software engineer, you can tell them to get stuffed (or sign the contract and both parties benefit!).
Edit: I just re-read the original post and saw that the OP is a software engineer. Ignore everything I said. This sounds like a terrible idea. You’ll burn all your bridges if you pursue this avenue.
williamdclt
Yeah, OP being a SWE I don’t think many people would be convinced by “it’s not in their job description”!
They could make that into a high-visibility project showing leadership blahblah, making it into a promotion/raise opportunity rather than a $ opportunity
chiph
Dave Plummer went through this while at Microsoft. He had a product he was selling (a shell extension to handle ZIP files) and got a call out of the blue from a M&A person at Microsoft wanting to talk about purchasing it. It got strange when he told them he would walk over to their office to discuss it.
He said he pretty much took their first offer as he didn't want to endanger his position at the company.
I am based in the UK. I work as a software/automation engineer in department A. Recently, department B bought software from a big-name company which uses yaml files to steer/control automation framework (think IaC). I don't work for/with anyone in dep. B, but they showcased their new software to few different departments (including mine) - hence I learnt about that software. Now, during presentation, it came up that while controlling everything through YAML files is amazing (thanks to git versioning, webhooks etc.) it was brought up that manging 100s of files and lines of code will be difficult due to amount of places to change single value. When discussed, it was stated that there is no plans to create any frontend by that company to manage all those files and this seemed to upset a lot of stakeholders. The software has been purchased and it's going to be rolled out anyway.
I see this as an opportunity to step in and sell the idea of creating frontend for this tool, however I don't want to do anything for free. Since I don't work in this department directly, I don't know how I should approach this. Perhpas I should create MVP first and engage with some stakeholders and see if they are interested?