Сам набросал прототип приложения в бесплатном конструкторе — отдать агентству на доработку или пилить с нуля?

Автоматически сгенерированный код из конструкторов — это почти всегда спагетти: куча лишних библиотек и жор оперативы. Когда рестораторы начнут в шесть утра оформлять срочные поставки, а аппка упадет — вы просто потеряете клиентов. Используйте свои макеты как визуальный референс, но разработку заказывайте нормальную.

Выбирая подрядчика, обязательно зафиксируйте три пункта в договоре: 1) исключительные права на исходный код переходят вам сразу, 2) релиз и прохождение модерации в App Store и Google Play входят в стоимость, 3) минимум 3 месяца бесплатной гарантийной поддержки после публикации.

Когда чувак за 12.000 SAR через пару месяцев перестанет брать трубку вы сразу поймете почему агентство просило 40.000 SAR. Скупой в разработке всегда платит дважды а то и трижды.

Заскриньте каждый экран вашего прототипа соберите схему переходов и упакуйте все в один подробный PDF. Отправляйте это агентствам как приложение к ТЗ для оценки. Так у них не останется поводов накручивать ценник за «неучтенные доработки».

Мы в Джидде делали похожую B2B-систему для логистики с нуля. Пришли к разработчикам с готовым кликабельным прототипом — агентство сразу скинуло прайс с 55.000 SAR до 34.000 SAR, потому что стадию аналитики закрыли мы сами. Ваш прототип — отличный аргумент для торга.

По законодательству Министерства торговли Саудовской Аравии право собственности на исходный код должно быть четко прописано в договорах на разработку ПО. Иначе код может быть признан интеллектуальной собственностью агентства. Какой бы вариант вы ни выбрали, обязательно пропишите в договоре, чтобы доступ к репозиторию с кодом открывался на имя вашей компании.

А ресторанам точно нужно мобильное приложение? Разве для уведомлений и счетов на первое время не хватит адаптивной веб-панели? Вы учли комиссии сторов и ежегодные расходы на аккаунт разработчика?

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

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

Не знал об этом.

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

Главное не цифра, а то, на основе чего она получена. Оставлю как заметку, пригодится.

мне тоже интересно.

Сохранил. Решения, работающие в малом масштабе, рушатся при росте, я узнал это слишком поздно.

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

Если критерии приемки не прописаны, момент завершения работы становится предметом спора. Удачи.

Согласен с этим. Код без документации не принадлежит вам, даже если он у вас есть.

Хорошо, что вы создали эту тему.

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

Интересно есть ли те, кто делает иначе.

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

Пишите, если есть вопросы, отвечу по мере возможности.

А как вы решили этот вопрос? Внедрение процесса управления изменениями не замедляет работу, а ускоряет её.

Чем сложнее отменить решение тем медленнее его принимайте. Надеюсь, это будет полезно.