[Feedback Needed] Gadget pricing
I need a working group of ~10 people from an assorted mix (freelancers, agencies, app developers) to talk through potential pricing changes and get a sense of what everyone's preferences are.
I am looking to correct a longstanding Gadget pricing mistake where we have loaded the cost of a lot of what we do into request time. The net result is that some apps underpay because the things they use are not priced, while other apps overpay because they use request time much more heavily at scale. My intent is not to increase Gadget's revenue, but to figure out the right price points so that people are billed more fairly for their actual usuage. So if anything, my expectaion is that some of the bills shift, but in aggregate Gadget doesnt actually make any more money, it just has a more fair pricing system that doesnt penalize select use-cases.
My current thinking is that:
1- I need pricing items that are tied to our efforts, and our costs:
* unbilled request time and bandwidth when moving data from PROD DB to read replicas
* a price for indexed data served via Elastic (the bandwidth, the actual storage, and the
* CDN bandwidth and usage
* possibly concurrency caps with ability to buy more workers for a fixed price
^ Moving to a more granular pricing model (withou making it too complex) means that people pay for what they use ^
2- Reduce request time fee by A LOT (30-50% vs today's price) . Once we build 1, alot of revenue will now collected correctly from the user that is using services. So there is no need to take the cost of all those things and pad request time which penalizes everyone, regardless of how much of each service they use.
I need 5-10 interested volunteers to periodically get on a call with and talk through. If youre interested, reply with an emoji and I'll reach out in due time.
I am looking to correct a longstanding Gadget pricing mistake where we have loaded the cost of a lot of what we do into request time. The net result is that some apps underpay because the things they use are not priced, while other apps overpay because they use request time much more heavily at scale. My intent is not to increase Gadget's revenue, but to figure out the right price points so that people are billed more fairly for their actual usuage. So if anything, my expectaion is that some of the bills shift, but in aggregate Gadget doesnt actually make any more money, it just has a more fair pricing system that doesnt penalize select use-cases.
My current thinking is that:
1- I need pricing items that are tied to our efforts, and our costs:
* unbilled request time and bandwidth when moving data from PROD DB to read replicas
* a price for indexed data served via Elastic (the bandwidth, the actual storage, and the
* CDN bandwidth and usage
* possibly concurrency caps with ability to buy more workers for a fixed price
^ Moving to a more granular pricing model (withou making it too complex) means that people pay for what they use ^
2- Reduce request time fee by A LOT (30-50% vs today's price) . Once we build 1, alot of revenue will now collected correctly from the user that is using services. So there is no need to take the cost of all those things and pad request time which penalizes everyone, regardless of how much of each service they use.
I need 5-10 interested volunteers to periodically get on a call with and talk through. If youre interested, reply with an emoji and I'll reach out in due time.
