Skip to content
All posts

How to keep SaaS costs under control as you grow

It is important when looking at the pricing model of the platform you are considering to evaluate not just the cost to get started, but also how costs scale as your operations grow and mature around your new platform.
 
This article will guide you through up-front thinking that can help avoid common pitfalls when rethinking your content operations around a new SaaS CMS.

If you do not properly evaluate how costs increase as you grow, you risk becoming a victim of your own success: Costs spiral out of control as you create more content, roll out more sites, and attract more visitors.

Be aware of the end, at the start

Many SaaS vendors publicise entry-level pricing, which is designed to provide a self-service, low-barrier-of-entry way to get started with their products.

These will typically be sufficient to get your first project or MVP started, and perhaps even get it running in production. There may also be clearly-priced subscriptions sufficient to scale up and run multiple projects without requiring an enterprise-level subscription.

SaaS vendors often do not, however advertise their enterprise or premium pricing. We strongly advise to get clarity on this model even if you do not expect to need it in the short or even mid-term.

It is not uncommon for the step up to an Enterprise subscription to result in a 1000% price increase. 

If you are already running a solution, this is not the right moment to evaluate which vendor provides the best value for your growth needs: Switching vendors may be even more costly, and you are now locked-in with little choice but to accept the increased cost. 

Map your ambitions to costs

SaaS software licensing is almost universally based on providing different levels of service, with feature and consumption-based usage limits for each level and a guarantee on system availability (uptime SLA). 

There may also be additional costs associated with add-ons for particular features. It is key to understand the expected growth of your organization and how that translates to usage limits and costs for a given vendor. 

For example:

An acquisition-driven business who is building a portfolio of brands will want to ensure its not a simple x N calculation on licensing costs as N new sites are added to the platform.

Organizations whose operations are de-centralized, will want to pay closer attention to how costs scale as more and more casual users are added, than those who centralize their operations around dedicated teams of full-time users.

For companies entering new markets, compliance requirements such as geographical location of data centers and single sign-on (SSO) may come in to play.

Five main factors affecting cost

The following gives guidance on the five main factors involved in restricting CMS system usage. 

  • The number of environments
  • The number of sites or projects
  • The number of users
  • The amount of content
  • The amount of traffic

Most of these factors will typically be in play, although they are sometimes hidden in the small print behind other headline factors which sound important, but are actually less relevant for your organisation.

While you can often pay pro-rata for over usage within your current subscription level, take care to understand at what point it makes sense from a cost perspective to move up a subscription level, or indeed what hard limits might force a subscription upgrade and introduce significantly higher cost.

1. The number of environments

As a minimum you will need to have an environment dedicated to running your projects in production, and separate environment(s) where development and testing can take place.

Terminology here can be confusing and is not consistent between vendors, but usually a subscription level will allow you to work within a number of distinct environments or spaces.

2. The number of sites or projects

If it is likely that you are going to be onboarding a lot of separate websites, you may want to look at a vendor who does not limit the number of sites that you can run within an environment or space.

Even if there are no limits in theory, ensure that you get guarantees from your vendor that their software is specifically designed to handle multiple sites in a single environment or space. Also be aware of other related limits (like user roles) which might in effect mean that you cannot create a proper site or project segregation within an environment.

You do not want to encounter issues down the line and end up needing to purchase additional subscriptions when you discover that assumptions made during procurement do not hold in practice.

3. The number of users

Global companies with regional marketing teams will have a mushrooming user base as your platform is rolled out. Watch out for casual users who are not working day to day in the system, but still require access, or consider centralising some aspects of the operation of the system to limit the user base.

There may well be a restriction on the number of users who can log in and work within in the system, with an additional cost per user.

4. The amount of content

If you are managing large amounts of content, pay attention to content related limits for each subscription level. Watch out for limits on:

  • Content items. Be clear on what a content item actually is. A single page may be made up of many different content items.
  • Content types. If you are managing lots of different types of content you need generous limits.
  • File size. Make sure that the assets you plan to store in the CMS do not exceed limits.

5. The amount of traffic

If your websites have a high volume of visitor traffic, or you are serving a lot of rich media, such as video directly from your platform you will need to pay attention to bandwidth limits.

SaaS software vendors will always increase costs based on outbound data bandwidth and/or number of website visitors, as their underlying cloud infrastructure providers have cost models based on bandwidth usage.

Make sure that you have a good estimate of your current bandwidth/visitor usage, and align with growth ambitions of your organisation to form a view on what your future needs will be.

For high consumption sites, a well-designed platform architecture is essential, both from a performance and cost scaling perspectives. 

Be sure to take into account any API request limitations, especially when working with headless or composable architectures.

What's not in the box?

There is an increasing trend to make low cost or even free subscriptions almost as feature rich as higher cost subscriptions and restrict usage based on the consumption factors mentioned above.

It is however, important to be alert on the capabilities on offer at different subscription levels, and indeed within the platform as a whole.

Whether it's a headless or integrated CMS platform don't assume that it provides the same capabilities as your current vendor.

The following are some key capabilities, which may not be included in the platform you are considering, and only available as a paid add-on or plug-in either from the vendor or via a 3rd party: 

  • Visual editing/composition tools
  • Single sign-on (SSO) integration
  • Digital Asset Management
  • Integration with translation services
  • Search
  • Experimentation and personalisation

Costs can stack up and procurement can be complex if you need to purchase and integrate additional systems to separately handle the above capabilities. 

On the flip side this may be a strategic choice, to not put all eggs in one basket and work with a variety of vendors who align best with your business needs and provide more flexible pricing.

Service availability

The main factor to consider is the guarantee of availability of the system itself (the uptime SLA). Typically, you will separate this out in to the availability required on the back end (managing your content) and front end (interactions with your content).

99.9% uptime guarantee means that the system will be unavailable a maximum of 9 hours every year. For the back end this is usually more than sufficient, but for a 24/7 global eCommerce site, this may not be an acceptable front-end uptime SLA.

It may not be necessary to push for a higher front-end uptime SLA from your vendor however. For mission-critical sites, you can architect your platform to reduce dependency on CMS uptime.

Another factor to consider is support availability. Subscription levels provide different levels of access for platform support from chatbots all the way up to dedicated packages with 24/7 phone support.

If you are working with a solution provider who assists you with your platform, they may already be covering a lot of your support needs, so make sure you are not paying twice for the same thing.

Additional considerations

You should now have a better picture of the factors which can influence how your SaaS platform costs scale as you grow.

When choosing a new platform there are, however many more factors influencing your choice and the total cost of ownership of your content operations.

You can find further guidance in the following articles: