В чём разница между IT-компанией и агентством — кому доверить разработку?

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

Сделайте простой лакмусовый тест: спросите у обоих: «Кто проектирует схему БД и архитектуру API на старте, и сколько у вас штатных backend-инженеров?» Если агентство мнётся или говорит «у нас привлечённые эксперты» — сразу в топку.

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

Три критерия, определяющих разницу: 1) Команда: у агентства это дизайнеры и копирайтеры, у IT-компании — системные инженеры и архитекторы. 2) Жизненный цикл: агентство сдало проект и побежало делать кампанию, IT-компания ведет его по SLA и мониторит баги 24/7. 3) Качество кода: агентство жмет на скорость и визуал, IT-компания — на безопасность и нагрузку.

в логистике дизайн нужен тупо для понятности экрана но никто не ищет понттовые анимации на экране трекинга фур. однозначно идите к разработчикам чтобы потом голова не болела.

Главный грех IT-компаний — это интерфейсы. Запилят вам экран в стиле бухгалтерии 90-х скажут «зато внутри всё железобетонно», и сотрудники потом мучаются. Так что если выбираете разработчиков обязательно смотрите их портфолио по дизайну.

Итог спора: для продаж и имиджа бренда — агентство, для интеграций, БД и бизнес-процессов — IT-компания. Так как у вас критически важный логистический портал, работайте с разработчиками, а интерфейс при необходимости проконтролируйте доп. соглашением.

Очень актуальная тема.

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

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

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

Удачи.

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

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

На этом всё, извините, если затянул.

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

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

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

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

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

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

Нужно идти по порядку. Спросите, кто готовил КП и кто будет выполнять работу.

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

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

конечно если ваша ситуация отличается, всё меняется.