Ask HN: Do you worry about copycats when building a project?
16 comments
It's literally a non issue. Once you start development, you'll run into so many issues, that you'll simply forget about it.
Building the right team is very very hard, finding investors is very hard, finding users is very hard -- just tackle the issues at hand.
If you're not technically competent, that is probably your biggest issue - because you may think you found the right team, while you probably haven't. Using bad programmers will hurt you in insane ways in the long run. Depending on the complexity of your app, if it's made by bad/ignorant programmers, and it turns out to be successful, it's very likely you'll need a full rewrite along the way.
Building the right team is very very hard, finding investors is very hard, finding users is very hard -- just tackle the issues at hand.
If you're not technically competent, that is probably your biggest issue - because you may think you found the right team, while you probably haven't. Using bad programmers will hurt you in insane ways in the long run. Depending on the complexity of your app, if it's made by bad/ignorant programmers, and it turns out to be successful, it's very likely you'll need a full rewrite along the way.
Big companies in your industry won't even notice you until you take one of their Top 50 customers, and by that point you're probably well into single digit millions in ARR if not tens of millions. Small companies in your space may pay attention to you if you raise >$1M or start to show up in a lot of deals. No one else will care at all, especially customers, unless one of those milestones are met. If it's that easy to copy what you're building, it probably isn't an expensive enough problem to sustain a business. Execution and maintenance are so much harder than building an MVP, even if someone copied the MVP chances are sustaining support and their finances will crush them.
No. If it were easy, lots of people have already done it earlier. I've never seen a pure copycat do well; anyone who is copying features instead of talking to customers rarely understands it enough to build better products.
Even if someone does copy you, it grows the market, at least for startups. Fashion buildings are often located next to each other, as well as book stores, hardware stores, and so on. Startups have a problem with market awareness, so the more competitors the better. Competitors also greatly reduce the cost of failure - being close to a competitor gives you the option of mergers, acquisitions, and maybe even getting a high level job within one should you fail.
You can look at companies like Rocket Internet, which is the best in the business at this. But they have high fail rates, and have failed to outdo Airbnb and Uber. They also look at fields that are easy to throw money at and large markets, like e-commerce, ride hailing, food delivery, groceries, meal prep. Unless yours is a trillion dollar industry, it probably won't be tackled by someone competent.
However, there is one thing you should worry about - domain name squatters.
Even if someone does copy you, it grows the market, at least for startups. Fashion buildings are often located next to each other, as well as book stores, hardware stores, and so on. Startups have a problem with market awareness, so the more competitors the better. Competitors also greatly reduce the cost of failure - being close to a competitor gives you the option of mergers, acquisitions, and maybe even getting a high level job within one should you fail.
You can look at companies like Rocket Internet, which is the best in the business at this. But they have high fail rates, and have failed to outdo Airbnb and Uber. They also look at fields that are easy to throw money at and large markets, like e-commerce, ride hailing, food delivery, groceries, meal prep. Unless yours is a trillion dollar industry, it probably won't be tackled by someone competent.
However, there is one thing you should worry about - domain name squatters.
> Even if someone does copy you, it grows the market, at least for startups.
Thanks for showing me a totalizing view. This is another thing I should keep in mind.
> No. If it were easy, lots of people have already done it earlier. I've never seen a pure copycat do well. > Unless yours is a trillion dollar industry, it probably won't be tackled by someone competent.
When I saw the first the argument, I was gonna say Apple is one, and it beat Xerox spectacularly (I'd hazard it was a pure copycat, the whole selling point of Mac was the GUI), but the second told me I wouldn't have such a mighty competitor since I certainly don't have an original idea like that and is definitely not in the trillion dollar industry. But I think a competitor as at much lower level of competence can still make me nervous.
Let's do a thought experiment. Let's say I anticipate IPv6 support will be a highly requested feature, yet I don't really understand it well to implement related features. Should I make myself well-versed in IPv6 before release a MVP (could take a long time)? Or release it first but then spending a lot of time learning it and make users wait, giving competitors opportunities to implement it first (I think many many developers/teams are well-versed in IPv6).
Making users wait is itself another concern I mentioned in the earlier reply.
Thanks for showing me a totalizing view. This is another thing I should keep in mind.
> No. If it were easy, lots of people have already done it earlier. I've never seen a pure copycat do well. > Unless yours is a trillion dollar industry, it probably won't be tackled by someone competent.
When I saw the first the argument, I was gonna say Apple is one, and it beat Xerox spectacularly (I'd hazard it was a pure copycat, the whole selling point of Mac was the GUI), but the second told me I wouldn't have such a mighty competitor since I certainly don't have an original idea like that and is definitely not in the trillion dollar industry. But I think a competitor as at much lower level of competence can still make me nervous.
Let's do a thought experiment. Let's say I anticipate IPv6 support will be a highly requested feature, yet I don't really understand it well to implement related features. Should I make myself well-versed in IPv6 before release a MVP (could take a long time)? Or release it first but then spending a lot of time learning it and make users wait, giving competitors opportunities to implement it first (I think many many developers/teams are well-versed in IPv6).
Making users wait is itself another concern I mentioned in the earlier reply.
I think it's fine to make users wait, or even give them a poor experience. I usually go for things were users have already hacked together a solution; the alternative is that they keep hacking even if they'd rather just outsource the work to someone else. If you're working in a field where plenty of competitors have IPv6 support, then copying isn't really your main problem.
You could simply release it first, then add support later when there are a lot of complaints on it. My preferred approach is to avoid paid marketing until there are no more complaints, but launching should happen early to collect complaints.
You could simply release it first, then add support later when there are a lot of complaints on it. My preferred approach is to avoid paid marketing until there are no more complaints, but launching should happen early to collect complaints.
Correct me if im wrong but Xerox wasn't an apple competitor. Wozinak tried very hard to convince Xerox to go in to the computer space but they didn't decide to. Also Apple became a trillion dollar company not because of the idea but by execution.
I think your concerns are very valid. However, I also believe that the target market for your product makes a lot of difference. The two extremes are:
Your target market is non-technical, then demonstrating your MVP to potential customers should help validate your idea. The feedback will ensure that you build the most important features first and thus start delivering value to your customers. NB: a customer is somebody who pays for your product. Non-technical prospects are more like to focus on their core competencies and not be inclined to copy something that they could simply buy.
Your target market is other developers or IT users, then the chance that your MVP might be copied becomes much higher.
Your target market is non-technical, then demonstrating your MVP to potential customers should help validate your idea. The feedback will ensure that you build the most important features first and thus start delivering value to your customers. NB: a customer is somebody who pays for your product. Non-technical prospects are more like to focus on their core competencies and not be inclined to copy something that they could simply buy.
Your target market is other developers or IT users, then the chance that your MVP might be copied becomes much higher.
> I know people keep saying you might build the wrong project so you should release early. But what if I'm building the right project?
The odds that someone else iterates on your idea aren’t zero, but they’re very close to zero. In practice, usually nobody else cares about your new thing enough to use it, let alone copy or improve upon it.
OTOH, the odds that you need to iterate a few times before you have something that people want are greater than 50%.
So, you don’t need to convince yourself that a competitive product isn’t a risk, nor that you’ll be able to handle a competitor if one emerges. Merely accept that the risk of making something that doesn’t serve a market is way higher - probably by 10x or more. Going from 50% chance of making something useless to 25% - by seeing how users react to your product - is worth increasing the chances of a copycat from, say, 1% to 2% (or even from 2% to 10%, though I don’t think 10% is likely).
The odds that someone else iterates on your idea aren’t zero, but they’re very close to zero. In practice, usually nobody else cares about your new thing enough to use it, let alone copy or improve upon it.
OTOH, the odds that you need to iterate a few times before you have something that people want are greater than 50%.
So, you don’t need to convince yourself that a competitive product isn’t a risk, nor that you’ll be able to handle a competitor if one emerges. Merely accept that the risk of making something that doesn’t serve a market is way higher - probably by 10x or more. Going from 50% chance of making something useless to 25% - by seeing how users react to your product - is worth increasing the chances of a copycat from, say, 1% to 2% (or even from 2% to 10%, though I don’t think 10% is likely).
> Going from 50% chance of making something useless to 25% - by seeing how users react to your product - is worth increasing the chances of a copycat from, say, 1% to 2%
This is a very good argument for not worrying about copycats during MVP. I'll keep that in mind.
But what about users? You talk with users, and tweak the product accordingly, they like it, and then they want a new feature, and it's also on the feature list, but very difficult to implement. What do you do? Just make them wait as long as it needs or should I make sure that before releasing a MVP, I at least have the technical capacity to implement all the features that are challenging (at the cost of delaying shipping, probably significantly)?
I forgot to mention my averse to making users wait is also part of what worries me. I wonder if such concern is warranted?
This is a very good argument for not worrying about copycats during MVP. I'll keep that in mind.
But what about users? You talk with users, and tweak the product accordingly, they like it, and then they want a new feature, and it's also on the feature list, but very difficult to implement. What do you do? Just make them wait as long as it needs or should I make sure that before releasing a MVP, I at least have the technical capacity to implement all the features that are challenging (at the cost of delaying shipping, probably significantly)?
I forgot to mention my averse to making users wait is also part of what worries me. I wonder if such concern is warranted?
> Just make them wait as long as it needs
Yup[1], or explain to/convince them they don't actually need the feature, or use the money paid by happy customers to pay someone to implement it, or conclude that demand is so strong that it's worth raising capital to serve them sooner.
Operating a business is doing that over and over, hundreds of times, for years.
Especially for a bootstrapped business, the need to do that will actually _increase_ during the business's lifetime - and that's if you're fortunate. When you no longer need to tell even more prospective customers "No," that's an early sign that you're serving almost the whole market and that growth (and the chance to solve neat problems) will slow down.
If you're succeeding, lots of prospective customers will always want something you don't have. There will always be larger companies that could - and you believe should - easily invest more in your field than your whole business spends.
Here's a personal example. I ran a log management service that had no graphing/visualization service - for 5 years. It launched way back in 2012 (https://www.businesswire.com/news/home/20110609005940/en/Clo...). If you'd asked me then whether it wouldn't get native graphing until 2017 (https://blog.papertrailapp.com/lightning-search/), I'd have said you were crazy - maybe even that it wasn't possible to exist that long without it. In those 5 years, I probably addressed that topic 500 times. Sometimes I explained why it wasn't necessary to solve the prospective customer's problem, sometimes I stated that my product wasn't a good fit, sometimes I tried to reduce the need for that feature (like by supporting external graphing services, which was a small enough amount of work that our tiny team could implement a great version: https://blog.papertrailapp.com/new-search-alerts-dashboard/).
But… our choices were sound and they worked out (though I assume there were >1 viable paths, not just the route we took). We had tons of demand for the problem we solved well, a very tiny team, and kept doing what I wrote in the first paragraph. You don't need to be able to solve all the problems for all the people, or even most of the problems for most of the people. You definitely don't need to be able to see the future. As long as you know precisely what customers want, why they want it, and how they value it ("We're paying someone to do this by hand and it's expensive and buggy" vs. "It would be cool if…"), and are constantly talking about and adapting to that information, the rest tends to work out.
37signals is the extreme version (100:1 no:yes?), but every other bootstrapped product business and many funded ones all do the same thing.
The way to get better at resource allocation is to do it over and over. Even if your first few products fail, there's always a next time - and it's easier when a failure takes 6 months and not 3 years :-)
[1]: https://signalvnoise.com/posts/1050-ask-37signals-how-do-you..., https://rework.fm/say-no/
Yup[1], or explain to/convince them they don't actually need the feature, or use the money paid by happy customers to pay someone to implement it, or conclude that demand is so strong that it's worth raising capital to serve them sooner.
Operating a business is doing that over and over, hundreds of times, for years.
Especially for a bootstrapped business, the need to do that will actually _increase_ during the business's lifetime - and that's if you're fortunate. When you no longer need to tell even more prospective customers "No," that's an early sign that you're serving almost the whole market and that growth (and the chance to solve neat problems) will slow down.
If you're succeeding, lots of prospective customers will always want something you don't have. There will always be larger companies that could - and you believe should - easily invest more in your field than your whole business spends.
Here's a personal example. I ran a log management service that had no graphing/visualization service - for 5 years. It launched way back in 2012 (https://www.businesswire.com/news/home/20110609005940/en/Clo...). If you'd asked me then whether it wouldn't get native graphing until 2017 (https://blog.papertrailapp.com/lightning-search/), I'd have said you were crazy - maybe even that it wasn't possible to exist that long without it. In those 5 years, I probably addressed that topic 500 times. Sometimes I explained why it wasn't necessary to solve the prospective customer's problem, sometimes I stated that my product wasn't a good fit, sometimes I tried to reduce the need for that feature (like by supporting external graphing services, which was a small enough amount of work that our tiny team could implement a great version: https://blog.papertrailapp.com/new-search-alerts-dashboard/).
But… our choices were sound and they worked out (though I assume there were >1 viable paths, not just the route we took). We had tons of demand for the problem we solved well, a very tiny team, and kept doing what I wrote in the first paragraph. You don't need to be able to solve all the problems for all the people, or even most of the problems for most of the people. You definitely don't need to be able to see the future. As long as you know precisely what customers want, why they want it, and how they value it ("We're paying someone to do this by hand and it's expensive and buggy" vs. "It would be cool if…"), and are constantly talking about and adapting to that information, the rest tends to work out.
37signals is the extreme version (100:1 no:yes?), but every other bootstrapped product business and many funded ones all do the same thing.
The way to get better at resource allocation is to do it over and over. Even if your first few products fail, there's always a next time - and it's easier when a failure takes 6 months and not 3 years :-)
[1]: https://signalvnoise.com/posts/1050-ask-37signals-how-do-you..., https://rework.fm/say-no/
So you're considering the worst case scenario is 1) you release the MVP 2) a competitor sees it and releases a finished copycat version within say 6 months 3) they take all your business?
If this were true and the only thing standing between you and success is a small head start, then you'd lose anyway as skipping step 1 will only buy you a small window of time.
Releasing a polished, targeted, marketed and paid product takes a massive amount of time and mental energy. Realistically, most indies have projects they're working on already and can't finish, and other teams aren't going to switch direction without a very good reason. Copycats will never be exactly the same either so there should always be a way to differentiate yourself.
If this were true and the only thing standing between you and success is a small head start, then you'd lose anyway as skipping step 1 will only buy you a small window of time.
Releasing a polished, targeted, marketed and paid product takes a massive amount of time and mental energy. Realistically, most indies have projects they're working on already and can't finish, and other teams aren't going to switch direction without a very good reason. Copycats will never be exactly the same either so there should always be a way to differentiate yourself.
>I have a feature list that I'd like to implement down the road, some of them are quite technically challenging. Should I overcome such challenges before releasing the MVP?
Depends on how substantial it is to your Minimum Remarkable Product. You need to make a skateboard, get it on the asphalt, and see how it does. Talk to users asap, but if you are concerned someone will hijack and it pump out more features, you need more domain-specific knowledge that will render that infeasible/impossible. Additional features down the line, if you can keep their needs in mind during the early phases, you may be able to tease apart things that would otherwise lead to "Complected" circumstances (two things tied together that do not need to be). Building a team is harder than building an application, I wouldn't consider it lightly as a solution to an incomplete product. If you're going to build a skyscraper, you need a plan from day one, but you also need people who can help you work on the concrete floor and foundation, not too many window decorators quite yet. Basically you must weigh out the odds. Will someone release before you? (10-80%) Will someone release after you but out-compete you on features? (25%) Will someone attempt to make a competition app if yours hits the market first (5% likely) Will someone else attempt to hit the market first if no app is there (95%)
Find the minimal set of features that customers will pay you for and use that as your first comet to reach. Your overall strategy should be to make a banger product, and you don't know what that looks like until you put a plank in the room and say "hey what do you think of this couch" and someone else says "that's a couch?!" It's the way to making a perfect couch, a perfect piece of furniture, that is not predictable and not exactly teach-able. As long as you are creating a product in a market with little to no competition you are fine, but if there is a lot of competition, why are you fighting for a tiny slice of a big pie when you could have a huge slice of a pie elsewhere that can grow? Recommend watching videos about Peter Thiel's Zero to One.
Depends on how substantial it is to your Minimum Remarkable Product. You need to make a skateboard, get it on the asphalt, and see how it does. Talk to users asap, but if you are concerned someone will hijack and it pump out more features, you need more domain-specific knowledge that will render that infeasible/impossible. Additional features down the line, if you can keep their needs in mind during the early phases, you may be able to tease apart things that would otherwise lead to "Complected" circumstances (two things tied together that do not need to be). Building a team is harder than building an application, I wouldn't consider it lightly as a solution to an incomplete product. If you're going to build a skyscraper, you need a plan from day one, but you also need people who can help you work on the concrete floor and foundation, not too many window decorators quite yet. Basically you must weigh out the odds. Will someone release before you? (10-80%) Will someone release after you but out-compete you on features? (25%) Will someone attempt to make a competition app if yours hits the market first (5% likely) Will someone else attempt to hit the market first if no app is there (95%)
Find the minimal set of features that customers will pay you for and use that as your first comet to reach. Your overall strategy should be to make a banger product, and you don't know what that looks like until you put a plank in the room and say "hey what do you think of this couch" and someone else says "that's a couch?!" It's the way to making a perfect couch, a perfect piece of furniture, that is not predictable and not exactly teach-able. As long as you are creating a product in a market with little to no competition you are fine, but if there is a lot of competition, why are you fighting for a tiny slice of a big pie when you could have a huge slice of a pie elsewhere that can grow? Recommend watching videos about Peter Thiel's Zero to One.
I try build something niche-y and cool and then automate it as much as possible. And: Price point is not usually the main selling point.
Because then: It's usually not big enough to be interesting for copycats, and with the higher price I avoid the "bargain-hunters" (in my experience these are the ones who will be the most time-suck with their communication and feature requests, etc) and have a decent enough margin to re-invest.
With a small target group, it's easier to talk to potential clients, they most likely have similar problems. E.g. if I build something like Trello, I will get wildly different answers when I talk to a CTO and when when I talk to junior devs.
I can always expand the target group, but I'll think about that later.
Because then: It's usually not big enough to be interesting for copycats, and with the higher price I avoid the "bargain-hunters" (in my experience these are the ones who will be the most time-suck with their communication and feature requests, etc) and have a decent enough margin to re-invest.
With a small target group, it's easier to talk to potential clients, they most likely have similar problems. E.g. if I build something like Trello, I will get wildly different answers when I talk to a CTO and when when I talk to junior devs.
I can always expand the target group, but I'll think about that later.
It's a non-issue. If you can build it, someone else can (and will). If your business is dependent upon the idea itself you are probably doomed or at least in for a hell of a fight. Anyone with funding could always come along with 10x the cash and resources to throw at the problem.
I recommend designing and building a business around some kind of competitive advantage, like data. In that case, even if your competitors have all of your code they still can't compete with you.
I recommend designing and building a business around some kind of competitive advantage, like data. In that case, even if your competitors have all of your code they still can't compete with you.
I have a feature list that I'd like to implement down the road, some of them are quite technically challenging. Should I overcome such challenges before releasing the MVP?
I know people keep saying you might build the wrong project so you should release early. But what if I'm building the right project? What if it turns out to have market fit but because I'm incapcable of releasing new features quickly enough, users turn to competitors because they couldn't wait?
I guess some people might say I should release the product asap, and then hire people to deal with technical challenges once the product turns out to be vaulable. But I don't think I'm good at building a team, and I can't trust myself for finding the people that are really capable of solving these challenges. The hiring just becomes another "technical challenge" I have to overcome (and probably a much harder one). It's not reassuring.
I have a hunch that such thoughts are naive, but currently I can't come up with good arguments. And this possible false sense of urgency is tormenting me.
Do you worry about such things when building projects? How do you deal with it?