I will agree with the strategy of separating your product into sub-products, and working on and releasing them one at a time. A single, well-executed feature is often better than many mediocre ones. Especially as a solo founder (shameless plug: I run https://resend.io ), I think this is the best way to both test your assumptions early, and to consistently ship improvements without spreading yourself too thin. I've ta…
Or just shamelessly ripping off intercom's product is another quick way to iterate and test your assumptions.
How to Ship Side Projects
91–100 of 114 posts
Re: How to Ship Side Projects
#92Earlier quoted context omitted.
Or just shamelessly ripping off intercom's product is another quick way to iterate and test your assumptions.
If you can execute well and if the demand is there, that's definitely a viable strategy to get you off the ground - Ride the wave
Re: How to Ship Side Projects
#93Sorry but those animated gifs distracted me from reading. Normally I will scroll things like that off the page but when they come so close to each other all I see is the movement.
Re: How to Ship Side Projects
#94Earlier quoted context omitted.
Definitely. You will reach a point where perhaps you will be spending 70% of your time building out novel features, while the remaining time is spent reiterating on your existing features to make sure they stay relevant. And the beauty of being a solo founder (even more so a digital nomad living sparingly) is that you don't have to go head to head with the giants, even if you were to just tickle them with a stick and…
> even if you were to just tickle them with a stick and steal 0.1% of their customers Just be careful with this line of thinking. This is the fallacy of "it's a $2 trillion market, so if we get .001% of .001%...!"
Re: How to Ship Side Projects
#95Earlier quoted context omitted.
Definitely. You will reach a point where perhaps you will be spending 70% of your time building out novel features, while the remaining time is spent reiterating on your existing features to make sure they stay relevant. And the beauty of being a solo founder (even more so a digital nomad living sparingly) is that you don't have to go head to head with the giants, even if you were to just tickle them with a stick and…
> even if you were to just tickle them with a stick and steal 0.1% of their customers Just be careful with this line of thinking. This is the fallacy of "it's a $2 trillion market, so if we get .001% of .001%...!"
I set out to test this as quickly as I could and just kept going at it when I verified they were willing to backup their frustrations with their creditcard.
Re: How to Ship Side Projects
#96Earlier quoted context omitted.
If you can execute well and if the demand is there, that's definitely a viable strategy to get you off the ground - Ride the wave
The product looks really good. Is the design yours as well?
Re: How to Ship Side Projects
#97Re: How to Ship Side Projects
#98Re: How to Ship Side Projects
#99I'm shopping for computer parts at the minute so built a quick app to scan UK shop deals, threw it up at a subdomain of my personal site (plug: http://slackfriday.jhope.ie) and let it go. Over cyber monday and later it got loads of traffic and watching a stupidly simple app do it's job was thrilling and liberating.
Even doing agile and lean MVPs every day at work nothing quite matches the level of focus you can reach when you know your own capacity and have a time-limit. I kind of disagree with the OP in that even if you use tech that you're familiar with and have a fleeting idea it's still worth doing every once in a while to remind yourself why and how people use things.
Re: How to Ship Side Projects
#100If you’re going to try a new to you tech, only use 1 new to you thing at a time. There is nothing wrong with using a technology that’s old. In fact, that’s the best way to finish something. Old technology is googleable, stable, and usually has libraries for everything you want to do. New tech might let you do in 3 lines what old tech will do in 20… but getting those 3 lines of code to work might take more time than just writing the extra code. The next point, elegance does not matter. NO ONE cares about your project. They aren’t going to review the code, so why spend time doing something elegantly? Just get it done.
As mentioned in the article, you really have to realize your limits. At work, when you have a large team, the definition of MVP can expand. When it’s just you, you REALLY need to think about what value you’re building. I’m constantly asking myself “is this thing I’m going to spend today on actually going to be the difference between my product being useful and not working at all”. “Is there a way I can get away with faking, or doing this thing manually”. If you only have a few users, you might not need to automate right away.
One more personal preference, I don’t talk about what I’m working on with friends and family until I’m near done or done. For a few reasons, first if you talk to other engineers, they’ll discourage you. When you propose an idea to another engineer, they’re shoot it down pointing out minor flaws. I used to think, oh that’s useful… they’re preventing me from going in the wrong direction. Upon reflection though, I’m not sure the advice I’ve gotten has always been “useful”, it has made me give up on ideas. Maybe I’m weak willed, but this is what I need to see my ideas get done. If you really believe what you’re building will work, the only person worth talking to are your future customers, if your future customer isn’t interested… that’s actually worth something.