4 ms·

that's a good point, we are currently discussing this with our early adopters to find the right balance. We might increase this per-visit limits. What would be

that's a good point, we are currently discussing this with our early adopters to find the right balance. We might increase this per-visit limits. What would be a fair limit for the business plan according to you?

mekkkkkk 6y ago
If you could use heuristics to discard automation such as search engine indexing and open graph lookups, then the limit is probably fine. I'm not sure I'm a fan of the pricing model in general though. If I were you, I'd look into smart caching, traditional (high and scaling) bandwidth limits, and instead applying tier limits on updates/edits/data pulls. More user friendly, more generous for smaller projects and slightly less open for exploits. In the current model (with no heuristics), you could shut down one of your customers in 5 min just using curl.
- raphael-gold 6y ago
  Yes that makes sense. Though, it would be hard to apply edits limits because the number of edits can vary greatly, independently from the purchasing power of a customer (for example a startup would change it's home page every other day while a large corporate would barely touch it once a quarter). The bandwidth or page views limits seem to be raising the same issue and the logic for us is simply to avoid server costs that would be too high for a single site that would pay a basic monthly subscription.
  - mekkkkkk 6y ago
    If a large company is not updating their site very often, then you do not have a great value proposition anyway. Your core product is ease of updating/editing and customization, no? Makes sense to charge based on that aspect. Of course you need some sort of traffic restriction for things not to spiral out of control. Putting this restriction on actual MB's transferred is an acceptable safeguard. Cache bandwidth is cheap using the right strategies, so your bounds could be pretty high while keeping it profitable.
    - raphael-gold 6y ago
      cool, great feedback. We'll look into implementing bandwidth restriction instead of page view, I had the same conversation with an agency yesterday and they were leaning toward your point of view.

mekkkkkk 6y ago

If you could use heuristics to discard automation such as search engine indexing and open graph lookups, then the limit is probably fine. I'm not sure I'm a fan of the pricing model in general though. If I were you, I'd look into smart caching, traditional (high and scaling) bandwidth limits, and instead applying tier limits on updates/edits/data pulls. More user friendly, more generous for smaller projects and slightly less open for exploits. In the current model (with no heuristics), you could shut down one of your customers in 5 min just using curl.

raphael-gold 6y ago
Yes that makes sense. Though, it would be hard to apply edits limits because the number of edits can vary greatly, independently from the purchasing power of a customer (for example a startup would change it's home page every other day while a large corporate would barely touch it once a quarter). The bandwidth or page views limits seem to be raising the same issue and the logic for us is simply to avoid server costs that would be too high for a single site that would pay a basic monthly subscription.
- mekkkkkk 6y ago
  If a large company is not updating their site very often, then you do not have a great value proposition anyway. Your core product is ease of updating/editing and customization, no? Makes sense to charge based on that aspect. Of course you need some sort of traffic restriction for things not to spiral out of control. Putting this restriction on actual MB's transferred is an acceptable safeguard. Cache bandwidth is cheap using the right strategies, so your bounds could be pretty high while keeping it profitable.
  - raphael-gold 6y ago
    cool, great feedback. We'll look into implementing bandwidth restriction instead of page view, I had the same conversation with an agency yesterday and they were leaning toward your point of view.