Follow these steps to building a SaaS product and you’ll increase your chances of developing a product that meets a real market need and stays on budget.
Fail to follow these steps and you might find yourself in the SaaS horror story hall of fame. If you’re feeling wrongly optimistic, just go ahead and read this list of 179 expensive SaaS failures.
Our team has exited a successful SaaS business, but we’ve seen SaaS failures firsthand.
We know that there are no guarantees, however there is a clear process that successful SaaS entrepreneurs follow, and this is it.
The first step to building a SaaS product is of course to either have an idea, or discover a painful and problem and then come up with a technological solution to fix it.
There’s far more opportunity in B2B SaaS, so start there. You can build a SaaS product that solves problems you’ve experienced in your own business, or that friends, coworkers, or family members have told you about.
You could also pick any industry (literally any industry), and shadow someone for a day, get a job, or interview someone in order to find out the problems that they need solved.
Once you’ve got an idea, make sure to validate it with our step-by-step process for vetting SaaS ideas.
2. Prototype creation
All of these steps to building a SaaS product exist for a reason. Creating a prototype satisfies a few key requirements:
Provide feedback before development begins: A prototype gives you the option to give feedback to your developers before they actually build your product. Whether you use an experienced prototype creation team, or piece together your own team and manage them yourself (not recommended unless you’re experienced), it will be more affordable to give feedback on a prototype than an actual build.
Get feedback from target users: In the next step, we’ll go over prototype validation. For now, all you need to know is that getting feedback from target users before you build is a key reason why you should make a prototype first.
Helps you test out your development team: When working with new entrepreneurs, we create the prototype for them first, then let them decide if they want to continue with us as their SaaS developers. We believe in the quality of our work enough that we don’t try to sell development straight from the jump. For you as a SaaS entrepreneur, you should use the prototype process as a way to vet your developers skill, responsiveness, proactive communication, expertise, etc.
Gauge your interest and commitment level: Let’s be honest, a lot of businesses fail simply because the entrepreneur decides they’re not right the person to tackle this idea or issue. There’s nothing wrong with that but it’s better to find out sooner rather than later.
Your prototype should be high fidelity, meaning it looks as close to the finished UX as possible. You can open it up in a web browser or large tablet, and see the menu and dashboard.
Your prototype designer should also be able to make a few features partly functional. You could click around and see some mock data built inside, that way you get the feel of using your software as if it were fully functional.
3. Prototype validation
We based Sprint Zero, our prototype creation workshop, off of Google Venture’s Design Sprint Process, partly created by Jake Knapp. In this video, he explains how the process works:
Essentially, it’s five steps: map, sketch, decide, prototype, test.
When you’re validating your prototype, you’re in the testing phase. The best way to test it is to show it to users and get their feedback. Using your personal network, door knocking, and cold outreach, build a list of 10 - 15 people who match your profile for a target customer.
Send them your prototype and record their interactions with it using Lookback.io so that you don’t have to take notes on their feedback.
Ask them what they think the product does
Ask what they think about the overall design
Ask them to use the product to do X (what your product achieves)
Ask them if they think it can help them achieve X
Ask them if they think X is something they need help with
Ask them if there’s something they need help with more than X, or in addition to X
Ask them to navigate around the prototype and talk their way through it: what they see, what they assume features are for, what they’re confused about
At this phase, you should already have vetted your idea, but you still want to take the opportunity to gain feedback on your overall concept, not just on product design.
You can also use these additional tools and processes to vet your concept before proceeding. You can do email and LinkedIn outreach to learn more about your target users wants and needs, and you can launch a form to gauge interest level like Joel Gascoigne from Buffer.
Make necessary changes to your prototype and you’re ready to proceed.
4. Backlog creation or approval
With an approved prototype, you’re ready to create your backlog. A backlog is a list of everything your development team will be doing. It should be both high level (the necessary steps along the course of development) and detailed (containing estimated time, purpose, development platforms and languages used, etc.).
If you’re working with an experienced development team, they will create the backlog for you, and you will need to approve it. They should explain to you why everything is in the backlog to make your decision easier.
Because you’re in the MVP stage, they should only be building the necessary features in order to launch and gain paying customers.
This is the stage at which you have the chance to hack at your idea. Is it truly an MVP? Are there features that can wait until after you’ve launched?
5. Development and UX design
So, how long does it take to build a saas product? That depends. It could take anywhere from 2 months to 10 months, and possibly longer, but for most SaaS MVPs, it shouldn’t take longer than 6 months. We build MVPs in 3 months on average.
Faster development not only saves money on development costs, but it also increases your speed to market, meaning you can launch to beta users and then paying customers much faster. The quicker you get to MRR the better.
During the development and UX design phase, your development agency should give you regular check-ins.
With our clients, we have the dedicated product manager check in every day with updates. If anything is taking longer than expected, our clients are the first to know, that way they can make adjustments to the feature set dependant on their budget and amount of runway.
Very rarely do new entrepreneurs succeed with managing developers, designers, QA engineers, product managers, and DevOps engineers all on their own. That’s why we include management of a full agile team in our process.
6. QA testing
The next set to building a SaaS product is quality assurance testing. There are lots of different types of quality assurance testing, but they all fall into two main categories: manual testing and automated testing.
Manual testing: QA testers essentially bang on the app looking for bugs. They may do exploratory testing and use it just like a real user would, or they might go through a list of manual tests, executing each function and each variation in order. Then they log issues in a platform like Jira or Github so developers can address them.
Automated testing: QA engineers write scripts or use a low-code automated testing platform to create tests that run 24/7 and generate reports with issues.
We’ve put QA testing as a separate step, because there is a large amount of testing that happens before deployment. However, the best development teams will run testing on each feature and user flow as it is built.
After a solid round of QA testing (in addition to testing that was done as each feature was built), it’s time to deploy the software to the cloud. This is where a DevOps engineer comes in.
There are many different deployment models that can work for SaaS, including multi-tenant servers, single-tenant servers, private cloud, and on-premise data center. While many enterprises will want to manage a private cloud, new entrepreneurs are typically better off with a vendor managed solution. We recommend AWS Lambda for a scalable solution.
8. Continuous testing and DevOps management
The most successful SaaS products and mobile apps are deployed continuously, and they’re also tested continuously. You should have proven agile processes in place for both.
9. Building new features
After you go to market, you should immediately have a backlog of new features to build. Why? Because if you went to market and felt like you built enough, then you didn’t create a true MVP.
You likely already have some basic features and user flows that need to be built. You’ll also need to take feedback from beta users and customers about what needs to be built. Just send them a simple email and ask them to reply with what features they’d like to see.
Building a SaaS product is incredibly complicated.
Entrepreneurs who try to do it themselves face these common problems:
Don’t know how to manage different roles to improve collaboration and efficiency among developers, designers, QA testers, DevOps engineers, and product managers
Developers aren’t using technology that saves time and money on development (low-code platforms in combination with custom code)
Team doesn’t understand how to build a true MVP and is building a product that is too large
Team is overcomplicating everything from the product to the development to deployment