Live data from Hacker News

Ask HN: Do you worry about copycats when building a project?

news.ycombinator.com

1–10 of 17 posts

Ask HN: Do you worry about copycats when building a project?

#1
I'm building a project that I'm quite excited about, but at the same time, I feel worried. I worry that if I release a MVP asap, but not techinically competent enough to quickly implement more features, once it's on the market, someone or some team will copy it and outmaneuver me because they're capable of pumping out new features more quickly. From what I read, time to market is really life-or-death for many product, and I believe for projects not that huge, it's mostly about features.

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?

Re: Ask HN: Do you worry about copycats when building a project?

#2
> 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).

Re: Ask HN: Do you worry about copycats when building a project?

#3
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.

Re: Ask HN: Do you worry about copycats when building a project?

#4
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.

Re: Ask HN: Do you worry about copycats when building a project?

#5

> 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…

> 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?

Re: Ask HN: Do you worry about copycats when building a project?

#6
post #4

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…

> 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.

Re: Ask HN: Do you worry about copycats when building a project?

#7
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.

Re: Ask HN: Do you worry about copycats when building a project?

#8
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.

Re: Ask HN: Do you worry about copycats when building a project?

#10
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.

Post reply on HN