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.<p>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?<p>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?<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'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.<p>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.<p>Do you worry about such things when building projects? How do you deal with it?
It's literally a non issue. Once you start development, you'll run into so many issues, that you'll simply forget about it.<p>Building the right team is very very hard, finding investors is very hard, finding users is very hard -- just tackle the issues at hand.<p>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.<p>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.<p>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.<p>However, there is one thing you should worry about - domain name squatters.
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:<p>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.<p>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?<p>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.<p>OTOH, the odds that you need to iterate a few times before you have something that people want are greater than 50%.<p>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).
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?<p>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.<p>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?<p>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%)<p>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.<p>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.<p>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.<p>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.<p>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.