There are a few ways to slice this.
From a client's standpoint, feature flags can raise some concerns. Is the system well-tested in various combinations of feature flags? Are all of the endpoints (both UI elements and request endpoints) protected against usage when the feature flag is set to a disabled state? When you introduce a third-party to manage those feature flags, there are additional concerns. What happens when the third-party system experiences an outage? Is the ability to toggle the feature flags secure and access well-controlled?
From a developer's standpoint, feature flags add complexity to a system and must be considered throughout the product development life cycle. What features need to be behind a feature flag? What happens if multiple feature flags are interwoven? How do we adequately test in all of the valid states of the system?
Depending on the environment, different types of feature flags are more useful than others. For example, instead of using a third-party service like Launch Darkly, consider a configuration file that requires you to redeploy your system or feature toggles in an administrative UI console. In other cases, feature flags aren't the right solution. Sometimes, keystone interfaces are useful. In other cases, separate branches are the right way to go. The choice depends on the specific requirements of your system.
When you provide software-as-a-service, I do not believe that customers should dictate how you go about building and deploying the software system. There are functional requirements and quality attributes that dictate how you design, build, test, and deploy new features or functionality. There may be regulatory standards at play that need to be treated as requirements on your product as well as the processes used to build it.
As a SaaS vendor, your obligation should be to demonstrate that you meet all of the requirements - regulatory requirements, functional requirements, and desired quality attributes. You should be able to simulate and test under various error and failure conditions to give your client sufficient confidence in your ability to provide the services agreed upon.
Coming from regulated environments, I'm used to questions such as this from clients. My approach is typically:
- Collect information from vendors and suppliers. This may include various industry-standard audits and assessments (ISO 27001 and SOC 2 are common, but others are more industry-specific). Other information may be documented on their website or in a contract - clients and testimonials, case studies, terms of service, and privacy policy.
- Perform a vendor assessment. Using the vendor's information, support how they will support meeting the requirements levied upon the system under design. If the client's documentation is insufficient, using a demo or trial period in a test environment to capture information may be a good idea.
- Allow for your development process to be audited. If you're a larger enterprise, there are various standards you can be audited against. Clients may also want to audit you directly. Have clear descriptions of how you work and how those ways of working satisfy every aspect of the software development life cycle and their requirements.
- Explicitly walk through your testing process. Demonstrate that you have appropriate coverage (preferably automated) around your feature flags. Although I know that it's not necessarily the most useful, things like code coverage reports can demonstrate that you're able to test. Also, explicitly go into how you manage environment access and who can toggle flags. Demonstrations go a long way.
- Have a demonstration environment that mimics production, especially if testing can't be done in production. This can give your clients the ability to understand your application in various states. They can gain confidence in the architecture and even toggle features on and off in different combinations without affecting the state of production.
