The Insider Guide to Building an Awesome SaaS Product

We released our first SaaS product, we call it Spark!

Spark is content sharing automation product which lets bloggers and internet marketer automate the content sharing on social media.

We are still in beta but I thought to share my two cents on building a SaaS product.

It's not easy!

Ideas are easy, execution is everything!

You had an idea and clear steps to go for but there is something which is stopping you from beginning, could be writing the code or design some screen or any do anything to move ahead.

Well, that's laziness and this is the first thing which you need to overcome to really build your project.

And yes, it's not easy!

Focus more on UI and UX

You may not focus much on the user interface design and user experience in military based projects but here on SaaS, UI and UX is close to everything.

Yes, no matter how good your backend engine is, how fast the search is, if UI sucks, your app sucks.

I am sure you have watched the Silicon Valley Season 3 episodes where they built the file sharing platform with their amazing compression algorithm. But they failed, because their UX feels engineered!

Research your audience and design your UI accordingly. I generally focus on 3 click rule when doing UX discussion. That means, up to 3 clicks on screens, the user must obtain some result.

Trim some fat!

If you had to launch your business in two weeks, what would you cut out? - Rework

We all have a great list of features to built and ship in the first release. I would say prioritize those and find out which one is not needed for a release.

Let me give you an example: For our SaaS app we thought to have following mandatory features:

  • Post analytics.
  • User profiles.
  • Edit schedulers.
  • Email reporting.
  • Pause and delete schedulers.

We only shipped the last one and put the other on hold. Why? Because we know that for the very less user engagement application ( it's fully automated ) user won't be bothered much about his/her profile and setting their personal photos as an avatar.

Similarly, try to find out those features which are good to have but not must to have for your application.

Release early

If you are thinking of the perfect time to release your product, you are doing a big mistake.

Release early, with fewer features to the small audience and see their feedbacks. Remember, you can always add new great features but there is no point of having that feature if no one is using it.

Continuous Release

Make sure your development release cycle is automated and continuous. Once you ship your beta out, you are expected to receive bugs and record feature request. Fix those bugs and release the patch.

Till now, we have fixed more than 5 major bugs and 10 minor bugs on Spark after the release of the beta.

Users have asked that they should get analytics reports of the content shared by our app, we quickly wrote the code and shipped it for testing to the real users. That's kind of continuous release you need.

Communicate

Before shipping the beta version out, make sure you have communication module ready. Because you are going to need it more than ever.

When there is any fix you made or you encounter any bug and not sure about the timeline to fix it, communicate to your users and let them know.

It's important! Don't be embarrassed, this is the part of the process. This way you are going to build the trust with users. Everyone in the world like honest people. So be one with your users.

In Spark, we used Mailterlite API to add every user to the email list and then if we need to communicate, we just send one email to all of our users using Mailerlite email composer. Simple as that.

Record every request

Henry ford That's right.

Record every request from a user to add new features but don't act immediately. Be patient.

Once you have a list of a feature request, try to find out the pattern that which one most of them ask and does that make sense ( It's important, remember there is still no dislike button in Facebook).

If the requested feature is something your application should not have then try to alter and deliver similar feature which relates to what users have requested. Like how Facebook deliver Facebook reactions when users asked for a dislike button.

Summary

These are the few things which would really help you in building SaaS based product because it helped us. Let me know what you think about this in the comment section.