8
18 Comments

Where to distribute a desktop app MVP?

Hello, hackers from all over the world!

I'm working on a cross-platform desktop app. The MVP will be ready in a week or so. I was wondering what should I do to distribute the MVP, this is what I thought:

  1. Release (and charge) in all the means possibles (Microsoft Store, App Store, Gumroad) as soon as it's ready.
  2. Make a web page to download the software (charging using Stripe).
  3. Same as above, but without charging and asking for feedback.

I'm facing two problems:

  • I want to charge, so I can validate the hypothesis that customers will pay for the product, but I also need as much feedback as possible.
  • I fear that the MVP will be very faulty and get a bad score in the markets

What should I do? Any help will be appreciated!

  1. 6

    I would recommend offering a trial. Personally, I ignore any product which I can't try(for free or at a low cost) for a few days and figure out if the product works as advertised and fits into my workflow or lifestyle.

  2. 6

    One possible (opinionated) strategy:

    1. Find < 10 people from your network who might be able to buy the product
    2. Sell your product to them (call it an Alpha version). That way you can test and adjust your pricing.
    3. Gather feedback from those people, fix the bugs for them, and make sure you understand what they like about your product and why they are buying it versus any other.
    4. Once you fell like you have product-market-fit for those people, then expand to 50 people, and sell them the product (call it a Beta version)
    5. Again refine your pricing, make sure you talk to your customers (literally calling them), figure out your USP (you can use this for marketing afterwards), fix the bugs.
    6. Once your 50 users are happy, you feel like you have a comfortable pricing, and you understand your USP, then you can release it on wider markets, make download page and everything.

    Notes:

    • I am looking at it from a B2B perspective where relationships with your users are more like "partnerships", and where reliability is key for supporting business processes. Some markets might be a bit more forgiving.
    • Do NOT release it for free. Releasing something for free should be done for a particular reason. If you want to make money from selling your product, don't release it for free unless for marketing purposes. If you need testers, then use a different channel.
    • Your relationship with your first users is essential. If it's strong enough, they will be forgiving of an Alpha version, they might help you fix some bugs. If it's not strong, they will download your product, tell you it's good, and then not use it.
    1. 1

      Great advice! I'll follow these steps and share the results 😃. Thank you so much for the thoughtful response!

  3. 3

    Getting feedback from the users is not easy.
    Users send feedback if they are very disappointed (e.g. facing a bug, which is great for you to get that report) or extremely happy. You lose the most part of your users.
    If you force them to provide feedback, you might get a meaningless 5 star because the humans prefer to be polite, or some quick feedback (so that they finish their obligation) without them having worked enough with your software.
    In addition to the feedback, you could employ a product analytics library like my "SoftMeter" that will allow you to see how your users are using the various parts of your software, and even remotely log crashes or exceptions of your application.
    https://www.starmessagesoftware.com/softmeter
    If you decide to release a trial vs paid application, SoftMeter will allow you to see if you have a healthy percentage of free users becoming paying customers, and adjust the features you offer for free. You cannot achieve that by feedback.
    E.g. you will see the immediate abandoners, that would not spend time to send feedback.

    I hope my ideas help.

    1. 2

      Thank you for the response! It's interesting what softmeter does, I will check it out, thanks!

  4. 3

    My opinions:

    1. Release MVP to marketplace and make a webpage to download are right. These are marketing channels for desktop app

    2. You have an underlying assumption that charging and getting feedback are in conflicts. But it's not right. From my experience, free users don't care as much as paid users. Paid users are more willing to give feedback. When giving feedback, you can improve your product which in turn provide more values to them.

    3. You should charge if you want to validate your idea. If your project purpose is to make money, you have to charge anyway. If you make it free to get users, you are trying to escape from the reality, instead of the truth.

    4. Faulty MVP. Why you have the fear? What is the root cause of the fear? If you do a complete testing for normal routes, it should not have major errors. If you are not confident, why not reduce the scope to cut high risk features?

    What is the core advantage of indie / bootstrap founders? We don't have a strong branding / reputation. What will you lose if there is a bug? Unless you are Elon musk, a bug will not cause you several millions dollars.

    Failed launch? Just launch again next time. Seriously, I don't think anyone care about my failures.

    1. 1

      really good advice!

    2. 1

      Thank you for taking the time @sillycube, I will apply your advice and share the results! 😃

  5. 2

    If you're deploying to Macs which sounds like you are you may want to use the macOS app store. With macOS Catalina and newer all applications downloaded from the Internet are flagged by default with this "could be potentially malware" warning which confuses and sometimes concerns users.

    I had to explain this recently. It's making me think of deploying my console (CLI) based application via the store some how.

    1. 3

      You can use both the MacOS app store and distribute your app from your website, outside the app store. (this is what I do for my software)
      Via your Apple developer subscription, you receive a digital certificate to sign your app for distribution via the app store and another certificate to sign it for distribution outside the app store. In recent versions of MacOS, additionally to the digital signing, you must also "notarize" your app via Apple.
      All these tasks can be done via xcode, and as a result, the end-users will not see any security warning. Depending on the users' security settings under MacOS settings, they might be notified that this is from a developer outside the Mac app store.

    2. 1

      Great insight! Thank you so much!

  6. 2

    Beta users are great. Try listing on beta list or here at the very least. You may want to get feedback by building a loyal user base before you can really start to charge perhaps

  7. 1

    Sorry for not directly answering your question but I am curious how did you develop your application. As Microsoft Store as far as I remember only accepts UWP software which is already a major hurdle to overcome when you want to multi platform because porting UWP to anything broader is a complete nightmare and vice-versa.

    1. 2

      I'm using the Electron framework. There is a tool that can convert the app into the format that the Microsoft Store accepts. I didn't use it yet, but I hope it works! This is the Git: https://github.com/felixrieseberg/electron-windows-store.

      1. 1

        Ah very interesting! Thank you that is good to know

  8. 2

    This comment was deleted a year ago.

    1. 2

      Sounds like a risky strategy. In my experience is once your software/product has a bad reputation it is going to even harder to turn the ship around so you face even more resistance to purchase. Make sure you have something solid before pushing it out to a wider audience.

      1. 2

        This comment was deleted a year ago.

        1. 3

          Yes you are right it is really hard to find a good balance. I would say go closed alpha with a group of people you trust and you know they will give honest feedback first. So no relatives or super-close friends (unless you know they are brutal honest). Iron out the most obvious issues that occur in this phase and then go wider public could be trial-beta, paid-beta or free-beta

          1. 2

            Thank you both @RichTheDeveloper and @Mut1nyJD! I will start with a closed Alpha to polish the main issues and then an open beta to a biger audience. I'll share the results in a few weeks! 😃

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 47 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 27 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments