3 ms·
I'm a big fan of pushpin. 1.This landing page doesn't make the use cases clear. I think you need to show architecture comparisons that makes it clear. Ex: htt
by boundlessdreamz 9y ago
I'm a big fan of pushpin.
1.This landing page doesn't make the use cases clear. I think you need to show architecture comparisons that makes it clear.
Ex: https://heartbeat.appbase.io/index.html https://heartbeat.appbase.io/index.html
Btw appbase is a pushpin user right?
2. The pricing page is confusing. Ex: $4/million minutes along with $25 monthly. So does $25 come with any minutes? Also instead of charging for minutes/received messages/delivered messages, I suggest charging for just one ideally 'delivered messages' and also bundle some with the $25 plan. Charging for all three feels like you are nickel-and-diming the customers
3. Separate out public cloud hosting & on-premise and make the pricing transparent. i.e offer people an easy to integrate fanout into their cloud infra. See here for an example - https://mlab.com/plans/pricing/#provider=amazon https://mlab.com/plans/pricing/#provider=amazon
4. On-premise option should have transparent pricing especially at this early stage. You are introducing friction into the process and that's fine for a known product but for a nascent one it's better to have standardised pricing
4. Fanout cloud (as it stands) seems like a weird product. Since you have only PoP the latency introduced is going to be huge. I think focusing on public cloud offering like mlab is the way to go.
- jkarneges 9y ago> I'm a big fan of pushpin. Always good to hear. :) > Btw appbase is a pushpin user right? Yup. > The pricing page is confusing. The paid plan doesn't come with any bundled minutes/messages, however we're considering changing this (e.g. up to 50,000 minutes/messages, then pure-usage cost above that). It would be nice if we could abstract away the three metrics and only bill for a single metric, but I don't think it's economically workable. In practice, we pay a cost for all three, and they vary wildly by customer. Competitors generally account for all these metrics too (not an excuse, but...). I do agree the pricing page could be more clear though. Even the current pricing is sometimes misinterpreted. > On-premise option should have transparent pricing I rarely see this elsewhere, but I can imagine how it may reduce friction. Worth considering. > I think focusing on public cloud offering like mlab is the way to go Thanks for the tip.
- boundlessdreamz 9y ago> I rarely see this elsewhere, but I can imagine how it may reduce friction. Worth considering. Nginx Plus - https://www.nginx.com/products/buy-nginx-plus/ https://www.nginx.com/products/buy-nginx-plus/ Github - https://enterprise.github.com/features#pricing https://enterprise.github.com/features#pricing Bitbucket - https://www.atlassian.com/software/bitbucket/pricing?tab=self-hosted https://www.atlassian.com/software/bitbucket/pricing?tab=sel... Mattermost - https://about.mattermost.com/pricing/ https://about.mattermost.com/pricing/ You can have a "Contact sales" for a really big deployment but customers should have some idea about cost and ideally should be able to buy and try at a small scale.
- jkarneges 9y agoGreat examples. Thanks!