
Ask HN: Do you worry about copycats when building a project? - hgl
I&#x27;m building a project that I&#x27;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&#x27;s on the market, someone or some team will copy it and outmaneuver me because they&#x27;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&#x27;s mostly about features.<p>I have a feature list that I&#x27;d like to implement down the road, some of them are quite technically challenging. Should I overcome such challenges before releasing the MVP?<p>I know people keep saying you might build the wrong project so you should release early. But what if I&#x27;m building the right project? What if it turns out to have market fit but because I&#x27;m incapcable of releasing new features quickly enough, users turn to competitors because they couldn&#x27;t wait?<p>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&#x27;t think I&#x27;m good at building a team, and I can&#x27;t trust myself for finding the people that are really capable of solving these challenges. The hiring just becomes another &quot;technical challenge&quot; I have to overcome (and probably a much harder one). It&#x27;s not reassuring.<p>I have a hunch that such thoughts are naive, but currently I can&#x27;t come up with good arguments. And this possible false sense of urgency is tormenting me.<p>Do you worry about such things when building projects? How do you deal with it?
======
photawe
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.

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

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

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

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

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

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

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

~~~
troydavis
> 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...](https://www.businesswire.com/news/home/20110609005940/en/Cloud-
Based-Logging-Service-Papertrail-Launches)). If you'd asked me then whether it
wouldn't get native graphing until 2017
([https://blog.papertrailapp.com/lightning-
search/](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/](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://signalvnoise.com/posts/1050-ask-37signals-how-do-you-say-no),
[https://rework.fm/say-no/](https://rework.fm/say-no/)

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

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

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

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

------
hluska
I worry that my projects won’t spawn copycats. Imitation isn’t flattering but
it’s usually damned good validation.

~~~
stazz1
An excellent contrarian voice! "Validate my idea with your imitation clones!"
Love it.

