I do a lot of work where I rapidly mature business functions/processes, generally related to analytics and data work. I basically fill a self-supporting busines

I do a lot of work where I rapidly mature business functions/processes, generally related to analytics and data work. I basically fill a self-supporting business role, while handling the technical needs until the processes fully mature. A core concern of mid/upper level management is sustainability, reproducibility, and maintainability of processes. The CTO wanted a format that could be reliabily reproduced by the skill sets that were staffed, even if the report itself was less robust than the Data Studio version. By introducing a new capability to a client, the CTO is in a bind to either adjust staffing to ensure deliverability of that capability or potentially risk losing a client if they ever have to switch back to the previous reporting after having elevated the clients expectations. And the issue expands beyond that one client. It can potentially disrupt the expectations of other clients, and shift internal demand away from the types of reports your existing staff are capable of producing. And that's a huge can of worms since the demand may shift faster than attrition, leaving the CTO in the uncomfortable spot of having an existing staff with a rapidly dwindling internal demand and yet still needing to aggressively hire for the newer skillset. If it had been used internally, rather than being exposed to the client, then it probably would have been received better by the CTO. A technical analogy would be the CTO learning that a manager had approved exposing an unofficial API to important external users, and that the users loved it. So then you either piss the users off by taking it away and shifting them back to the cruddy old official API, or suddenly have a need to put resources behind ensuring that unofficial API is up to snuff and matches the same SLA with your official one.