Choosing a SaaS Building Path: Build in Public or Private?

When you go about building your own SaaS, there are different approaches you can take to do so.

If it’s your first time building a product, you start by picking one idea to develop. Take anything between 3-10 months to build a prototype or “MVP” and then post about it everywhere on the internet.

But as you’ll eventually realize, the phrase “if you build it, they will come” is a total lie.

It doesn’t have to be all doom and gloom though, in this article we’ll explore both approaches to building a SaaS, each with its pros and cons.

You’ll find out when it’s better to use one method or the other.

So, let’s dive in and take a look at the two ways you can build a SaaS.

The Traditional “Private” Way of Building a SaaS

If you have ever created something to promote online, whether that’s an e-book, a course, or an app, you are already acquainted with this method.

However, for our purposes here, I’m talking specifically about solopreneurs and indie builders.

This is the way that many people use when starting out. But it also applies to more experienced and more established builders.

It also looks like the most reasonable way to build a SaaS. And for most people, this is the only way they know.

It allows the creator to work and develop the idea without any intrusions and far from prying eyes. It provides the space to build an initial version, test it out, and iron out any bugs before the end users can find them.

Many people build this way because they don’t want others to “steal their idea”. And so, they take however long to build something that’s good enough to put out and gather feedback from a small group of beta testers.

However, the downside of this approach, regardless of whether it’s the first product or the 10th one, is the lack of feedback during the development phase.

The initial idea in a lot of cases is not that similar to the end product.

The first version of Twitter is not the same as it was 2 years after.

Something similar happened to Instagram, it was created as an app to share geolocated photos. However, the functionality of sharing photos was the most popular amongst the users. And when a small set of photo filters were added, that’s when it started getting thousands of users.

You see now that the initial idea can be one thing but it can change a lot after going through feedback from early users.

A result of this lack of feedback is building a product that no one wants and no one pays for.

A similar result is building something that does solve a specific need but doesn’t stand out in the market and can’t be discovered by its intended audience.

The “Build in Public" Approach to SaaS Building

This is the other side of the coin.

With this approach, you don’t go into your cave for an extended period of time and then come out with creation and try to get it into the hands of as many people as possible.

The name is a bit misleading and makes people think that they need to share everything that happens because it’s building “in public”.

You don’t need to share every little detail or talk about every single event that leads to the creation of the product. You can choose how public you want to get.

The idea is to find your ideal audience, get feedback from them early on, improve the initial idea with that feedback, and get people to care about what you’re building.

This sounds like a better approach to building something in general, but with everything in life, there are also downsides.

The most obvious one is that you’re putting yourself and your creation out in the open where everyone can see what you’re doing. This is uncomfortable for most people.

You also need to be careful with what you’re sharing because if you overdo it, there are lurkers out there who won’t waste time copying what you’re building and will take away part of your userbase.

For others, building in public makes you look like a novice that doesn’t know much and is just “throwing stuff at a wall to see what sticks”.

This goes against what we have heard about being an “expert” in your field and having the credibility that you’ve “done the thing before” instead of it being your first time.

Another downside for some people is that it will put them in a position of vulnerability, more so than they’re willing to be. And/or will expose them as “impostors”.

That pressure can be too much for some to handle and they will either go back to doing things in private or try and share some things but won’t fully realize the advantages of the “build in public” approach.

Where to Draw the Line Between the Two Methods of SaaS Building

If you have heard about “build in public” before but haven’t really given it a try before, you should start with a project you are working on or plan to in the future.

You don’t have to do it all by yourself though.

If you are getting started and don’t know how to make the most out of it, there are communities out there (like HackerCabin or Build in Public Mastery) that are built around this concept. They are great places to start rather than DIY’ing it on social media.

Going the “build in public” route can also be a good process of discovery. Both for knowing how to make a better product but also for knowing yourself more deeply and developing new skills (and also relationships!).

Of course, if you’re working on something really important like helping people with a rare disease or creating water out of air particles… that’s something you can keep under wraps (at least until you get a patent for it).

Building in public is not something that’s exclusive to SaaS or software products. It also applies for projects like books, courses, and even print-on demand.

The important part here is not to share stuff for the sake of being “out there” or ticking off tasks from your marketing to-do list. People don’t really care about your product updates unless they’re close friends.

When you build in public, share stories of how you came up with ideas, how you implemented them in product, problems you came across and how you were able to solve them; concepts others have a wrong view of and how your work can change them and provide a better view.

We are all naturally drawn to stories. And if the beginning is interesting and intriguing enough, we’ll want to see how they develop until the end.

(That’s one of the reasons why new TV shows still come up.)

Conclusion

You now know that when it comes to building products to launch online, there’s no “one size fits all” way of doing so.

You can build it on your own over a period of time and then, when you launch, it can have the results you want or it can flop.

You can use the “build in public” approach and take a bit more time before the launch, but once you do, you know you’ll be launching something that helps people and have a waitlist of potential buyers instead of launching to crickets.

And you can also play around with the amount of “public building” you want to do. Either be completely transparent on the process or dial it back and just share highlights and lessons learned.

At the end of the day, the decision on which approach to choose is only yours.

Take a look at your current situation, what your goals for the project are, what resources you have at your disposal (i.e. if you have the time, energy, and money for the project), and what a “successful” launch would look like.

When considering these different factors, you can make a more informed decision on which approach to use when you set on the journey of building and eventually launching your next product.

Don’t forget to subscribe to me on Hackernoon so that you don’t miss the upcoming articles.