1. Will I get locked in?
One of the key benefits of having a composable system is that you can make changes or switch out products as you grow and mature. The services that were right for you when you were a small business might have limitations once you become an enterprise, but changing them no longer requires a complete system migration.
It seems silly to think about the end before you’ve even reached the beginning, but it’s important to consider portability from a technical and licencing perspective from the start. Can you get your data out? If there is a transaction history, is it meaningful? If there is an open standard, has it been used?
2. What will it cost (and I’m not just talking about the price)?
Cloud costs are complicated. In the old days of monolith systems, you could negotiate a licence fee, buy some servers, allocate costs to CapEx and OpEx, and have a solid understanding of how much you were likely to spend in the coming year. Now that many operational costs are shifted to the vendor and licences depend on your user activity, an entire FinOps industry has sprung up to try to predict and optimise system spend.
Pricing can hardly be considered a forgotten consideration, and yet it's important to thoroughly explore the licencing models on offer. Remember that this now covers the hidden costs of keeping your servers up to date or running an out of hours service to support them. Similarly, it’s crucial to understand your own projections for usage and growth: some solutions come with a transactional cost which can be incredibly cheap for low usage, but quickly gets very expensive as you use them more; others have a higher monthly cost, which can become essentially nominal in systems with larger volumes of traffic.
3. What happens when you get hacked?
In a world where the only responsible prediction of a potential security attack is that it’s a matter of when and not if, it’s crucial to fully understand partner security and the impact of any breach.
Look for evidence of secure design and operational practices – for example, adherence to standards such as ISO 27001, PCI DSS, or the appropriate CIS Benchmarks. Even the best systems might be compromised, so also look for evidence of regular security reviews, pro-active alerts and monitoring, and a recovery plan in the event of a total outage.
4. What’s your update strategy?
A common mistake is for businesses to assume that once a SaaS has been integrated, it will work as-is forever. In fact, a diverse SaaS landscape means that there is continual change (normally for the better).
One of the benefits of working with service vendors is that you no longer need to worry about security patching, or small improvements. Releases no longer happen on an annual basis, and bug fixes can potentially be live within hours of first being reported. The flip side is that you might not know when they will happen, or what will change.
There are many different approaches that a provider might have taken, so it’s important to understand how they operate. Do they make frequent incremental changes, or if they favour larger releases, will they require maintenance windows and system outages? How are these releases scheduled and how are you informed? Does this work for your own availability commitments to your users?
5. How can we see system health?
In a composable system, “Is the website down?” is a surprisingly difficult question to answer. An outage with your address lookup provider won’t be visible when you check your landing page, nor will it be immediately obvious when you examine your checkout, but it could potentially have a significant impact on the volume of abandoned baskets you can see.
Does the vendor supply a way for you to see if a service is available, and even better, can you link that information to your own observability platform? Understanding customer journeys and behaviour is a key part of optimising site performance - how easy is it to trace transactions as they pass through external systems?
