Заказали кастомный софт: реальные примеры и риски для небольших компаний вроде нашей

Мы в Дюссельдорфе занимаемся оптом упаковки, штат 15 человек. Два года назад отдали 42.000 EUR за подобную интеграцию. До этого трое сотрудников по два часа в день вручную сводили накладные и упаковочные листы. После запуска освободилось около 30 рабочих часов в неделю, а ошибки в комплектации почти исчезли. У нас система окупилась за 14 месяцев.

Студиям всегда выгоднее пилить код с нуля чем настраивать готовое. Основная засада не в том что софт не допишут, а в том, что после сдачи они забьют на поддержку или задерут рейт до 150 EUR в час. Вы точно выжали максимум из API и вебхуков текущего софта? Прежде чем лезть в самописный код, убедитесь, что современные SaaS-сервисы реально нельзя связать между собой.

Не вываливайте сразу все 38.000 EUR. Разбейте проект на модули. Для начала сделайте простой мобильный интерфейс для монтажников, чтобы они списывали детали с привязкой к вашей базе. Сделайте этот этап где-то за 10.000 EUR и протестируйте в полях. Если приживется и сбоев не будет, тогда уже докручивайте интеграцию с поставщиками.

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

А в каком виде отдают данные поставщики? Если там старые форматы типа EDI или CSV, под них есть масса готовых облачных конвертеров. Точно ли нужен самописный софт, а не простой слой парсинга данных? Обсуждали этот момент с разработчиками?

Юридическая часть тут важнее технической. Обязательно требуйте от агентства: 1) Все исходники и git-репозиторий должны храниться на вашем сервере с каждого релиза. 2) Стек только из популярных открытых языков и фреймворков, никаких их собственных закрытых библиотек. 3) Гарантия бесплатного фикса багов минимум на три месяца. Если отказываются, дальше даже говорить не о чем.

Лет пять назад мы из соображений «хотим свое уникальное» наняли компанию для логистики. Ведущий разраб у них уволился, и проект встал на три месяца. Новый парень не смог разобраться в чужом коде и предложил все переписать. Со второй попытки мы сделали предельно простой сервис чисто под оптимизацию маршрутов, и он пашет до сих пор. Чем уже рамки задачи, тем выше шансы на успех.

Верно.

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

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

Я долго занимался этим вопросом. Первые три месяца все идет хорошо, проблемы всплывают на четвертом.

Если в договоре не прописано право собственности на код, при уходе у вас нет переговорной позиции. Оставлю как заметку, пригодится.

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

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

Ответ сильно зависит от отрасли, универсального правила нет. На этом всё, извините, если затянул.

Слежу за темой.

Сохранил.

Об этом много говорят, но у нас так никогда не было. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

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

Я проходил через это расскажу. ну чем сложнее отменить решение, тем медленнее его принимайте.

Спешка в решениях оборачивается исправлениями через полгода. Я бы пошел этим путем.

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

Если делаете впервые, начните с малого, масштабирование потом. Конечно, если ваша ситуация отличается, всё меняется.

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

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