Ask HN: What do you do if someone is already building what you wanted to build?

58 points by jaredsilver ↗ HN
…better than you think you can build it?

58 comments

[ 1.7 ms ] story [ 64.9 ms ] thread
It depends. If I'm building it for my education/fun I'll carry on. If I'm building to use or for others to use, I'll move on to something else. I have way more project ideas that time to work on them, so I don't want to waste my time.
Don't give up. It is the power of competition. First of all if someone is building the same it gives you some validation that your idea might be worth it. Second of all, there will always be a lot of people that look like they are working on the same thing, but the might not.

Do your analysis of the market, and iterate based on customer feedback. Your idea might seem similar, but it might be completely different. The race is not to build your idea, the race is to find out if the idea is worth it or not.

You can try to build better than they are doing and see if you are able to do it otherwise try to find out if there's a way to help them building it.
Build it anyway.

I've been working on an app that I believe will be beneficial to millions of people. And I've seen a few built and deployed that are SOOOOO close -- and even an announcement by a VERY big player that is also close.

But frankly, I believe they've all misfired.

And that it's my app that will literally change the world.

So I keep plugging away.

Alone.

We'll see if anybody actually uses it though. It's always a crapshoot.

I already dropped the ball once when I had essentially the same idea as Lyft or Uber -- but decided not to pursue it when I read Apple's rules against transportation-related apps.

I'd be willing to bet that hundreds of us had that idea. It was that obvious.

But Uber and Lyft actually built and deployed something.

And apparently those rules were rules that could be broken.

Oh well, live and learn.

What were the (broken) rules on transportation-related apps??

Best of luck not dropping the ball this time!

I don't recall exactly.

It would be interesting if someone could dig up the old apple App Store Review Guidelines from whenever Core Location first became available.

Currently it disallows "Apps that use location-based APIs for automatic or autonomous control of vehicles, aircraft, or other devices will be rejected".

But I'm fairly certain that at the time it disallowed transportation industry related apps, and specifically mentioned trucking and taxis.

Which was irritating to me because during the dot-bomb at the turn of the century I had been reduced to the role of taxi driver for a time.

And the only way to actually get any fares through dispatch was to bribe everybody and especially the radio guys. I hated it and really had to work hard to make money from people hailing me.

So when I first learned of Core Location, my first thought was "motherfuck taxi dispatch - I can make them irrelevant with iPhones now".

Seriously, I'd love for someone to dredge up the old version of that document so I can read over it again.

Pros

--------

0) It's validation.

1) Execution will be different, they might bork it or serve different customer segments.

Cons

--------

0) Find/create durable competitive advantage/s

1) Win-Lose/Lose-Lose competition sucks because it's often dumb (see also: Peter Thiel)

Build it. Not anyway, just build it. Two houses on the same of the street, built by different neighbours, may be or less similar. The street gets better by 2+ neighbours focusing on making the street better.
Not everyone uses Cisco, some people use Juniper. Not everyone uses HP, many use Dell and others. Not everyone has a LAMP stack, some prefer SQL Server, IIS, and .NET.

There's many ways to differentiate. Maybe yours can be more featureful. Maybe it can be simpler; not everyone wants everything to be covered in options. Maybe you can iterate faster; maybe you can offer more stability and a more "corporate-aligned" update schedule.

Look for people who don't like the other person's product, find out why, learn from their mistakes, and try to serve users that they ignore.

Build it better / different / more focused.
hard mode: the competitor is a YC company and you are not even in US

Would you answer the same?

Absolutely. If you aren't in the US, market it to wherever you are. And YC is a funding/networking/mentoring mechanism, not a super power. Don't be intimidated just because someone is YC.
So you get to learn from their mistakes, and you don't even have to start in the same market!

You could even advertise yourself as being like your competitor, but the local option. Sell them on the idea that by paying you instead of the competitor, the money would stay in the community instead of going to the USA.

Totally. There's much more to the world than the US. Use your differences to your advantage -- you can be more localized.

For example, I'm working in a little niche with some US competitors. But my partners have found that being "Made in Canada" is actually helping us sell to our local Canadian small businesses. Additionally, we're going to do a French Canadian version of our app and market in Quebec -- our US competitors haven't touched multiple language support. These small differentiators will help make us a successful business; not a Google or an Apple, but, a source of revenue that we built by ourselves out of nothing.

Competition is a sign that you're on the same track others have identified as being viable. It's much better to have competition than to be all alone.

Wait for a new idea. Each of us has very specific talents that others don't. If you can find yours, you can be the one building it better. It's all about maximizing efficiency. Ideas come and go. You don't have to jump on the first one to succeed. Just on the one that makes the most sense.
Either build it anyway, or join them, or sit back and wait until you can use their thing. It depends on what your reasons for wanting to build it are.
Someone will always be either building what you'd like to, or chasing after you with a competitive product trying to eat your lunch.

Any market worth being in, will have plenty of competition early on.

Primarily you have to ask yourself if you can add value to the segment you're talking about. If you have something worth-while to offer customers / users. Such questions remain regardless of the competition or lack thereof. If you've got something valuable to offer, build it. There is always an angle to take against a seemingly superior competitor, whether that's on price, features, support, customization, ease of use, et al.

> …better than you think you can build it?

If it's open-source, see where you can contribute, for example, documenting the code or adding a feature you think they're missing.

If it's not open-source, see if they're hiring. In your cover letter mention that you had a similar idea, but it differed in x, y, and z ways, and include the pros and cons of your your different features and implementation methods.

Good points, but always depends right? I need this tool and it happens someone has done the dirty work and will take forever for me to DIY (it requires a lot of research and understand how X works). I used the tool, and I found a bug which affected usage, and I fixed it because the tool was opensource.

But I always note I don't actually decide what goes into that software. I can argue about why X feature is needed or why Y should be implemented in Z way, but I don't own that repo. Of course this is the beauty of open source just fork it (with the cavaet of watch the license which many probably doesn't care or doesn't have the knowledge to understand what X license mean to a user and to a contributor). But if I were to test my own ability and feel proud "yes I build it from scratch" I will build one from scratch. There is just that one idea that "I wish I was famous and getting tons of likes and respects because I built something that hundreds of developers are benefiting, being original creator vs a contributor.

Be relieved that you have one less project to accomplish in your lifetime and move on to the next thing you'd like to do.
If another app solves all the issues I set out to solve in my own app, and is in a language I am comfortable with, then I would try it out and see if I could contribute somehow.

Then again I only program as a hobby and everything I make is open so I have no financial motive to compete.

Have they deployed yet? Otherwise, build to ship first. Be first and expand based on your users/buyers input. Motivate yourself to deploy asap.
To quote Alan Cooper, you don't want to be first to market, you want to be best to market. Build something great and let your opponent make the painful first inroads.
I believe there is no market for a single idea, you create a market by pleasing them day after day. And imo the best way is to ship asap, get the feedback, adjust en please.

But, it ofcourse depends on what your building, the info i miss in de main question asked.

Nobody cares about calling dibs. People will move to the product that provides the best value; a subjective assessment that is constantly being re-evaluated as conditions are ever-changing. Also, execution never looks the same even if the ideas are identical.

If you think you can build something of value for people and you care about the problem then do it or join others already doing it. If a competitor makes a mistake, learn, and if they succeed, adapt. Everything else is a distraction from solving actual problems.

I don't think there are a lot of ideas that are so original that no one else came up with them. Chances are someone is already working on your idea regardless of what your idea is. You have the benefit of knowing who that competitor is. Shouldn't stop you, but encourage you.
Build it anyway, gain experience.

You know how there's only one personal computer platform because the other guys all gave up? Oh right, there's a bunch! Because different things can fill different niches, your take on the problem might fill some slightly different, but large demographic.

I'll go one further:

Build your version, less better, and then just kick their ass in business.

Apple was eaten alive by shitty IBM clones in the PC wars. SGI and Sun were decimated by commodity hardware. Linux destroyed a lot of high-end OSs and platforms.

You don't have to be better to do better.

There are more variables in the success of a product than just whether "something is built better".

- Product personality (aka voice)

- Initial Target Market's propensity to be enthusiastic about your product

- And much more.

(comment deleted)
Why are you building this project?

If it is to learn something, the answer is obvious: build it anyway. You will still learn pretty much all of the things you otherwise would have.

If it is because you feel that the world needs this thing to exist, and it'll become a better place because it does: see if you can contribute to the other people's work. If not, see if what they're doing meets that need and be happy that other people shared your vision of a problem to be solved.

If it's because you wanted to make a company and earn a living: keep going. There are thousands of niches in businesses. You can find yours.

Keep building it, but don't release until the other people do. This will do a few things.

First, it will vet out the market of the product. We are told to look for something new and innovative, but truth be told, the best way to predict the success of a product is to analyze the performance of similar product.

Second, it will give you some insights on areas within your own product to improve as well as ideas on how to differentiate.

How many things are brand new and innovative? Most aren't, most are iterations, or just a more successful effort at something that has been done before.

If you want to build it, build it anyway. Build it for passion, for the experience, for interest, or for any other reason. Or don't, that is ok too.

Very few people go the distance with their projects. If you think you'll be someone that does, then go for it. We've had the biggest companies to startups enter our space, and many already in it before we started. The difference, I think, is that few have the courage or focus to push hard on it day after day for years at a time.
This is what I was thinking well staffed and funded projects have a high rate of failure, bootstrapped and underfunded projects have an even higher rate of failure. The odds are that project will never hit the market in the first place.