4 ms·
you're right it's.... special. Let me give you my thought process: - One time pricing can be a real hurdle for users to pay upfront. Remember adobe costing a
by thomasikzelf 5y ago
you're right it's.... special. Let me give you my thought process:
- One time pricing can be a real hurdle for users to pay upfront. Remember adobe costing a lot of money up front. The upside is that after this initial huge hurdle your free to use the product. For the business non recurring revenue means they need to batch changes to make buying the product worth while. This results in a long cycle between updates.
- Subscription pricing aligns the business with it's users. Users pay only for what they use and the business can ship features to the user as fast as possible.
- The downside is the subscription is often 'per user' and is done on an ongoing basis. You pay for the tool even if you don't use it.
- Usage based pricing: you only pay for what you use in the smallest quantity that is understandable. This is what I use and what AWS uses for example. I think this is a really fair pricing model. If you're only doing one project it might cost you 3 bucks, but if you are a company that uses the tool fulltime you pay accordingly.
It might turn out that too many people are turned off by this pricing, I don't know. It is easier to change to a regular pricing model then to a weird one :-).
If you open one of the examples that is one project. Your project can be published at one unique URL.
- sombremesa 5y agoDoes this really align the business with its users? With this model aren’t you incentivized to make users waste as much time as possible so their time spent in the app increases, which is directly convertible to $ for you? I’m not convinced. Maybe I’ve misunderstood something. Charging for time spent developing is very different from what AWS does.
- thomasikzelf 5y agoYeah you are right, there is no perfect alignment. I also agree that the usage based pricing from AWS is different from my hourly pricing (hourly being a subset of usage based). I've never seen hourly based pricing being used for tools before. But hourly based pricing is common for human services and also for things such as AWS Lambda or VPS's. You could make an argument for AWS having an incentive for slow running lambda's. In these cases you can test if the speed of AWS lambda is good enough for you. Similarly you can try out my app (for free) to see if it's slow or fast, and you can see this directly instead of having to rely on AWS's logs. Anyway thank you for your feedback. It's really valuable for me to read these responses!