Products are never really finished, they're always evolving and growing and changing, for better or worse. At what point do you draw the line, call it quits on further breaking changes, and ship it? Asking for a friend.
Maybe your friend is procrastinating. Does he even want to ship it? Maybe your friend likes developing and polishing.<p>Shipping a product is the moment of truth. Will people buy it? or even use it? Running a business means marketing, selling and support. Even releasing as open source means you start getting feedback -- both positive and negative and demands for support and features.<p>Perhaps your friend needs support in those areas.
My personal motto is: “don’t chase perfection, and don't settle for mediocrity“. I can’t just ship the most basic thing because I find that boring and demotivating. I don’t like to make good enough things. I take joy in going a little deeper into things. But chasing perfection is a never ending road.<p>What helps me is to write down my vision of an mvp. As I start to work on it that vision may change. I may think of this or that feature. If I get that itch to add something new, I go back to that document. I ask myself if this is really a critical addition. Sometimes I come to the conclusion that yes, this new way of thinking is the way to go. Most times I just write it down as something to explore in the future and keep going.
If you’re asking, you’ve waited too long. Give up on perfection and ship it. Get it into the hands of users, customers, whatever, get feedback, and iterate loop from there. Failure isn’t imperfection, it’s giving up or never trying. Ship it!
Ship with the minimum features needed. Add more on a set timeline, every x months. The costumers will tell you what they want so ship ASAP with no major bugs.
If you're scared to ship the first iteration of a product and keep procrastinating, just go open or fair source and you'll start to feel pressure to get things into an MVP asap. You'll see the README needs work, those open PRs need to move, your repo need stars, that one feature isn't tablestakes, etc., etc.
Give yourself some immediate, immutable deadline that reasonably scares you and causes you to scramble (eg. 48 hours for initial release).<p>From there, give yourself a regular release schedule that makes sense for your work place and helps prevent scope creep (eg. weekly releases every Friday or whatever).
For my case, I killed projects several time. The most recent one was because when the deadline passed, the team couldnt deliver it properly. We needed more time to fix all of the bugs, while the market already shipped better products. So its better to call it quit, and focus on other products.
Thanks everyone. I just shipped what I've been working on for 3 months. Even though everyone says it was fine, I know that it was too early. I should have made some working demos, polished the API a little more, and done a lot better job on the announcement post.<p>Hopefully this will at least be a lesson for someone else.