This is correct. Another way to frame it is to be upfront about development costs for custom features and bake it into the contract. A few ways I've managed to

This is correct. Another way to frame it is to be upfront about development costs for custom features and bake it into the contract. A few ways I've managed to do this in the past: If the feature seems like it will benefit all customers, but is not a priority, push back on timeline. Otherwise, validate with other customers and try to get multiple customers interested and/or on the hook financially to fund the work. If the feature seems like it may be will benefit some other customers but is not a high priority, then you offer the customer the ability to partially fund the development and work closely as a partner to accelerate building to spec. If the feature seems like it might never be applicable for other customers, my preferred approach is to say no, with an alternative proposal of building something jointly (i.e. we will consult for you to help you build this on our platform) while facilitating their ability to build the thing through whatever means (API improvements, examples, etc.). This always comes at a substantial markup over SaaS sticker price. Basically, unless you were going to do it anyways, get funding for it, and even if you were going to do it, try and get funding for it anyways. Mature organizations are used to this game and won't be shy to discuss options. The only caveat is when you openly advertise something in development or on a feature roadmap, it becomes much harder to lobby a customer to fund it. I usually advise founders to stick to table stakes features for the roadmap, like SSO. A savvy mature customer will have a purchasing team that actually reads your website to find opportunities to out negotiate you.