Hello ramez, your case is surely also valid but should not be stated as exclusive.
Sure you have all right and I encourage to disagree, with the purpose of placing different opinions, which is key to best frame the strategical target. (To relate my input; my experience and practice in large companies prime activity IT in past 40 years (yes, old guy, started coding at ETHZ on punchcards, despite mostly management&architecture never lost grip on cool tech stacks, reason of my strong sympathies/support to meteor.
Also since I have experienced a large period in IT history and how, which items evolve or do not evolve). I clearly believe there is the same risk (as I had mentioned few years ago in a post at a similar junction/crossroad of meteor) that exclusive hosting, cloud-service will not allow to fully scale.
It was/is one of the strategy key criterion’s in my job. Particularly in the fast changing times to ‘prevent lock-in’. In the past there was the saying ‘you never get fired for choosing IBM’, very many companies were locked in to IBM (still today with heavy legacy stacks - and massive code volume).
I see continued high potential in Meteor and would consider three strategical vectors to not miss:
Become the top (fully dominant) stack for prototype, stage 1,2, alpha/beta design and development
The stack which does dominate the starting stage can further influence the full scaling (hosting of applications, micro-macro services etc., supported via well defined/conditioned free hosting as outlined in various posts here already)
Provide full scale production service - Tiny hosting/cloud
Provide flexibility to change 2 to another provider (docker etc.)
The very clear strength of meteor is on 1(-2), other companies will continue to dominate the high-end hosting/cloud service AND IT’S TECH EVOLUTION (here Meteor should best adapt, stay relevant). Tiny may gain major portion of the revenue via services (experts to optimize and help
move from 1 to 2/3 (and between them), subscribe community skills/contracts
Also perform some UCase friction analysis should be done ‘full’ stacks such as .net
(learn from and minimize direct clash but clear alternative - DIFF/GAP table etc. used for marketing)