Another option might be a multi-tenant compute/data architecture where everyone is NOT run on the same compute/database, and instead is in a serverless single tenant architecture in different cloud accounts.
The multi-tenant part of your saas would amount to pushing regular automated updates to individual cloud accounts each with it's own serverless compute/data infra. This should make the core app simpler to build, and push complexity of multi-tenant into systems to manage the apps. Also you could get geo benefits by putting compute/data closer to where it's used. With serverless it should be more cost competitive than the days of operating actual servers.
Depending on your market focus and potential of less demanding customers, it also might make more sense to just avoid these large "semi-custom" customers which will no doubt be very time consuming and need many special features that no one else cares about. If you spend time building those customizations out, you are then stuck managing them after said large customer leaves. I have seen this happen and am wary of any single large customer feature "demands".