This is all well and good when dealing with optional features/functionality. But 'required' fields present a challenge. Such as adding a required field to a for

This is all well and good when dealing with optional features/functionality. But 'required' fields present a challenge. Such as adding a required field to a form, or updating some process with an additional step. If the UI is added last, but the backend logic is ready and available before the time in production, this would suggest that your backend is either using dummy values temporarily or using additional logic to work around the release delay. In either case, this means: - cleaning up said extra processing/dummy value logic when deploying said feature for real (potentially introducing bugs during this step); - requires reverting data storage in the event of dummy input being used where such data needs to be persisted (I'm assuming the backend has been updated already to cater for the required fields since the changes are already in production); and - other (backend) systems that feed from the other end of the API that now depend on such a field being set, now either need to treat the field as optional and at some later stage add any validation, etc, -or- needs to be scrubbed of such dummy data as well (not always possible). Seems that the answer in such cases is that enabling the option on the UI is not the keystone, but rather the usage of said fields in other APIs or functionality within the backend. But this complicates matters depending on the backend itself as well as the required usage of said required field(s). So while I can see some value here, I dont think required inputs are as simple or easy to chalk up.