Три оффера: агентство, фрилансер и софтверная компания — что такое software house и когда это выгодно?

Перед тем как решать, взвесьте три момента: 1) Риск финансовых ошибок: если скрипт криво посчитает раскрой или цену, кто возместит убытки? 2) Планы на вырост: не станет ли этот портал через пару лет основным софтом для всего вашего производства? 3) Независимость: если вы разойдетесь с командой, останется ли у вас на руках документация, в которой разберется любой сторонний спец? Если эти пункты для вас критичны, то только software house.

Два года назад мы заплатили 4.000 EUR фрилансеру за похожий расчётный инструмент. Система работала, но парень, который её разрабатывал, перешёл на полную ставку в корпоративную фирму и забросил проект. Документации не было, поэтому даже простое обновление налогов в коде никто не смог сделать. В итоге нам пришлось отдать 11.000 EUR и заказать всё с нуля софтверной компании; первоначальный бюджет ушёл полностью в никуда.

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

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

Сколько ежемесячно за SLA-обслуживание просит софтверная компания, которая даёт предложение, за поддержку и сопровождение после запуска? Обычно такие компании после сдачи предлагают договор на ежемесячное обслуживание; когда планировали бюджет, вы добавили к стоимости первоначальной установки эти возможные операционные расходы?

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

когда мы договариваемся с софтверной компанией, права на написанный код принадлежат напрямую нам? если в будущем мы прекратим с ними работать, сможем ли мы передать проект другой компании и продолжить разработку?

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

Полностью согласен. Главное не цифра, а то, на основе чего она получена.

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

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

Не упустите: Ошибка, сделанная на стороне софтверная компания, обычно исправима, но дорого.

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

Ответ выше точно передал суть вопроса. То, что делают все, не значит, что это правильно.

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

Согласен.

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

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

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

Каждое «посмотрим позже» на встрече означает неоплаченную работу. Конечно, если ваша ситуация отличается, всё меняется.

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

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

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

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

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