Is there any relationship between technical difficulty and startup success?
My product, Placemark, is on the technical side of technical. It's using some bleeding-edge technology, is around 20k lines of code, and generally has a pretty steep learning curve on the technical side.
I've been thinking - are the most successful indie startups the ones that have few technical requirements but great product-market fit? When I look at some of the biggest successes, they seem like they would be implementable with a vanilla tech stack and then more or less stay the same as they grow organically.
And I daydream a bit about much simpler things I could be implementing, like… what if I just made a Scrabble score calculator that looked nice and saved your old games? Or a website for finding mechanical keyboards?
Hi @tmcw
Some problems just require more technical effort than others.
As an example I'd like to use an open-source/enterprise product listed on IndieHackers called Sidekiq (https://www.indiehackers.com/product/sidekiq) generating over 80k / month.
Sidekiq solves a complex and technical problem (background processing at large scale), even tough the user experience might be simple, its implementation isn't. (https://github.com/mperham/sidekiq), and yet the product is somewhat successful.
Working with maps/GIS isn't easy at all, so 20k or 100k lines of code don't matter as long as you are able to maintain the code base in a sane manner, while at the same time providing an intuitive user experience.
I'd love to hear your opinion.
Cheers
Yes. Solving harder problems is a huge advantage. You’re more likely to arrive early and dominate a new market and even in an existing market, you’ll have better pricing power since fewer can compete with you.
But! Working on something hard can’t compensate for choosing something with no market value.
None of your customers have any idea how the product is made, nor do they care, so I don't think it impacts the success of your business. That said, if your product is challenging to create, that can serve as a barrier to entry for competitors. Furthermore, you may be able to implement features that competitors can't or won't because of the work it would require. If you have a superior codebase, it's entirely possible that there are features you can implement in a couple of hours that a competitor couldn't do without rewriting a lot of their app.
Making a simple product like a scrabble score calculator would be fun and easy to make, but you'd have to worry every day about someone else releasing theirs.
That’s like saying, “none of your football opponents have any idea how you work out or train, nor do they care, so I don't think it impacts the success of your sporting career”.
I said "customers," not competitors.
Okay. I will revise. 😁
What you said is like saying, “none of the customers attending your football matches have any idea how you work out or train, nor do they care, so I don't think it impacts the success of your sporting career”
And that sounds correct lol. People wouldn't stop attending matches because they didn't like how the players trained.
Do you know how the IndieHackers website is built? Would you stop posting here based on the tech it's built with? As users/customers, it doesn't concern us. Look around your home, and you'll see hundreds of items, none of which you know how were built, and yet, you bought them all.
I did stop because of the tech for a while. It took more than 30 seconds to load on my android because of the choice to make it a bloated Ember app.
The thing you are (intentionally?) missing is that not all technical choices are equally good for a product and your customer WILL notice if your product is buggy or slow or overpriced or developed slowly due to your bad choices.
In theory if I hire you to paint my gas station, I don’t care if you use spray or rollers or a hand held brush or a tooth brush. But I really do care, even if I don’t understand the root cause, because if you use a toothbrush it will take years and cost a fortune.
To be clear, in this metaphor, your choices are the spray paint. The C++ guy is using a toothbrush.
I think we're saying the same thing in different ways. I'm saying the customer doesn't explicitly care about how it's made; they only care about the experience. You're saying they implicitly care about how it's made because it affects the experience.
Sometimes the less you have – the more you've got. Especially on the start.