This is a difficult question to answer with any precision without having all of the context. My answer will hence be somewhat generic.
First off, I am assuming you are referring to operational expenditure (opex) and not capital expenditure (capex); that is, the cost of operating a backend. If this assumption is not valid, the rest of this post will likely not be relevant.
Adoption and architecture are the two primary contributors to operational costs for an Extension. A developer clearly has control over architecture, but has limited control over adoption. I say limited here, as there are things that influence this that are directly in a developer’s control, whilst there are quite a few things that they cannot control. Implementing a non-scaling architecture can cause operational costs to inflate. In general, be very mindful of data flows between frontends and your backend. For example, if your Extension frontend heartbeats a backend, think of the consequences of several large channels going live with your Extension. Immediately hundreds of thousands, or millions of viewers, and hence connections…
To simplify things, we are taking a multi-pronged approach:
- Providing different paths for monetising Extensions; and
- Providing building blocks that abstract the need to implement as much scaling logic
Personally, I would love to get to a place where developers are able to make a living creating Extensions, and for a decent number of use cases, allow Extensions to be created that do not require a developer hosted backend.