Excellent work on the spreadsheet, very useful (maybe Adalo should check it out and see if their math still makes sense).
I reviewed Firebase plans again, and was mistaken. You get collectively 90k read/write/delete actions per day, not per month, for free. If you top that allotment, it charges the following per each additional block of 100k actions:
Read: $0.06/block
Write: $0.18/block
Delete: $0.02/block
So, essentially, where Adalo is charging business users $10/200k extra actions, Firebase will give you 300k actions collectively of the above for $0.26. Plus a GiB free storage in the firestore with each additional GiB coming in at $0.18/month.
I ran my firestore numbers (granted there are other functions in Firebase that charge, but still pennies on the dollar) as I wanted to get a base estimate of monthly collective actions (read, write, delete), and I went on the liberal side with my estimates for the first six months following public release.
My total per month would be approximately $21.71, bringing my six month total to $130.26.
And unless my math is wrong, to get the same number of actions in Adalo after deducting the 1mil with the business plan, at 200k/$10, the six month total from Adalo would be $6900. That doesn’t include the $250/month just to use their service (and my Firebase calculation doesn’t include the monthly fee to use the other service).
And these are just straight fee calculations. This doesn’t take into account that Adalo is counting much more as an action than Firebase does, which would suggest that one would either use far more actions in Adalo per month versus Firebase with the same estimated active users per day, or someone using Adalo would have to reduce their daily user count and/or limit daily action use per user.
Just for kicks, I added my estimated monthly egress, and plugged in some Google Vision extras, and my file storage amount. This brought my grand monthly total to just under $25. Including my developer account, that’s $95/month.
Adalo would be more than ten times that amount just for their monthly use fee plus actions, that doesn’t take into account the need to pay extra to get premium components needed to adequately design an Adalo app (where there exists a robust free library of components for Flutter) plus all of the external calls, automated workflows, and external database infrastructure to counter balance the lack of performance from Adalo.
Honestly, you may as well hire a developer if you’re going to pay Adalo prices.
I’m guessing Adalo is banking on people not figuring out there are MUCH cheaper and more robust services out there, or they are hoping to attract people who don’t want to take the time to learn Flutter and Firebase/Firestore. With the advent of low code editors for Flutter, and an intuitive UI for Firebase, plus if you’ve spent ANY time at all in command line, working with flutter systems and Firebase is a breeze.
I get that Adalo’s interface definitely provides an easier to build and deploy setup, with an open canvas (not having to work in rows and columns, for example), and their relational database structure is a no brainer for most, the limited time I’ve spent away from Adalo has made me realize how rudimentary Adalo’s system truly is.
Now, if you consider Firestore’s document reference fields as a similar concept to Adalo’s many to many or many to one, etc, relationships, grasping the use of reference fields is really very straight forward.
Besides all of that, when I came into Adalo, I was pursuing an app that would initially deploy as a PWA concept for a limited run of approx 400 users to test. But a core functionality of the app required a barcode (not QR) scanner deployable in PWA with the ability to query separate strings of data from the barcode and plug those strings into their respective places. Aside from the fact that there is no barcode scanner available for PWA in Adalo (which means I would have had to pay someone to make it for me or learn to build components myself), when experimenting with the QR scanner that does exist - though the camera faces the wrong direction 
, I only ever saw a way to pull one long string of data and plug it into a single field.
The week I’ve spent with Flutter, I’ve already deployed a test barcode scanner function plus a dynamically-generated barcode displaying separate pieces of information, each being stored in different fields - best part, I didn’t have to pay extra for it, and deployment took less than a day.
I’ll close up with this last bit - the service I’m using also allows for downloading your app as a web package to host wherever you want (Firebase offers a solution though, convenient), and setting your elements to display correctly for larger screens is a simple wrap. No need to buy an extra component or wait for Adalo to fix that aspect where it works. (Currently, web app capability for Mac is in beta and a Windows version will be opening up soon).
At this point, I’m just using the free version of Adalo to quickly conceptualize design and layout, as low to no backend demos to potential clients - once sold, I build out the real version elsewhere.
So, really, I should be thanking Adalo. If they hadn’t screwed their customers in a most climatic way, I wouldn’t have discovered a much better option both for feature capability and scalability.
