Агентство предлагает писать под iOS и Android на разных языках — как выбор стека влияет на бюджет?

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

Мы в своей оптовой сети три года назад наступили на те же грабли и заказали натив. Отдали 240.000 TL. В итоге при каждом крупном обновлении Android или изменениях правил в App Store платили за доработки обоим программистам. В прошлом году переписали все на один код, чек за поддержку упал с 18.000 TL до 8.500 TL в месяц.

В агентстве просто сидят без работы отдельные разработчики под iOS и Android, вот их часы и пытаются закрыть за ваш счет. Сейчас 90% корпоративного B2B-софта пишется на кроссплатформе с одной кодовой базой.

Что нужно уточнить у них до подписания договора: 1) Какой именно экран в нативе откроется быстрее, чем на кроссплатформе? 2) Что входит в годовую поддержку двух раздельных баз? 3) Кому перейдут полные исходники обеих версий после сдачи проекта?

Не спешите отдавать 340.000 TL, закиньте то же самое ТЗ еще паре студий, которые пилят на кроссплатформе. Ценник сразу опустится где-то до 190.000 TL, а срок сократится недель до шести.

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

Заказывать нативный код на двух языках для B2B-приложения которое показывает каталог и сканирует штрихкоды — это прямая выброска денег на ветер.

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

Оставлю как заметку пригодится.

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

Давайте немного раскрою техническую сторону. Самое дешевое предложение обычно самое непродуманное.

Я бы пошел этим путем.

мои сомнения развеялись спасибо. короче прежде чем принимать решение посмотрите какие данные у вас есть.

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

Внедрение процесса управления изменениями не замедляет работу, а ускоряет её. Удачи.

У нас было так. Большая часть потерь времени копится на задачах, ожидающих согласования.

Если напишете результат здесь, это поможет и другим.

я сталкивался с тем же.

Полностью согласен. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

Процесс, по которому не ведется учет, не улучшается потому что вы не знаете, что именно улучшать. На этом всё, извините если затянул.

У меня будет вопрос, не хочу уходить от темы но... Если скоуп растет, должен расти либо срок, либо бюджет. Третьего не дано.

Надеюсь, это будет полезно.

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

Начните с небольшого эксперимента, не привязывайте всё сразу.

Спасибо за ваш пост.