November 21, 2019

12 Questions to Reveal Whether Your AMS Is Real or Pseudo SaaS

12 Questions to Reveal Whether Your AMS Is Real or Pseudo SaaS

If you’ve been reading our posts this month, you’ve learned that many AMS on the market aren’t real SaaS products. Why is that a big deal? Because you want to steer clear of pseudo SaaS AMS that come with hidden costs and undesirable consequences.

How can you get past the marketing messages and sales spiels to find out whether the AMS you’re considering is real or pseudo SaaS? Become a savvy AMS buyer by knowing what questions to ask and what answers to seek.

12 Questions to Help You Spot a Pseudo SaaS AMS

Hosting software in the cloud or providing software by subscription doesn’t make it SaaS. The benefits of SaaS come from its economies of scale, scalability, reliability, and readiness for innovation. These questions will help you find out what’s behind the marketing curtain.

#1: How many versions do you support?

For real SaaS, the only acceptable answer is “one.” If the vendor is supporting several (or dozens) of code base versions, that’s pseudo SaaS. They must hire and train staff to develop, support, and maintain all those different products. As a result, their focus is diluted and their payroll budget is higher.

#2: Will we be using the same code base as other clients?

This is another way of asking the same question—an effective method for getting at the truth. With a real SaaS product, all clients use the same version of the same code base. You also want to hear that everyone uses the same “instance” of code.

On the contrary, beware if you hear anything about “branching” or “forking off” code. What this really means is they’re customizing the code for your instance alone. Not good. As we explain in our post on customization vs. configuration, customization comes with many troubling implications.

A single code base allows for economies of scale, which means lower costs, more frequent (and free) upgrades, and standard integrations for you.

#3: Is the software based on single-tenant or multi-tenant architecture?

Here’s another way to get the answer you seek: find out how the software is designed (or architected). If the AMS is single-tenant, that’s like having your own software installed on your own server, except in the pseudo SaaS case, the server resides in the cloud.

You want to hear “multi-tenant.” For real SaaS, a single instance of the software and its infrastructure serves multiple clients. Each of them shares the software, but each client’s (or tenant’s) data is separated from the others. Multi-tenancy provides cost savings for the vendor and, therefore, cost savings for you.

#4: Do you support configuration or customization?

Real SaaS vendors use configuration to meet client-specific needs. Pseudo SaaS vendors rely on the customization of each client’s code base to meet their needs.

#5: Will a developer need to build functionality X?

Here’s another way to find out whether the vendor is planning to use configuration or customization to meet your needs—because it won’t always be clear. When you request a functionality that isn’t “baseline,” i.e., part of the core product, you must make sure it requires a configuration, not a customization. If the AMS vendor needs time for a developer to build a functionality—and make changes to the core code—then it’s not a configuration, it’s a customization—and it will cost you extra now and in the future.

#6: What if we want to change our membership model, can we make the necessary changes in the AMS without the need to customize or change the core code?

Ask about a possible change so you can find out how it would be handled—by configuration or customization. With configurations (the real SaaS approach), you’ll have the flexibility to respond to market needs and create complex membership structures, for example, different tiers of organizational and individual memberships with various relationships between them and different benefits attached to those relationships. Phew, sounds complicated, but configuration can handle that.

#7: Who manages upgrades, the client or the vendor?

In real SaaS, upgrades are tested and released to all clients at once with no downtime and no work on the part of the client.

However, with pseudo SaaS, it gets complicated. If you want to take advantage of upgrades, you’re responsible for getting (and paying) someone to rewrite your customized code. Then you have to apply and test upgrades to that code to make sure they work along with your existing integrations.

#8: Will we have to pay for upgrades?

Users of real SaaS AMS, like MemberSuite, enjoy free, frequent, and automatic upgrades. However, customized code kicks you off the upgrade path—that’s just one of the hidden costs of a pseudo SaaS AMS. If you want to take advantage of the new features and functionality included in pseudo SaaS upgrades, you must pay the AMS provider or a consultant to rewrite your customized code so upgrades can be applied.

#9: Will our configurations continue to work with future upgrades?

With Real SaaS, yes, configurations will continue to work for everyone. On the other hand, with pseudo SaaS, there are no guarantees. Your customized code may not work with upgrades, so you may have to pay to recode customizations.

#10: We want to integrate the AMS with our LMS, online community, etc. Are other clients using those same integrations?

With a real SaaS AMS, an integration built for one client will work for all clients because everyone’s using the same code base. If they say an integration is a customization, find out why. Is it because you’re the only one using your version of the code base?

#11: Are integrations supported through upgrades?

Upgrades don’t threaten the integrity of real SaaS integrations, but that’s not always the case with customized pseudo SaaS AMS.

#12: How often do you release upgrades? Can I see documentation for recent product releases and your product roadmap?

The frequency of past releases is a clue to whether it’s a real or pseudo SaaS AMS. If the vendor is too busy creating, supporting, and maintaining dozens of customized code bases, they don’t have the time or budget for innovation. As a result, releases—software upgrades and bug fixes—are less frequent. They may only occur once a year or once every 18 months. But, sadly, many clients don’t apply the upgrades because they can’t afford to pay for changes to their customizations and integrations.

With real SaaS, the vendor has only one version of the code base so they’re getting feedback on that version from all their clients. They have the opportunity, time, and budget to build new functionality that everyone can use.

Many of these questions ask the same thing in a different way, which is what you must do to get past a salesperson’s routine answers. Don’t move on to your next question unless you completely understand their response. Make no assumptions. Clarify and document everything that’s important to you so you won’t encounter surprises later.

Our AMS Buyer’s Guide explains in non-techie terms the architecture behind a real SaaS AMS, configuration and customization, and the hidden costs of a pseudo SaaS AMS so you can make an informed decision about your organization’s technology investment.