How to Estimate the Cost of a SaaS

There are numerous elements involved in the ideation, validation, estimation, build, launch, and growth of a SaaS system. The estimating step is critical as it helps you to understand if this project is “worth it,” how to proceed with funding, and what features should and should not be added to the Minimum Viable Product (MVP).

The SaaS Cost Estimate

This is where you either start off on the right foot or step on the hidden trap trigger like Indiana Jones’ bumbling tagalong. That’s because properly nailing down all of the various elements – and doing it accurately – is a vital task that takes some experience. This process accomplishes several things:

• It helps you and your team fully understand what you’re about to dive into financially.
• It provides a solid basis for your project scoping efforts, which will cut time and get the work going faster on research, planning, and build.
• It gives you ideas about how much various elements will cost so that you can find ways to strengthen your plan. It’s fine if the estimate is a wide range on a big project. However, as you would expect, the narrower the range, the easier it is to make a decision on whether to move forward or not.

Your initial estimate will likely have a wide range between the minimum and maximum costs, and that’s okay. After you have the basics down, you can work with your team, discuss details, and pin down estimates for different items with smaller ranges. Here at JH Media, we have a specific process for this, which we’ll be sharing in this article.

The SaaS Cost Project Estimation & Scoping Process

Before we talk about how to estimate the cost of building a SaaS system, let’s outline the overall project process. Here are our steps in a SaaS project process:

1. Meet with the client and understand their vision.
2. Evaluate the potential success or failure of the project. This is CRITICAL. If a potential client doesn’t know what they are getting into or are unprepared for the journey they are about to take, we will not work with them. This is because:
   1. They are probably going to fail.
   2. It’s going to cost them a ton of money.
   3. They are going to blame us to some extent.
   4. They are probably going to be difficult to work with.
   5. We don’t like taking people’s money if we can’t provide value. We have no problem telling someone they need to rethink the system and that we are not going to work with them until they do. It is ALWAYS better for everyone.
3. Meet a few more times to identify and clarify the major features and obstacles in the project.
4. Put together a project estimate (this step is what this article is about).
5. If the estimate is in line with their budget and they want to work with us, then do a small engagement to research the project and write up a project Scope of Work. This includes things like a:
   1. Contract
   2. Creative brief
   3. Information architecture (IA)
   4. Project flows or wireframes
   5. Project plan
   6. Final price or very narrow range
6. Engage in a contract for the full project.
7. Build the SaaS System.

Just to be 100% clear, this document outlines the steps in the ESTIMATION step, not the FINAL QUOTE or information architecture. This is the step prior to the architecture development, and the deliverable will be an estimate that gives a RANGE of costs while still delving into several aspects of the system.

Template and process for estimating a SaaS or large web-app project

Over the years we’ve put together a thorough spreadsheet, or template that helps us estimate every feature, every section, every subsection, and every page or view that goes into a SaaS system or large web-app project. If you take the time to work through this process with your team so that everybody understands what goes into the project and can agree on a good set of features, you can start figuring out a solid cost range.

After you have a good understanding of what goes into the system, you can use this tool to put together a solid estimate. From our perspective, this helps our clients to look over the project and decide:

1. If the project is ‘Worth It.’
2. If they want to go with our team.
3. If the project is potentially too expensive (no matter who they hire).

Moreover, our method is designed to be especially helpful because it shows people not only what the project build will cost, but also their ongoing operations costs.

So let’s take a look at the process for building a SaaS from start to finish.

This workflow chart is a handy tool for visualizing all of the steps involved in developing a SaaS.

This is a segment of our standard SaaS or large project build process. The item we’re focusing on is denoted by the blue circle and arrow: ‘Produce Estimate’.

This step in the process is most efficiently performed with three people:

• The Information Architect or Strategist
• The salesperson (sometimes)
• The Project Manager
• Oftentimes a developer or subject matter expert

Together, this team can list out all the features, most of the pages, all of the major features, and crank out a round number estimate.

This can all be done using the SaaS build spreadsheet mentioned above. This tool has multiple components, which we’ll break down one-by-one.

Begin With Pricing Standard SaaS Features

The first element of our project estimation template focuses on a listing of “standard features”. In this area, we start off with the general systems that every SaaS system needs. That includes things like a project setup, pre-launch site checks, launch activities, architecture writeup, UX design flows, revisions, design meetings, team kickoff, etc.

I would like to point out that the UX design flows (see red box below) line item can very often get way, way, way higher than 40 to 100 hours. This can be 500 hours, or 700, or even higher sometimes. It really depends on what the project is, what goes into it and the size of the project.

NOTE: The Dashboard estimates are strictly for the most basic version of a general SaaS dashboard; the dashboard’s specific features are listed in a different worksheet page called “System Specific Features”. We know we will almost always need to build a dashboard, so it is taken into account here. But the specific functionality of it will have to be outlined in the system specific area of the document.

Estimating the cost of standard SaaS or large project features

In addition to the setup, there are standard items like:

• Login and logout
• Forgot your password
• Permissions management
• Admin panel build
• Dashboard
• Billing systems
• Onboarding
• Email notifications
• Knowledgebase

Every single element of this will become critical at some point during the SaaS build. On this page you only need to address the basics – the base build without all of the flash. Again, there is a page dedicated to specifics, so don’t overload your estimates by doubling up.

Finally, as you’re going through and building this, we like to add in a percentage for general mobile responsive changes (see the blue box). In this case, we’ve got 10% on this, but sometimes it can be 20% or more. It also depends on how the system is being built.

So all of these things get added up to get our labor totals (green box), and then we add:

• A Project Management Percentage (Management gets paid, too!)
• Quality Assurance Percentage (Testing and Debugging)

What that means is we’re going to take all the hours, sum them up, and then take a percentage of that amount. Both percentages are 20% of all task-related hours, although these percentages can vary by project depending, for example, on the collaboration process with a particular client and the types of testing that will be conducted. 

Labor Hours Range

We end the rundown of basic cost estimates for building a SaaS with the totals area (in the red box). Not only do we have the min/max/average hours listed, but we also include, in each column, three totals:

• The average hours
• Plus 20%
• Minus 20%

This is just an estimate, and there are a ton of factors at this point that could sway the price as we move along. Having a range helps clients keep in mind how things can change based on how in-depth various functions and features are designed in each area.

SaaS costing as it relates to value metrics

The Value Metric is a variable that increases the price of the SaaS as it goes up. This can include metrics such as:

• Number of seats (users)
• Number of projects
• Number times the database is hit

These elements can greatly affect the amount of work that has to be done and the cost of the system for a lot of reasons. Namely, the more complicated the value metric or metrics, the more work has to be done to integrate this metric into the system and notify users of the change in price.

If it’s a matter of just the number of users, then it is usually a simpler solution. If it’s the number of projects paired with other variables, it can balloon the scope. The +/- 20% lines are used to give you perspective on just how much scope changes can affect the cost, which can help to keep everybody focused on preventing scope creep in the long run.

Project Estimates Aren’t Built In a Day.

In the case of the SaaS estimate that we’re providing for an example:

1. We’ve already had a minimum of two or three conversations with the client at this point.
2. We’ve asked most of these questions, but haven’t really delved in depth into everything (but we’ve got a good idea).
3. We have done a bit of research on the system to ensure it is actually possible to build.
4. As pointed out above, we (not just the client) think this thing is going to work.

Very often, the architect building the estimate has to enter hours that they aren’t 100% sure about because either there is research to be done to calculate hours or because the work done has unknowns such as integrations into 3rd party systems that cannot be predetermined without a substantial amount of work. So they enter a guess to have a talking point with which to go back to the client. In most cases it is important to make sure to discuss the entire system before completing the estimate.

NOTE: As this process is ongoing, typically every single box in the ‘notes’ column gets filled, which takes time, but is immensely valuable moving forward.

Everything we have discussed so far pertains to the Standard SaaS Features Worksheet. We’ve still got to go into system-specific features.

SaaS System Specific Features

The project in the image was for a really small system, just a few features. The majority of the special features centered around the Dashboard and a few client forms. Very often, however, this System Specific Features area can be quite large.

Just like on the first worksheet, we utilize the additional overhead percentages. For those who may not be too experienced with spreadsheets yet, here’s a closeup of how that’s coded:

 

 

 

An EXACT estimate on a SaaS or large project is impossible

Unexpected events and changes happen, unknowns pop up, and people just get sick sometimes. So you’re never going to be able to look at an item and say “that’s going to take exactly 7.32 hours total”. However, the more granularly you do your initial estimates, the closer you will be to an actual final SaaS cost. I recommend NEVER having a task that lasts longer than 4 hours in your actual scope of work. In the estimate though, we can sometimes see features with hours at 50+ hours.

Determining the total number of hours needed to build a SaaS

When we go to take a look at the overall totals on the system specifics page, it may come out to a big range. In this case, the -20% in the minimum column would take just 54 hours, and our +20% maximum weighs in at 170 hours. That is 3X longer!

But if we go back to the Standard Features page:

Here, the maximum of 1,604 is over five times larger than the absolute minimum of 296!

How accurate is a SaaS estimate?

The advantage here is that when we get done with the estimate, we can say that it’s definitely not gonna be less than 300 hours for this part and it’s almost definitely not gonna be more than 1,600 hours. And, this is the important part:

The more definite and detailed you can be, the more definite your cost range will be.

That’s why it’s so important to go through each item one by one.

Does a SaaS system need a website?

Almost always the answer is yes.

The next estimate we work on is for the promotional website. This example is just a standard, simple quote on a basic website.

This example is for a very basic website build estimate.

We’ve got design, development, quality assurance, and content. Sometimes we’ll come back and put a much more advanced quote together for the marketing website.

What ongoing costs does a SaaS system have after it is built?

The last major step we like to do when estimating costs for a SaaS system is to give our clients an estimate on what their actual ongoing costs are going to look like. It’s one thing to estimate the build cost, but another, entirely, to help them get an idea of what they’re going to be paying long-term to run their SaaS business.

While the build cost is very important, if you really want to accurately estimate the cost of a SaaS you’ve got a lot of ongoing expenses you have to take into consideration. Not everybody is prepared for these numbers, and running this estimate can make the difference for your long-term success.
Now you can plan for it accordingly.

The items included in the long-term costs for your SaaS will likely contain:

• SaaS Build, Management, and Maintenance costs: This includes things like third-party software, documentation, password management, time tracking, etcetera.
• Marketing: This is a big one. You need to have an idea about what your marketing spend is going to be, and it’s going to add up quickly. Most SaaS systems are really looking at $20k, annually, at a minimum, which is what this small SaaS system was quoted. That’s really actually very little money to spend on marketing a SaaS, but it’s a good place to start.
• Business setup costs: This includes any recurring private or public fees, such as insurance, fees charged for licensing at federal, state, or municipal levels, etc.
• Personnel: The cost of employees, payroll taxes, and human capital expenses.

Even for a smaller SaaS, the ongoing costs in this example run nearly $400k per year. This number is important because, for this client, that’s going to set the baseline. This can affect their pricing, their marketing strategies, and a host of other things that they can now make an informed decision about.

Breaking Down the Overall SaaS Costs

All of this comes together in the overall cost area in our template. This section includes our example SaaS system total average cost, minimum costs, maximum costs, and the +/- 20% on each area.

 

 

 

Initial. Monthly. And yearly.

Presenting the Project Estimate and Contract

The last thing to do is to present your initial estimate and start the conversation in earnest. From here, we work out every feature and determine what needs to be done on that feature, what your expectations are, what needs to go into the MVP, and of course, what it’s all going to cost.

We start off presenting a big min/max range with an idea on vision and most of the functionality, and then we go through each line with that client so we can narrow that range through clarification, education, and conversation.

Once that range looks good to both us and the client and we have a contract in place, only then do we start working on the project scope. After the scope and a more narrowed price are agreed upon, we embark on the project.

Conclusion

Doing an estimate for a SaaS or large project can take as little as 3 hours and as much as 3 weeks of full-time work (sometimes more). For the most part, we like to put this together for all the people we talk to. It helps them run their businesses just as much as it helps us to give them a quote on the project.

If you need help with your own estimates, or with any part of your SaaS build, please let us know! We would love to help you find success in your new venture.