Hacker News Reader

Comment by raphael-gold | Hacker News Reader

yes for the free tier we host the website. Starting from the paying tiers we enable self-hosting. Today it is still an on-demand feature but we are planning to enable self-hosting in self-service before the summer. We also plan to have one-click integrations with Netlify and Vercel (we are in discussion with them at the moment).

Yes, the tool is in the space of no-code site builders, we typically see users choosing weweb when they've outgrown their regular site builders like Webflow, Wix or Squarespace and want more customization options.

View on HN

When it comes to the per-visit limits, what exactly counts as a visit? Being crawled and indexed can quickly consume hits if they are simply renderings of the page. Even the business tier seems really limited if that is the case. Especially for 100$ a month.

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?

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.

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.

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.

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.

Reply on news.ycombinator.com