azShoo

Это реально.
С чего начать? Определиться с тем:
1) Как вы будете забирать данные и где хранить.
2) Как вы будете доставлять данные на клиент.
3) Какая логика должна быть на клиенте.
4) Как вы собираетесь это монетизировать (если собираетесь) и как продвигать.
По каждому из этих пунктов расписать Job to be done и начать делать.
Рокетсаенса никакого. Возможно ли достичь рентабельности зависит от ответов на п.4

Нужны. Работодатель вполне в состоянии обеспечивать необходимыми девайсами команду (это не так дорого, как кажется)
Есть проблемы с удаленщиками, тут спасает только SauceLab и аналоги, но они хреново работают, не всегда пригодны к использованию и не всегда повторяют поведение живых девайсов.

С правовой точки зрения: нет, нельзя, если иного не указано в лицензии на использование товарных знаков и интеллектуальной собственности.
С фактической точки зрения: так делают, но на свой страх и риск.

А ещё есть отдельный геморрой с тем, что например при загрузке в АппСтор\ГуглПлей с вас, с высокой долей вероятности, спросят про права на трейдмарки и прочее.
Но это если говорить о мобильных приложениях.

Первый вариант выглядит наиболее правильным, если вопрос именно в хранении.
С точки зрения масштабируемости - амазон стоит относительно дорого, но масштабируется идеально.

На iOS меньше конкуренции и больше $, но вместе с этим следует и больше ограничений и проблем.
В целом, доходы от рекламы что там, что сям сильно разнятся в зависимости от.
Средняя цена за клик колеблется около 1$, но сильно зависит от региона пользователя, девайсов и прочих историй.
Чем дороже будет аудитория, тем, собственно, выше цена.

Первое. Для хранение координат, и их истории (т.е. банальная связка device_id:coords) смысла использовать RDBMS - ноль.
Только нереляционные базы данных. Монга, упомянутая, отлично подходит.
Я бы сделал отдельную таблицу\коллекциюс актуальным(последним) положением девайса и отдельную таблицу\коллекциюс историей координат по девайсам.
Таким образом для отображения текущего положения пользователя и\или проверки на то, изменил он своё положение или нет - смотрим последнее актуальное состояние по ключу, а для построения маршрутов и прочих историй требующих более одной точки - лезем в коллекцию с выборкой по оному.
Коллекция актуальных состояний всегда будет равна количеству трекаемых девайсов, а историю можно шардировать, партиционировать как душе угодно в зависимости от объемов данных.

Второе.
Как делать.
Ну, очередь на отправку на клиенте, ожидающая удачного коннекта и "запоминающая" последнее сочетание координаты + таймстэмп на последний синк с сервером.
Очередь на приём с последующей обработкой и перезаписью в базу на стороне сервера.
Ну, и система гарантированной доставки в режиме пинг-понг через сокеты.

На правильность не претендую, но я на мой взгляд это разумное соотношение сложность\качество.

Выберите тот, который выгоднее.
Если умеете генерировать идеи и алгоритмы решения задач - оценить рынок, составить бизнес-план и вывести риски для каждого из проектов у вас проблем не должно вызвать.

Между этими сферами много "пересекающихся" областей, но и очень много вещей специфических для одной из.
По личному опыту: знаю разработчиков одинаково подкованных и в веб(бэкенд) и мобильной разработке. Но, я бы сказал, что если бы эти люди сконцентрировались на одной сфере, а не на двух - стали бы гуру. А сейчас же - среднестатетический хороший разработчик.

Объединить это в одном стеке технологий и решений - не получится.
Одинаково ориентироваться в двух стеках - вполне возможный вариант. Все упирается в опыт и количество потраченного времени.
Опять же, есть люди, которые быстро учатся. Для них стек технологий и набор библиотек - не более чем инструмент, и они очень просто переключаются с одного на другой. Сел, разобрался за месяц-другой и все хорошо.
Есть люди, которые переключение между спецификой даже в рамках одной платформы (или даже стека) дается тяжело. Для них это "обучение программированию с 0", а не "почитал, понял особенности, погуглил нужные библиотеки, понял как это работает".

Вопрос ещё в том, что в определенный момент вам может быть _выгоднее_ (с точки зрения интереса, времени, денег или ресурсов) сконцентрироваться на одной из сфер (приложениях), а веб отдать партнеру\коллеге\фрилансеру\работнику.
Просто потому, что пользы будет больше.