Не штопано, не рвано⁠⁠2

Я не знал. А теперь вот сижу страдаю, не могу никак выбрать - Вьетнам или как всегда Тай?

В большинстве случаев

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

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

Те же запросы в базу данных. Можно сделать быстро и будет лагать (связи на ORM, неоптимальные запросы), можно сделать средне по времени и невозможно будет нормально сменить СУБД, а также будут дыры в безопасности (сырые запросы) или сделать чуть дольше чем средне, но кросплатформенно и без лагов (построение запросов кодом, Query Builder).

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

У меня есть один сайтик, который подавал заявки по претензиям от клиентов. Изначально сделан часов за 50, юзает пачку внешних сервисов чужих вместо БД напрямую. В первые 2 года он сильно разросся по коду и логике, делал его джун с нуля и сам. На 6й год в нём уже несколько вещей было переписано по несколько раз (например, работа по HTTP со внешними сервисами, обработка бизнесовых исключений и общих ошибок, логирование и мониторинг приложения и так далее). Сейчас осталось переводить архитектуру в нормальное ООП, ибо банально сложно поддерживать. Также пора обновить фреймворк и версию языка. Устарело уже года на полтора. В некоторых местах жуткие полотна кода с парой десятков зависимостей. Но это точечные задачи по 10-30ч. + Меняются внешние зависимости, нужно переключаться, мигрировать время от времени...

И вот так скажи, сайт на 5 страниц, принятие претензий от клиентов. А там каждые полгода вбухивается 400ч+ (и то потому что у 1 одного разработчика его ведущего ещё 3-4 проекта стабильно). И это на 85% бизнесовые фичи всё, не рефакторинг.

Очень сильно зависит от проекта, но на сложных в первую очередь важна архитектура и методология ведения и нужен толковый Tech Lead.

     Я бы не стал при коммерческой разработке соединять в одном предложении слова “простое” и “мобильное приложение”.

Мобильное приложение – это рабочий инструмент бизнеса. Бизнесу хочется быть в кармане пользователя. Как в прямом так и в переносном смысле.

    Количество мобильных веб пользователей превышает количество пк веб пользователей.

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

    Имея свое приложение можно увереннее закрепиться за пользователем.

     Современный пользователь – создание искушённое, и если приложение ему с первого раза не понравится, то он легко и быстро его удалит и взглянет на альтернативу от конкурентов, услужливо предлагаемую мобильным маркетом.

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

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

      Просто и быстро писать можно и нужно MVP (minimum viable product, не путать с одноименной архитектурой). Для демонстрации рабочего прототипа заказчику /инвестору дабы выбить денег на нормальную разработку. В ходе которой лучше переписать всё с нуля, продумывая дальнейшее сопровождение.