One piece of criticism constantly aimed at SaaS is that it is not as ‘customizable’ as on-premise software. Before examining this claim further, we need first to define ‘customization’ from the perspective of licensed software in order to provide the proper context. Traditionally, ‘customization’ meant a change to the application source code or the creation of modules for a specific client, often with the result that the vendor ended up maintaining a branch of source code to support each client. With custom modules, the vendor would maintain only the modules’ source code but had to ensure that subsequent releases of the core product did not break compatibility with these one-off components. If they did, the modules had to be rewritten or the customer could choose not to upgrade from the version for which their one-offs were built. This strategy works for on-premise software vendors because all they need to do is to maintain customer-specific source code and/or modules. This complicates the software development life-cycle, but it also creates massive barriers to exit for the client since their customizations are owned by the vendor. And since the vendor usually charges annual maintenance fees, plus time and materials for customizations and module compatibility upgrades, this approach is often profitable.
By contrast, SaaS vendors should regard customization as a Cardinal Sin that, once committed, brings retribution that stretches into Subscriber Eternity as customization requests break the SaaS model. This includes any request for running a ‘private version’ behind a customer’s firewall or in a ‘hosted’ environment. By adopting this mindset, SaaS vendors will have an easier time saying ‘No!’ to the customer or asking for significant premiums to fulfill customization requests. Put succinctly, there is no way to handle one-off customizations within a SaaS business architecture.
But the reality is customers will still request customizations without considering if they truly need them. Some potential subscribers may refer to a checklist every time they buy a new accounting package. The original checklist included a requirement for a custom widget that no one has used in 10 years, but it is still a ‘must have.’ Why may have been forgotten. The department or person who originally made the request may be long gone. Yet the widget is still on the ‘must have’ list. When the company comes to your virtual door with that same checklist and asks for that widget, what are you going to say?
Before answering, it is necessary to stop thinking like a software company and think like a service firm instead. Ask yourself how a CPA would handle a client who asked to use an outdated IRS form. The CPA would say, ‘No.’ One of the reasons we’ve emphasized integrated analytics and community development so strongly is that if you are able to back your assertions with hard data and customer agreement, your credibility as market experts grows tremendously.
Many SaaS vendors will argue that one-off customizations will help them generate cash in the short term, which will in turn help them through the lean times while they grow recurring revenue. It is true that the custom design-and-build business can be lucrative and tempting in the short run, but over time it can do tremendous damage to your business by:
Flexibility is the answer to the customization dilemma for a SaaS vendor. At an implementation and configuration level, you must plan in advance what amount of flexibility will be built into your system. Ultimately, all of this should be dictated by your target market’s needs. Your goal when rolling out the ‘1.0’ version of your system should be able to meet at least 65% of the needs of majority of your target market. As subsequent versions of the system are released, your goal should be to increase that number to 80% and enable the 20% of specialized requirements to be met through inherent flexibility. This flexibility, including the user interface, reports, workflows, templates, etc., should be meta-data driven, where the underlying application does not change for each client. Being meta-data driven, each client, or even each individual user, can make changes to the elements on their own without going outside of the sandbox created by the system flexibility model.
When considering flexibility and your SaaS business architecture, remember that the more horizontal the product, the more flexibility will be required to meet the majority of the needs of the target market. As the focus becomes vertical or on a tighter niche, more can be built into the core product to meet a market’s needs. With a tighter vertical focus, it is also easier for the SaaS vendor to be thought of as the industry expert who understands the market’s requirements and best practices.