Oops! Sorry!!


This site doesn't support Internet Explorer. Please use a modern browser like Chrome, Firefox or Edge.

Rick Blyth Logo

Validating Your Micro SaaS App Idea

Whilst it’s possible to do some soft validation techniques, there’s really only one way to fully validate your Micro SaaS idea - build a barebones MVP (Minimum Viable Product) version of your app, put it out there and see if people will pay for it.

But before you start building the MVP, you can also utilize some soft validation checks before you go ahead and code your app:

  • Soft Validation Checks

  • Using Online Communities For Idea Validation

  • Dipping Your Toes In

  • The Dummy Order Page

  • Building The MVP

  • Throwaway or Foundational MVP?

  • Beta Testing The MVP

  • Some Alternative Methods To Validate Your Micro SaaS App Idea

Soft Validation Checks

Revisit and re-validate the niche & problem with a fresh set of eyes, how many people are in your target niche, is it evergreen, and are they searching for a solution to this problem?

Here are a few ways to look for search intent to get a feeling for the numbers.

  • Google Trends - check the popularity of your target niche. We want stable/growing rather than declining.

  • Google Keyword Planner - find out approximate search volumes for software in your target niche. Add your specific problem search term to this if it’s common enough.

  • Keywords Everywhere chrome extension - (a great example of a Micro SaaS app idea itself) - repeat the above to give some further indicators of search volume.

  • UberSuggest and AnswerThePublic - Gain more insights and to spark further ideas.

Keyword research tools

Using Online Communities For Idea Validation

Next, move on to the places online where your niche’s users hang out in communities. This could be Facebook Groups, Reddit subs, Slack, Discord, etc.

Join these communities and use the search function on the platform to find people’s thoughts on the problem you’re considering fixing and the workarounds. If possible, try to message these people one on one in a non-spammy way and if appropriate, outline your high level app idea to them to get their feedback.

Be wary that it’s easier for them to give you a false positive by encouraging you to build it, so make a point of asking for honest feedback and how much they’d pay for that solution.

Review Existing Solutions

Next, check out any existing solutions to the problem. If there aren’t any solutions or there are only manual workarounds, then you may think you’ve struck gold and that your solution must be better than no solution right?

Well, there may be a good reason why others have passed up on the opportunity, so make sure you do your due diligence and consider all angles carefully.  

If there are already some solutions in place for the problem it doesn’t mean that they’ve got it 100% right and it’s a non-starter for you. Look for the gaps or issues users have with the existing solutions:

  • Are they too expensive for the users to justify? Could you produce something more affordable? For example, Pabbly is a slimmed-down, cheaper version of Zapier and it is becoming very popular proving there’s plenty of room in the market for both of these platforms to thrive.

  • Are they bundled with too many other features? Start your app off with just one core module that provides an express service.

  • Are they hard to understand or use? Build something that is easier to set up and use.

  • Are they missing key features? Build these as your USP key starting features.

  • Validate your Micro SaaS app idea by dipping your toes in

    Are you happy with what you see and you are ready to take your idea to the next level?

    You can then gauge demand and receive feedback before committing to building an MVP by creating mockups of how the app would look and function.

    It should be obvious to the end-user what the app’s features would be from a glance at these mockups.

    You can then share the mockups via private messages with contacts in the niche or even post it publicly in the niche’s communities and ask for their honest feedback.

    Be wary of prying eyes when posting publicly. If you have many users screaming “take my money already” in the comments, it’s possible that somebody in that niche could hire a developer to build the app.

    I’d suggest removing the post after a day or two once you’ve gotten the feedback you’re looking for. That way, it’ll reduce the chances of someone stealing your Micro SaaS app idea.

    Dipping your toes in to the Micro SaaS Waters

    The Dummy Order Page

    You can take this a step further and build a simple website for the app with the above mockups in it along with some short paragraphs outlining the key features. This technique was made famous by Tim Ferris’s “4 hour workweek” book.

    You’ll have buttons on the site encouraging the visitor to order the app. On the “Order” page it’s up to you whether you:

    • Simply state that the app is in development and prompt the user to join the waitlist to receive a discounted launch offer.

    • Frame it as an app that’s available to order/pre-order and you actually pretend to take their card payment to truly validate how many people will actually pay for the app. Of course, no payment is taken and the user is told as much.

    You can then drive traffic to the site through paid ads and check the clickthrough rate to “order” and, if nothing else, gather prospective users’ emails ahead of your genuine launch.

    Alternative Methods To Validate Your Micro SaaS App Idea

    Personally, I’ve not needed to create an app website as above to try to gauge demand ahead of a launch as I could see the demand right in front of my eyes.

    For my target niche, Merch By Amazon, I was already part of the community. I listened to many Podcasts and watched lots of YouTube videos on the subject in my spare time.

    Within the Facebook groups and on these Influencers’ shows, I was able to spot recurring problems within the niche which plenty of people were complaining about. This alone gave me enough confidence that it would be worth building at least an MVP version of an app that solved them.

    Instead of building out a website with a dummy order/pre-order page, I actually started by offering some simple free chrome extensions. The users only had to register their email address to gain access to them.

    This helped to build up trust in the community and to gather an email list of leads within the niche that were ripe for targeting when I was ready to launch my main app.

    Micro SaaS Marketing Sales Leads

    Building the MVP

    The MVP is our proof of concept and will find out the answers to these key questions:

  • Does this app solve a real problem for a real set of users?

  • Are those users willing to pay for this solution?

  • Is it possible to target and attract users?

  • The majority of us software developers are somewhat perfectionists. You have to throw that out of the door for your MVP, or risk losing weeks/months of your life for no good reason.

    You have to move quickly, fail fast … fail forward.


    The first version of the app should be basic, have lots of missing features and potentially be a little rough around the edges. But, critically, it has to function correctly.

    First impressions count and we’re aiming for a reaction like “woohoo, someone is starting to fix my problem, how can I support them to improve their app so it works better for me”, rather than, “this app looks like a 5-year-old designed it and it’s full of bugs”.

    Micro SaaS MVPMicro SaaS Beta testing badge

    Throwaway or Foundational MVP?

    In my view you have two options when creating your MVP:

    1) Hack it together to such an extent it does a job and proves if there’s a demand for the product. Throw it away and start again if your MVP gets traction.
    2) Spend more time on your MVP with the intent of forming the foundations on which you’re going to build the final app upon.

    In some cases, you’ll even be able to use no-code solutions to quickly knock up a functional MVP. No-code tools such as Bubble.io are becoming increasingly powerful and are great if your app is a web/mobile/desktop app. However, you will struggle to go down the no-code route if your app is a chrome extension or ecosystem plugin.

    Beta testing your MVP

    Before we actually launch the MVP, ideally we’re going to want to get some feedback from users within the niche to help mold the MVP into shape before its public release.

    Assuming that you have no ready-made audience to tap into, you’ll want to dive into your niche’s communities and find some beta testers to help give you valuable feedback on your MVP.

    Find recent posts where people are complaining about the problem your app proposes to fix. Either comment on this post or message the users privately, letting them know you’re creating an app to help fix this problem.

    Let them know you’re going to be launching a beta version of your Micro SaaS app idea in X weeks and you’re looking for people to give feedback on it over a period of X weeks. In exchange, you can either offer them a big discount off the launch price or even free lifetime access if you have to.

    How Many Beta Testers Do I Need?

    You need 5-10 beta testers to get some decent initial feedback.

    Put them into a group (Facebook group/Slack workspace) so they can see each other’s feedback. This will ensure they’re not duplicating each other’s issues and suggestions.

    Structure and streamline the feedback loop to make it super simple for them to give feedback. After all, their feedback will be as precious as gold to you.

    Quick reality check - as with all things, some beta testers will never open the app and will just drop off the radar. That’s why you ideally need a bunch of them to actually get some valuable feedback.

    Ok, you’re getting closer to having a functional and bug-free MVP version ready to roll that our beta testers are happy with.

    It’s likely that your beta group will be bombarding you with feature requests and it’d be worth putting together a quick high level feature roadmap which you can then use on your website to show potential users how your app is going to evolve.