Solo dev in similar situation here. Agree with some of the other comments that the moat is not the code, especially in OSS.
I'm trying to find a sweet spot between the OSS part of the software and a potential premium feature set that would add enough value that people would be happy to pay for it. The OSS part becomes the validation of user need and distribution; the paid layer validates revenue.
If you couple that with great customer support you give people little reason to switch. In an age where everyone can build product, marketing/sales and customer support seems to be premium.
How we build retention with agents being the primary user/customer is another issue...
Solo dev here, shipped a security scanning SaaS where the core value is in the scoring methodology and detection logic.
These are exactly the kind of thing that looks algorithmically copyable.
What I learned is that the algorithm was never the moat.
The moat is the boring stuff around it - handling edge cases at scale, calibrating thresholds against real world data, the integrations, support quality, response time and honestly just being the project that's still maintained 18 months later when someone Googles your problem.
A large org or well known developer who clones your idea has to commit headcount to maintain it, most of them won't.
The ones who do, will move slower than you because they have stakeholders, they need to do meetings, sync and prioritize tasks.
Speed of iteration based on real user feedback is something a solo dev wins at by default, but only if you have users and you don't get users by hiding.
Open source your project, license it AGPL if commercial use worries you, but spend more time on the launch than the license.
Additionally, remember that even with licensing, the cost of protecting your licensed services can be too big to handle for solo developers and that alone can kill the project.
My personal point of view is that the thing that kills solo projects is not theft - it's lack of progress.
The moat was never really the code....it was always the understanding that produced it. All those failed experiments and design iterations that led to the algorithm... that knowledge lives in your head, not the repo. Someone can clone the implementation, but they can't clone the reasoning behind every decision you made.
The audience problem is separate from the IP problem and worth solving on its own, start writing about the problem you're solving before you open-source anything.
I prefer to write in TypeScript. The "moat" for any TypeScript artifacts is training/experience. Most people who write in this language, or especially JavaScript, cannot confidently write original code. They cannot architect, struggle to plan, and cannot navigate multi-dimensional data structures. So if you want to be safe from other humans just write in vanilla code without use of frameworks, dependencies, or code agents. The code can be exceptionally well organized, well commented with explicit instructions, and amazing clear to read and even still the idea of deviating away from a small collection of finite memorized patterns will be unforgivably emotionally traumatizing to most people who write in this language professionally.
That has down stream consequences as well. If developers feed logic they do not understand to an LLM and then use that output as though they wrote it themselves they own the consequences of those changes. Open source licenses frequently include a no warranty clause, but at the very least you can reach out to the authors and ask for guidance/assistance. No original author is going to spend their time decoding your AI slop when you haven't spent the time to understand the code in the first place.
1) If it's open source, what's the incentive to steal from you anyway? It's free. That's one of the interesting moats in the age of AI.
2) If it's at risk of being stolen/copied today, it will be the same thing 10-100-1000 days from now. There is no hiding from AI copy cats. Just put it out there and find out if someone actually will want to do it. If yes, you saved yourself a bunch of time.
> I’m a new solo dev with almost no audience. If a large org or a well-known developer sees the idea and ships a similar implementation, they can get more attention immediately than I can get in months. And in the end I get nothing for open-sourcing my project.
This has always been a fear of open source development… but in reality it’s over exaggerated, thousands of FOSS ideas are posted every day…
My advice would be to treat posting your project like a launch, and get all the readme’s, docs etc ready before posting, so it has the best chance of growing an audience, which seems to be your goal.
But if you really don’t want other people to recycle your idea, then open source is not for you…
If your open source code contains your technical barriers, then don't open source the code with those barriers—only open source the other parts.
If it's the other case, where you're worried about plagiarism, I actually don't think you need to be too concerned. I once saw an interview with Airbnb's founder Brian Chesky where he talked about how Airbnb also faced many imitators in its early days. These competitors grew rapidly too, but looking back, the difference between imitators and originals is that while imitators might get off to a quick start, they find it hard to persevere through difficulties like the original does in the mid-to-late stages. In the end, it's often the original who stuck with their vision that survives.
the painful truth is that if a big org wants to copy your approach they will, open source or not. They have the resources to reverse engineer anything from a paper or a benchmark.
I'd open source early. The community, feedback, and credibility you get compounds over time. Being first AND open builds a reputation that a clone cant buy. The algo might be replicable but being the person known for it isn't.
There is no way to protect your idea from being copied/stolen.
It happened a million times over, you have some brilliant idea, people start using it, and after a few months some big company puts 10-100 engineers on it and they do the same thing.
I would say that the key is to get to a big enough audience so they would rather buy you out than compete. Easier said than done :P
And the biggest question is: do you want to commit 100% of your time and money to building your company, or you would rather spend your time building new things?
Seriously, I think you should just do it closed source and pursue adoption by other channels. If people ask you why it's not open source, say you're not ready to manage it yet.
API security is the most common blind spot. Vibe coding tools generate endpoints fast but almost never think about broken authentication, excessive data exposure, or injection flaws. A solo dev can ship a beautiful frontend with completely exposed APIs behind it. At minimum — test your own endpoints like an attacker would before going live.
Open source but license it properly - AGPL works best if you are worried about someone making money off your idea. Honestly though with AI everything is copyable - wouldn't worry about that. Instead focus on the fastest path to get feedback and iterate
If you are building something which can be vibe-coded easily then it ofc people will create it. You can copyright a product but you can't copyright an Idea.
Selling things online was an idea by Amazon, now everyone sells online.
If you really want people not to copy your idea then make something which cannot be easily vibe-coded or copied easily i.e. which require serious skills.
Is your project a vibe-coded application? It sounds like you're insecure about someone copying your idea, which will could happen regardless of licensing if anyone has access to Claude Code and a description of your product.
If your primary motivation to use an Open Source license is gaining trust and users, you're just going to be disappointed.
Solo dev in similar situation here. Agree with some of the other comments that the moat is not the code, especially in OSS.
I'm trying to find a sweet spot between the OSS part of the software and a potential premium feature set that would add enough value that people would be happy to pay for it. The OSS part becomes the validation of user need and distribution; the paid layer validates revenue.
If you couple that with great customer support you give people little reason to switch. In an age where everyone can build product, marketing/sales and customer support seems to be premium.
How we build retention with agents being the primary user/customer is another issue...
Solo dev here, shipped a security scanning SaaS where the core value is in the scoring methodology and detection logic. These are exactly the kind of thing that looks algorithmically copyable. What I learned is that the algorithm was never the moat. The moat is the boring stuff around it - handling edge cases at scale, calibrating thresholds against real world data, the integrations, support quality, response time and honestly just being the project that's still maintained 18 months later when someone Googles your problem. A large org or well known developer who clones your idea has to commit headcount to maintain it, most of them won't. The ones who do, will move slower than you because they have stakeholders, they need to do meetings, sync and prioritize tasks. Speed of iteration based on real user feedback is something a solo dev wins at by default, but only if you have users and you don't get users by hiding. Open source your project, license it AGPL if commercial use worries you, but spend more time on the launch than the license. Additionally, remember that even with licensing, the cost of protecting your licensed services can be too big to handle for solo developers and that alone can kill the project. My personal point of view is that the thing that kills solo projects is not theft - it's lack of progress.
The moat was never really the code....it was always the understanding that produced it. All those failed experiments and design iterations that led to the algorithm... that knowledge lives in your head, not the repo. Someone can clone the implementation, but they can't clone the reasoning behind every decision you made.
The audience problem is separate from the IP problem and worth solving on its own, start writing about the problem you're solving before you open-source anything.
I prefer to write in TypeScript. The "moat" for any TypeScript artifacts is training/experience. Most people who write in this language, or especially JavaScript, cannot confidently write original code. They cannot architect, struggle to plan, and cannot navigate multi-dimensional data structures. So if you want to be safe from other humans just write in vanilla code without use of frameworks, dependencies, or code agents. The code can be exceptionally well organized, well commented with explicit instructions, and amazing clear to read and even still the idea of deviating away from a small collection of finite memorized patterns will be unforgivably emotionally traumatizing to most people who write in this language professionally.
That has down stream consequences as well. If developers feed logic they do not understand to an LLM and then use that output as though they wrote it themselves they own the consequences of those changes. Open source licenses frequently include a no warranty clause, but at the very least you can reach out to the authors and ask for guidance/assistance. No original author is going to spend their time decoding your AI slop when you haven't spent the time to understand the code in the first place.
1) If it's open source, what's the incentive to steal from you anyway? It's free. That's one of the interesting moats in the age of AI.
2) If it's at risk of being stolen/copied today, it will be the same thing 10-100-1000 days from now. There is no hiding from AI copy cats. Just put it out there and find out if someone actually will want to do it. If yes, you saved yourself a bunch of time.
> I’m a new solo dev with almost no audience. If a large org or a well-known developer sees the idea and ships a similar implementation, they can get more attention immediately than I can get in months. And in the end I get nothing for open-sourcing my project.
This has always been a fear of open source development… but in reality it’s over exaggerated, thousands of FOSS ideas are posted every day…
My advice would be to treat posting your project like a launch, and get all the readme’s, docs etc ready before posting, so it has the best chance of growing an audience, which seems to be your goal.
But if you really don’t want other people to recycle your idea, then open source is not for you…
If your open source code contains your technical barriers, then don't open source the code with those barriers—only open source the other parts.
If it's the other case, where you're worried about plagiarism, I actually don't think you need to be too concerned. I once saw an interview with Airbnb's founder Brian Chesky where he talked about how Airbnb also faced many imitators in its early days. These competitors grew rapidly too, but looking back, the difference between imitators and originals is that while imitators might get off to a quick start, they find it hard to persevere through difficulties like the original does in the mid-to-late stages. In the end, it's often the original who stuck with their vision that survives.
the painful truth is that if a big org wants to copy your approach they will, open source or not. They have the resources to reverse engineer anything from a paper or a benchmark.
I'd open source early. The community, feedback, and credibility you get compounds over time. Being first AND open builds a reputation that a clone cant buy. The algo might be replicable but being the person known for it isn't.
There is no way to protect your idea from being copied/stolen.
It happened a million times over, you have some brilliant idea, people start using it, and after a few months some big company puts 10-100 engineers on it and they do the same thing.
I would say that the key is to get to a big enough audience so they would rather buy you out than compete. Easier said than done :P
And the biggest question is: do you want to commit 100% of your time and money to building your company, or you would rather spend your time building new things?
Vibe litigation
Seriously, I think you should just do it closed source and pursue adoption by other channels. If people ask you why it's not open source, say you're not ready to manage it yet.
API security is the most common blind spot. Vibe coding tools generate endpoints fast but almost never think about broken authentication, excessive data exposure, or injection flaws. A solo dev can ship a beautiful frontend with completely exposed APIs behind it. At minimum — test your own endpoints like an attacker would before going live.
Open source but license it properly - AGPL works best if you are worried about someone making money off your idea. Honestly though with AI everything is copyable - wouldn't worry about that. Instead focus on the fastest path to get feedback and iterate
If you are building something which can be vibe-coded easily then it ofc people will create it. You can copyright a product but you can't copyright an Idea.
Selling things online was an idea by Amazon, now everyone sells online.
If you really want people not to copy your idea then make something which cannot be easily vibe-coded or copied easily i.e. which require serious skills.
Is your project a vibe-coded application? It sounds like you're insecure about someone copying your idea, which will could happen regardless of licensing if anyone has access to Claude Code and a description of your product.
If your primary motivation to use an Open Source license is gaining trust and users, you're just going to be disappointed.
I vide-coded some, but the core is hand-craft arch/algorithm, that's the most valuable part I want to protect.
Then it's already gone to AI servers. They slurp your codebase.
totally agree
see also: https://ryelang.org/blog/posts/cognitive-dark-forest/
(posted on HN a couple of weeks back)