Firebase looks really cool, but my first impression the moment I see that you end up building everything in a way where it is tightly coupled to the servers of a startup that does not have years of profitability yet (or even published pricing), is that there's no way I'd put anything but toy/demo's on it for a long time.
It seems like the type of thing that'd do great with the option of a self-hosted server, and it also seems like the type of thing that'll see open source clones of pretty quickly, though. But I'd actually be vastly more comfortable paying Firebase to host my apps if I knew there was an open source fallback for their server component.
[Firebase founder] Thanks for the feedback! We're definitely aware that it's a concern. Hopefully we can go a little way towards winning your trust by showing you the great apps built on us by larger companies (happening soon) and by giving you the best customer service we possibly can. And, hey, toys are a good starting place too.
Pricing doesn't look like an issue. The hosting thing, for me, would remain an issue no matter how many large companies you sign up - A large enough company could presumably negotiate special concessions. And if not: Large companies make risky decisions too, and can often better afford to engineer their way out of a problem (such as your company failing) better than smaller companies.
If I were to consider using this for something important, my first order of business would be to establish how I could ensure I could remove my dependency on you in the case of problems. The more perceived effort that would require, the less chance I'd go ahead.
Nothing specific to you here - that's how I'd approach building a service around running on e.g. AWS too, or making use of any proprietary API.
You should have graduated concurrent user limits there. Rather than 1000 across the board, start with 100 for the "Candle" plan (the name "Spark" would be a great fit too), 1000 for "Bonfire", and 5000 for "Inferno".
Also, what happens if you exceed the 1000 concurrent user limit? For example, your site is momentarily popular and gets 1500 people trying it out for a few hours then goes back down under 1000. Is there burst pricing? Do connections get dropped? Is there a grace period, like the way 95th percentile bandwidth billing works?
I almost never use Facebook to log into anything, and vastly prefer using twitter as my catch-all account. You absolutely must put in a real account system as an alternative to Facebook if this is going to take off.
We currently provide convenience SDKs to login with Facebook, Twitter and just a regular email/password, but the system is flexible enough to allow any authentication mechanism that can produce JWTs.
It seems like the type of thing that'd do great with the option of a self-hosted server, and it also seems like the type of thing that'll see open source clones of pretty quickly, though. But I'd actually be vastly more comfortable paying Firebase to host my apps if I knew there was an open source fallback for their server component.