[ghiculescu]

Lots of good answers below on how to make it work, how you should charge more, etc.

Remember that saying no is also an option. You aren’t obliged to say yes just because someone asks for something you don’t sell, even if they are willing to pay.

For most SaaS there’s no logical reason why having a feature for 2 extra weeks would be an enormous advantage to a customer. In my experience what this question really is is “can we make last minute change requests to a feature you thought was done”. I’m not keen to guarantee that, so it’s a simple no, sorry, we can’t do that. It’s yet to be a deal breaker.

[cosmie]

> For most SaaS there’s no logical reason why having a feature for 2 extra weeks would be an enormous advantage to a customer. In my experience what this question really is is “can we make last minute change requests to a feature you thought was done”.

If you frame it as early access, then people are apt to try to throw their wishlist at you, thinking it's still "not official yet" and easy to change.

But based on what OP asked, I'm not sure that's the primary reason. It seems more like his larger clients are finding the changes disruptive enough that they're wanting advanced notice to prepare for them. So integrating a lot of the suggestions here can very easily address that issue, while also providing leverage points for client management and sales.

@OP - don't think about it in terms of preview access or letting them into your internal sandbox environment(s). But rather, restructure your releases to decouple the release from the account migration. Using feature flags and such then allow end users to determine whether they immediately migrate to the new feature when it's available, or if they continue with the status quo and wait a few weeks to familiarize themselves with the changes before opting into them.

For end users – this gives them room to both continue with their day-to-day needs using the process they're already familiar with, while giving them flexibility to familiarize themselves with the changes and prepare (in whatever form they need) before committing to them.

For the tech team – there's an initial lift to adjust the app architecture to support this type of usage, but insulates them these sorts of client requests in the future since the app now supports these types of opt-in migrations within the live environment. If a user wants a sandbox account, it can be provisioned as a normal account in the live environment but with sandbox-like restrictions applied to it.

For the sales/account teams – this can be used as a negotiation point. You can position it as normal accounts get auto-migrated to new features upon release, but enterprise clients can pay for the ability to control their own release/migration timing via these opt-in feature gates. And a sandbox functionality (which provisions a new account using the current configuration of their existing account, but with applied sandbox-like limitations) allows them to both prepare for it and test it in a controlled environment before enabling it on their primary/production account. That sandbox capability is independent of the opt-in capability, and a second point of negotiation.

And since your application now supports both of these directly in production and doesn't require bespoke work or custom environments from your tech team to support, the incremental cost is pretty minimum to give it to a particular client. Which is hugely useful for a sales team when closing larger accounts. They can give it away without much hassle if they have to in order to close a deal or provide value-add during renewal, while simultaneously capturing incremental revenue from clients that are willing to pay substantially for these sorts of things.

[cbono1]

Thanks for the additional context here.

I think some of the administrative pain can come from having a 'sandbox' or 'qa' tier beyond dev (which in this case would be customer facing) before production.

If data separation isn't required/essential, seems as though a a separate environment is actually unnecessary and feature gating could be used. But if data separation from other customers is required, then new infrastructure should be introduced via separate CICD if I follow correctly?

[cosmie]

> I think some of the administrative pain can come from having a 'sandbox' or 'qa' tier beyond dev (which in this case would be customer facing) before production.

Pretty much. It's hard to guess at the reason why without knowing the product, but for whatever reason customers are wanting access to new features/releases before using them. Which likely means that they need to do something on their end every time you release (validation, update internal training/process documentation, etc). And it's causing disruption when things change outside of their control. So they're wanting more control over that change timing, to smooth out the impact of those releases as far as their usage goes.

If your release codebase can only support a single "production" version of a feature at once, you end up having to provision entirely new environments to hold a client back. And again, for every client wanting this. Because the timing they want isn't going to be convenient enough to be the same.

So instead, structure things so that you can run both the old and new version of "the thing" simultaneously in production, and give the client self-service ability to activate the new version when they're ready. That way your production environment itself is able to accommodate these requests and client's can opt-in when they're ready/comfortable to.

The biggest challenge to doing this tends to be architecting your application so you can push releases to the backend independently to releases in the frontend. Which can generally be handled by routing things through middleware that provides a stable response for a given feature version. If the interface is using the latest version, the middleware is basically just a stub that does nothing. But if the interface is using a prior version, then the middleware accepts the request signature of the prior version, translates into what's needed to execute on the new codebase, and returns a response that's consistent with the prior version. It's a few years old, but here's[1] an example of how we handled the data-model aspect of this sort of setup at a prior company

So in effect you're actually upgrading all customers to the new release at once, but from the customer perspective everything still looks/feels/act the same as they're used to until they "upgrade/opt-in" to the new release.

It's a pretty major lift to implement this architecture (particularly on an existing codebase), but maintaining it is easy to incorporate into the regular development process. And completely eliminates the operational and customer management headaches you're having now.

With this architecture, it doesn't really matter if you're running isolated deployments or a multi-tenant architecture. You only ever have a single version of production in both cases. The "sandbox" isn't a new environment, but a new production account that copies over the configuration/setup of their existing one while applying sandbox-like restrictions to it. This gives them a temporary space to prepare for the change so they're prepared when they flip the switch on their primary account.

[1] https://github.com/TomFrost/Vers