paint-brush
5 Steps to Build a SaaS Product That Gets Fundedby@paolodotta
847 reads
847 reads

5 Steps to Build a SaaS Product That Gets Funded

by Paolo Dotta May 12th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

99% of global organisations use at least one SaaS product, the industry is worth over $145B worldwide and is expected to grow to $171B in 2022. At Altar, we’ve developed a structured process to answer this question and ensure you build an innovative, user-centric solution. The process has helped over half of the startups we work with achieve VC funding, in an ecosystem where only 0.05% of startups ever see that happening to them. The first step is to identify the problem you’re trying to solve.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - 5 Steps to Build a SaaS Product That Gets Funded
Paolo Dotta  HackerNoon profile picture

Roughly a decade ago I decided to move away from my corporate job in investment banking in London to pursue something I always knew I wanted: to become an entrepreneur.

I’d had this idea to build a marketplace in the social events space and decided it was time to do it.

Like so many other stories of first-time entrepreneurs, I made some serious mistakes that eventually forced me to shut the project down. But it was far from a failure in my view.

Firstly, I learnt a ton about how to build a startup. More than that, it was during this project that I got to know the amazing people that would turn out to be my co-founders here at Altar.

Like me, they were all entrepreneurs in the past. They’d all built startups from the ground up and also faced many of the classic entrepreneurial hurdles first-hand. 

Between us, we had over 10 projects under our belts when, in 2015, we decided to create a product & software house designed specifically to help entrepreneurs. 

Fast forward six years and today we’ve helped build over 50 startups. We get requests from 25 to 50 entrepreneurs and business managers every month looking for help to build their tech products.

Most of these requests are to build some form of SaaS product. Which is no surprise. After all, 99% of global organisations use at least one SaaS product, the industry is worth over $145B worldwide and is expected to grow to $171B in 2022.

It’s for that reason that today’s article will focus on the exact framework we use to help out clients build successful SaaS startups.  

And by successful I mean this process has helped over half of the startups we work with to achieve VC funding, in an ecosystem where only 0.05% of startups ever see that happening to them.

Let’s get right into it with the first step, finding your SaaS product’s value proposition.

Step One: Your SaaS Product’s Value Proposition

There’s no point building something nobody wants. Therefore, before writing a line of code you need to define what value your SaaS product will bring to the market. 

At Altar, we’ve developed a structured process to answer this question and ensure you build an innovative, user-centric solution: 

What is the Problem your SaaS Product intends to solve?

The first step is to identify the problem you’re trying to solve. After all, how do you know what value you’re bringing if you don’t first know the problem behind your SaaS product? 

Who is Your Main Target?

Once you’ve identified what you intend to solve, you need to know who you’re solving it for. This may seem obvious, but actively identifying your users is a critical step in ensuring your SaaS product is valuable.

You should get to know them in terms of demographics, psychology and observed behaviour. You will eventually have to build UX Personas, so any research you do now will certainly help you down the road. 

How do Your Target Stakeholders Deal with the Problem Today? 

Without a doubt, there is some kind of solution in your market already, even if the competitor behind that solution is an indirect one. 

For example, Henry Ford created the world’s first mass-produced car – putting the “world on wheels”. It would be easy to say that he had no competition. 

However, people were solving the problem of getting from A to B before the Model T hit the market. They were using horses. So as indirect as it may be, there was still competition in Ford’s market. 

Most likely, your target market already has a way to solve the problem you intend to tackle. It’s important to know both how they’re solving it and who is solving it for them. 

Why is Your SaaS Product Better Than the Current Solution?

Now you know how the problem you’re tackling is being solved, and who is solving it, it’s vital to outline how your product is better than those solutions.

What is it that you’re bringing to the table that no one else is? 

You’re going to be asking your market to drop their current solution to adopt yours – so you need to be able to give them a reason to do so. 

Sum up Your Value Proposition with an Elevator Pitch 

The last stage in preparing your SaaS product for development is to sum up your value proposition in an easy to digest elevator pitch. 

Here’s a template to help you get started: 

[Name of your SaaS product] has been created for [your target stakeholders] who [state the problem they face][Name of your SaaS product] is a [statement of its key value]. Unlike current solutions we [explain what differentiates you from the alternatives].

Your elevator pitch should be simple, stupid and crystal clear. The person reading or hearing this elevator pitch should instantly know what your value is and why your SaaS product is worth adopting. 

Once you have that, you’re ready for step two: setting the assumptions you need to validate with your SaaS product. 

Step Two: Set the Main Assumptions You Need to Validate

The next step is to assess the assumptions you’re making about your target market and the problems they face.

For example, Slack assumed that businesses wanted an all-in-one online platform for workplace communication when they first developed their SaaS product. 

Create a list of all the assumptions you have surrounding your product. Once you’ve done this, it’s time to validate them.

Start by researching the current solutions to find the assumptions that have already been validated. To go back to the Slack example, they already knew that people were looking for a solution to communicate online because of email providers and file transfer solutions such as dropbox. 

Once you’ve identified the “pre-validated” assumptions, check them off the list.

Next, you need to define which assumptions can only be tested/validated through building a SaaS product. 

For example, Slack needed to prove that there was a demand for a hub that allowed teams to not just communicate but collaborate online. 

Once you’ve defined which assumptions need to be validated with a product, you should also identify the KPIs to measure whether or not your assumptions are true. This could be adoption rates, retention ratio, etc. 

With this information in hand, you’re ready for the next step: build something that validates those assumptions as quickly as possible. 

Related: How to Build a Successful Minimum Viable Product (MVP) in 3 Steps 

Step Three: Validate Your Assumptions As Quickly As Possible

With your list of assumptions and elevator pitch in hand, it’s time to create the list of features to build into the first version of your SaaS product. 

Going down your list of assumptions, define what feature(s) are needed to validate them. Then cross-reference this with your elevator pitch to ensure that those features showcase your value proposition. 

Leave any features that do not validate your assumptions or showcase your value proposition for later iterations.

For example, Slack needed to give users the ability to send direct messages, group messages, share links, and upload/download files to showcase their value proposition. 

They didn’t, however, need to give users the ability to integrate with other apps such as Trello or Google Drive. While the ability to integrate third-party apps is undoubtedly useful, they don’t prove or disprove the key assumptions behind Slack’s value proposition. Therefore, Slack built them later, after they’d proven that people wanted their product. 

This step should leave you with a concise set of features that put solving your users’ problems first. Once you have them, you’re ready to move on to the first stage of developing your SaaS product: choosing the right tech stack.

Step Four: Choosing Your SaaS Product’s Tech Stack

There are several popular technologies that are used in many SaaS products. 

For the frontend, modern Javascript frameworks such as React, Angular or Vue.js are commonly used. In terms of backend development, it’s normal to see Node.js or Django. 

These have risen in popularity as they’re lightweight, allow for high performance at a lower cost and set the company up to scale with more ease.

The next addition to your tech stack will be a database. These hold all the necessary information for your SaaS product. Popular databases include PostgreSQL, MySQL, MongoDB, to name but a few. 

Finally, you will need a SaaS hosting provider. Any reliable cloud provider will do the trick here. Amazon Web Services (AWS), Google, and Microsoft are all popular due to their reliability, flexibility and, critically, security. 

With these being the most popular stacks for SaaS products, most likely the talent pools within them will be larger. This means, if you choose one of the above stacks, you’ll probably have an easier time onboarding talent vs. the less popular stacks.

To make a more informed decision on the specific stack you should use, I would first recommend learning the basics of tech before having these conversations to ensure you are able to make the decision from an educated perspective. Remember, technical decisions at this stage are also business decisions. 

Then, I recommended doing some further research by looking at your competitors. If they’re already succeeding in your chosen industry, most likely they’re using the correct tech stack for the job. 

On top of that, ask any technical Jedi contacts you have what stack they would recommend. You can even reach out to a software development company to ask them what they would propose building it in. Most reputable agencies will happily do this free of charge. 

Just keep in mind that anyone you ask may have their biases (especially if they want to work with you). 

Once you’ve identified the tech stack you think is right for you, it’s time to find some top talent developers to help you build it. 

For more advice on choosing the right tech stack for your SaaS product, feel free to send us a message. We’ll be happy to put you in touch with someone from our technical team to answer any questions you may have.

Step Five: Building Your SaaS Product Development Team 

When it comes to finding the right technical stakeholders to build your SaaS product, you have three options. 

You can: 

  • Find a CTO/Technical Co-Founder
  • Hire a team of Freelance Developers 
  • Work with a high-quality Software Development Company

For the purpose of this article, I won’t go too in-depth on this topic. My co-founder, Daniel, has written a great resource on making this decision. 

In short, my advice here is that if you’re able to find the right CTO/Technical Co-Founder from day one, then you should onboard them and never look back. 

Having a senior tech stakeholder on your team to deal with both building your SaaS product and growing your technical team is, undoubtedly, invaluable. 

Related: How to Find a CTO for Your Startup: The Founder’s Guide 

That being said, the process to find the right person for the job can take a long time. I’ve seen founders spend months looking for a CTO/Technical Co-Founder only to come up empty-handed. 

With time-to-market always being a concern, many entrepreneurs will instead choose to build the first version of their product with freelance developers or a software development agency. 

I recently sat down with CTO & Startup Advisor Nelly Yusupova to discuss this exact problem. With nearly two decades of experience in the tech industry, she shared her thoughts on the topic and the notion of earning a technical co-founder. 

“What you do is you build the first version of your product and build a community around your idea.  This not only shows off your marketing skills, it proves you’re not just an idea person but you can actually sell and market the product. 

To build the product itself, you’re going to want to go with an agency or a team of freelance developers. 

This is the fastest way to actually get your idea into the market so that you can get traction and essentially de-risk the opportunity for a potential technical co-founder. 

By showing them you’re more than just an idea person, it changes the conversation from “I need you!” to “Here’s a great opportunity!”

If you go down this route, just make sure you know what you’re getting yourself into with both options. 

Should you decide to work with freelancers, just keep in mind that you will be responsible for managing the team. This can be a massive challenge for a non-technical entrepreneur – especially when you have all of the business aspects of your startup to take into account. 

More than that, it’s vital to ensure that the technical stakeholders you onboard follow the best working practices. 

If the partner you work with doesn’t follow the industry standard, you could face problems down the road with user experience, scalability, security and reliability to name a few. 

This also applies if you choose to work with a software development company. 

With over 15,000 software agencies listed online, the main challenge here is separating the wheat from the chaff. Choose the wrong partner, and things can go bad very quickly, something I’ve seen first hand. 

I’ve worked with entrepreneurs who worked with bad agencies before coming to us to help them build their products. In the worst cases, we’ve had to scrap their entire codebase (sometimes months of work) and start again. 

This is simply due to the fact that the agency they worked with didn’t use the best working practices. Our team simply couldn’t untangle the spaghetti of code they had written and it had to be trashed. 

This mistake is costly both in terms of time and money – and not all entrepreneurs have the luxury of affording a second chance. 

That’s not to say you can’t build a successful SaaS product with an agency. You just have to make sure you do your due diligence and choose the right partner for the job. 

Aside from ensuring that the technical stakeholder you choose follows the best working practices, there is one final element to take into account: 

It’s critical that the technical stakeholder you choose aligns with your product and business vision. 

This applies to CTOs, freelancers and agencies alike. For sure you’re never going to agree with your technical stakeholder 100% of the time. However, you need to align on the big picture. 

There’s no point in onboarding someone to help you build your SaaS product if they don’t align on it’s being built. 

Once you’ve found the right technical stakeholders, built and rigorously tested your SaaS product, it’s time to move on to the next step – the launch.

Wrapping Up 

If you’re setting out to develop a SaaS product, this guide will give you all the tools you need to get started. 

I will leave you with the advice I give all the entrepreneurs I work with and advice when they set out to build their startup products. 

Before writing a line of code, ensure that your product is truly valuable to the market you intend to tackle. 

In my experience, the structured process I outlined here is the best way to avoid falling foul to this common startup problem. 

Then, once you’ve defined the blueprint for your SaaS product in a way that puts the user first, ensure you get talented people to build it. Whether you choose a CTO, a team of freelance developers or an agency, make sure they follow the best working practices. 

More importantly, ensure they align with your product and business vision and get behind the “why” of your SaaS product. 

Thanks for reading.

Originally published here.