How accurate is the below estimate? I am one developer working on an iOS app and I WAS using the free Springboard plan. Now my app has been frozen and my plan switched to the Scale plan. According to the below estimate I would be paying about $200.00 per month? I don’t even have real users…just fake demo users. How can I afford to develop on this plan if these numbers are correct?
…oh these numbers are from Aug - Oct 2023 when I was full time actively developing.
1 Like
i should clarify that I HAVE to switch to the Scale plan because I have more than 10 tables. I don’t know of any app that wouldn’t have more than 10 tables ESPECIALLY in development when things aren’t optimized.
This new approach to billing penalizes development because now I have to spend more time trying to manage “fake” costs that would otherwise be optimized away before going live if I stay on this platform.
I recommend offering a plan that has unlimited calls for a non-live app so we can focus on development. Optimizing non-production code just to keep API usage down seems like a colossal waste of time.
Thank you for the feedback, David.
How would you handle cheaters wanting to take advantage of the free plan and unlimited calls and push it to production?
I think (almost) all apps that truly go live have more than a handful of clients accessing the db. For a sole developer like myself I can only hit the API from so many devices at a time. I have maybe 5 devices max in utilization at any given time. Even if you restricted the number of registered clients to 50 i can’t imagine any real app trying to go live with that kind of a restriction. I am writing an app that I hope has thousands of users as I’m sure every developer dreams.
I my first thought is to have a “live” app defined as more than 25 registered clients…
Yes, everyone dreams of their apps getting thousands of users. However, unfortunately, the sad statistic is that most software projects (and startups in general) fail. As a result, the approach you described would mean that we eat the cost of trying to help developers get their ideas off the ground to see only a fraction of them succeed. Those costs are actually staggering; the bills are not only to pay for the hardware resources, but we have a team that provides free support, and we constantly innovate. Perhaps bigger companies or those who like burning through VC investments can afford it (at least temporarily).
We believe that the approach of offering development for free is not right. The app development cost with Backendless on the Scale plan can be reasonable. We provide facilities where you can control the expenses and get a project through the dev phase.
By the way, the limit for the number of tables in the free plan is 20.
Then why offer a “free” plan at all? I don’t mind paying for something, but this policy forces me to turn a development cycle on its head by putting API call optimization ahead of feature development. In a test environment I could dev a feature and look at the analytics prior to going live. If it’s too hungry then I would scrap it or optimize it. With this approach I have to worry about how many accidental API calls I make while compiling and launching an app on my test clients (every compile and launch hits the server). And like you, I also don’t have VC backing which means $200 per month is a lot to me…but worse is that it is VARIABLE for pre-production. I would gladly pay a flat rate for testing environment, and a variable rate for live. Test usage (and environments) are VERY different than Live so treating them the same is hard to understand.
I don’t think you should eat the cost of my ideas, but part of the “free plan” model for you was that my miniscule use as a developer would turn into higher paying apps with lost of users. It sounds like that model doesn’t work which is unfortunate. Have you considered charging for a support plan? There is no such thing as free support because your time is paid from something.
Bottom line for me is that I can’t sweat pre-production code because of variable high cost API calls. If there isn’t a better plan option I will have to throw a years worth of work on this platform away and move to something less punitive.
If your development traffic results in a $200/month bill, many things have gone very wrong in the logic/algorithms and/or the overall approach. We see numerous apps on the Scale plan in production, with thousands of concurrent users paying way less than $200/month.
One of the most interesting observations we made when analyzing how developers consumed Backendless services while on the Springboard plan was that optimizing their apps was the least of their worries and concerns. Of course, the business model never forced them to do that, but it is very wrong to think that if the backend doesn’t charge you extra for additional API calls, one should not optimize their logic.
When your app is on the Scale plan, and you are in development (or even in prod), you can set a threshold to prevent any likelihood of exceeding the limit you are comfortable with. It is available in Backenldess Console on the Billing page. This removes any possibility that the bill will be more than what you’re willing to spend:
Yes the KEY word is “production”. I’m talking about pre-production usage when I’m focused on learning the API and testing features. No way would I look at the current usage and think I could support a number of users with that many API calls.
And I think your observations are correct…PRIOR to scaling I would optimize the code. Sometimes that requires refactoring chucks of code etc., but it comes second. While in pre-production (like the Springboard plan) I wasn’t thinking about scaling to any number of users because I don’t have any users. I am just trying to create a test product.
The limit threshold is a good stop-gap solution for surprise billing, but the frustration remains. You have a very powerful product that is going to be diminished by not having a plan that allows me to focus on developing products. Counting API calls at this point in the development process is counter productive, and I hope there is some future consideration for a flat rate pre-production plan.