d_v_c

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

С 20 000 маркеров могут быть варианты.
Когда маркеров будет хотя бы 200 000 - без вариантов решение с bounds_changed + дополнительная логика на сервере когда маркеров в выдачу явно попадает слишком много (зум на страну условно)

1. Imho времена когда деньги давали под идею - давно прошли.
Деньги дают под работающий MVP с понятной монетизацией и четкой динамикой роста.
Деньги дают под экспертизу человека который разработал проверенную гипотезу.
Сейчас Ваша методология - не проверенная. Выстрелит или нет - не известно никому. Рыночная её ценность на данный момент - плюс минус те 2 месяца что Вы на неё потратили.

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

3. Из конкретных нововведений о которых Вы пишите:
а) патент на визуальное решение в российском праве вряд ли получится сделать, а в американском/европейском затянется на несколько лет минимум, с соответствующими расходами
б) ограничения системы прав существующие на нынешних сайтах мне кажется вполне логичным и не понятно в чем тут преимущество. Впрочем это моя субъективная точка зрения.

4. Из предложенных Вами вариантов - либо искать сооснователя, либо сделать презентацию про традиционные ценности™ и пытаться получить что-нибудь в гос.акселераторах.

PS не хочу судить предвзято, но сочетания фраз

профессиональный опыт не связан с разработкой интернет-проектов

и

адекватное, проработанное ТЗ

в соседних предложениях вызывает у меня огромный скептицизм.

Учтите что решение IceJOKER и Михаил Тодерашко будет работать ОЧЕНЬ медленно на даже на сравнительно небольшой базе.
Такая сортировка не использует индексы.
При каждом запросе, для каждой строки будет вычисляться значение функции TRIM, а потом еще и сортироваться.

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

Есть 2 точки зрения.
Классический REST говорит что надо отдавать ошибки в http кодах сервера.
На практике занимались разработкой api под мобильные приложения несколько лет и столкнулись с тем, что многие библиотеки используемые для работы с апи на мобильных приложениях:
а) хреново работают с любым заголовком отличным от 200
b) хреново работают с любыми методами отличными от GET/POST

В итоге пришли к следующему решению (кусок из внутренней документации):

где code 400 говорит о том что серверу не нравятся какие то данные в запросе, error_code говорит о том что именно не нравится (почта, пароль итд - список свой в каждом методе api)

Ну как бы все написано же.
SQL Вам говорит "в таблице msg нет колонки с названием categories"
А почему нет? А потому что в коде CREATE TABLE Вы её назвали category

PS А вообще это выглядит как не очень хороший код.
Мне кажется a) не стоит использовать sqlite б) не стоит в коде модели заниматься созданием таблиц.

DevMan

Профукал телефон/номер/вырубился роуминг (или его вообще нет) - давай досвидания.

Как показывает практика - это вообще не проблема.
Номер телефона восстановить гораздо проще чем украденную почту.

Я вижу несколько других проблем:
1) Затраты на отправку смс. Авторизация это достаточно частое событие в общем случае, смс надо будет слать много.
2) Пользователи с опаской относятся к идее ввода на сайты чего либо пришедшего по смс, все эти истории с подписками чему то научили все таки.
3) Долгий процесс авторизации. Пока смс придет, пока юзер перепишет код. Если такие условия будут на каком то обычном сайте - я как пользователь плюнул бы и ушел.

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

авторизован, ip занесен в базу, зашел с того же автоматом авторизован, нет отправляем новый код

Лучше ставить куку и проверять её наличие, дополнительно сверяя IP если кука есть.
UPD
Kostik_1993 , DevMan : подтверждение любых критический действий через смс с одноразовым кодом - давным давно стандарт в банковской индустрии и понемногу проникает в остальные. Двухфакторная авторизация (по желанию пользователя в не критичных случаях и принудительно - в критичных), восстановление пароля - отличные кейсы для смс.

По сути у нас сейчас нет способа иначе проверить пользователя.
Или приложение на ios с биометрией, или одноразовые смс.
При выборе нормального оператора связи - номер телефона это единственный способ связи с пользователем который пользователь не может неосознанно потерять на долгое время.

Халявы не бывает ©
Оператор в любом случае хочет за отправку смс денег.
Любые сервисы предоставляющий сколько то смс бесплатно - делают это за свой счет в целях рекламы.
Бесплатной отправки смс всем подряд не бывает.

Основная претензия к PHP - огромное количество школьников которые прочитали полторы статьи, посмотрели 3 видео курса, собрали бложег на вордпресс и считают себя программистами.
Есть некоторые шероховатости и нелогичности, но с каждым релизом их меньше и меньше.
Я не вижу каких то принципиальных преимуществ у других скриптовых языков.

Все imho
1) POST /missiles/[id]/launch мне кажется вполне нормальным
2) POST /missile/[id]/country/[id] мне кажется вполне нормальным
3) POST /country/[id]/destroy ;)
4) POST /parade/start

Потратил когда то 2 года жизни на разработку и запуск аналогичного проекта (система коллективной лояльности в виде мобильного приложения + интеграция с системами в заведениях)
Писать честно говоря лень, но если наберете меня в скайп dentelis - расскажу голосом с чем Вам предстоит столкнуться и с технической стороны, и с юзабилити, и с точки зрения продаж всего этого.

1) Без острой нужды я бы не стал класть в базу json. Особенно в mysql/sqlite. Это вот прямо источник кучи геммороя и проблем с произвордительностью когда выяснится что объект все таки можно для экономии ресурсов читать/писать не целиком.
2) Если у Вас стоят ограничения в стиле "доступно только это" - значит у Вас явно нет каких то ощутимых нагрузок, так что делайте как угодно, начнутся живые проблемы - перепишите на postgresql/redis/... в зависимости от ситуации