First of all, let me start by saying you all have built an awesome application. The ease of use and level of customization is absolutely amazing.
The question I have is related to how the different plans work. All of them are based on the number of unique monthly users. The app that I’m building will obviously have a landing page and a few basic pages (“Find Out More”, “Contact us”, etc), but ultimately 99% of the app is only going to be available to those that sign up and can actually log into the site. Are the users that access the front-end pages going to be counted as unique users? I ask this because, as all of us hope when we design this app, it could generate a very large amount of traffic. If I have 10,000 users that access the landing page to see what we offer, and then we truly have only 500 monthly subscribing users, I don’t want to get a massive bill at the end of the month because the traffic exceeded the current plan I use.
Cool. A user hitting the homepage still counts as one user, but gets merged with the user that signs up if this happens. The way we identify users then is with a cookie in the browser.
We’re still working on pricing though, and trying to figure out the best approach. Ideally we’d like to use storage and bandwidth, but felt like unique visitors are a more accessible metric. We’ll refine this in the coming months.
Thanks for the clarification. I definitely like your pricing model, but since I can’t control how many users access my site once it goes live, I’m a little scared to put it out there. A good article from a popular news outlet would drive a lot of traffic to any site they feature. I don’t want to pay $1700+ that month for something I can’t control.
Well, if you host your app on AWS or heroku yourself, it’s the same, if a news outlet features you, you’ll pay more (and I think that’s the goal no?). We use AWS ourselves, and our pricing follows their curve. We just take a premium on the top of it.
Again, we’ll refine our pricing and don’t want our users to go bankrupt if they have some traffic At the end of the day though, traffic leads to higher server costs, but this is inherent to building a tech company.
I’m also a bit concerned about the pricing model. $19/mo starter plan is reasonable given the functionality here and the fact that you’re hosting, too. However, the high-side uncertainty is difficult to get around. In my case, I’d be using Bubble to recreate and run an event that I’ve run successfully for the last four years using a self-hosted Wordpress site, which has been $100/year for hosting and a handful of premium plugins with one-time cost of maybe $60 total. Almost all of my traffic comes in March/April, where according to Google Analytics I get about 20k uniques. No complaints from my host, which operates a shared server model.
To go from that (call it $120/year) to Bubble (projected ~$400/year) is a big jump – especially given my app is just a writing/teaching event that I host personally, not a business – but given your (excellent) functionality, I am strongly considering it. But to think that one “lucky” promotion by a teacher’s organization or popular writer, leading to a bunch of in-and-out users who make zero or one click each, resulting in negligible storage and easily tolerable incremental bandwidth, could cost me hundreds or even thousands of dollars is making me really nervous. Neither storage nor bandwidth – even in peak months – have ever been even a remote concern for my current web host making a steady $100/year (never less, never more) off of my site.
Seems that a storage/bandwidth model could make sense for Bubble users like me, though I’m sympathetic to your concern about how to communicate that clearly. For what it’s worth, my host today allows 100GB of storage, 500000 objects (inodes), and 1000GB/month bandwidth (and 100 minutes of CPU time, 20 minutes of SQL time, and 20 simultaneous processes, if you care about those things), and provides a panel showing me exactly how much of each of those I’m using at any given point in time. And if I need extra bandwidth, it costs $1/GB/mo.
As I said earlier in this thread, we’re going to refine our pricing, probably using the number of workflow runs, which is a better and more accurate view of an app’s usage of our infrastructure. That should address your points.
Yes totally agree, I have just opened a thread about it as I am worried too that Bubble becomes way too expensive for a tiny app.
with what I calculated, 10 000 workflows will be eaten very quickly with only 100 users per months.
It would have been nice to have a package that let us have like 3 workflow for free per page and make us pay the extra workflows after that, this way we can then refine our app in a way that makes it less expensive for us to build.
Remember, some people will sell apps and make money from them, others will hope to get clicks from ads, I am this type of people who like to spend as I grow and not before and I think the Bubble team should think about this, thanks!
At the end of the day though, traffic leads to higher server costs, but this is inherent to building a tech company.