Заказное ПО пишут, когда готовые программы заставляют компанию подстраиваться под себя: склад ведут в трёх таблицах, заявки теряются между отделами, дилеры звонят узнать остатки. Такой проект сложнее сайта не столько технически, сколько организационно — главный риск в том, что задачу понимают по-разному. Ниже — как проходит работа, почему честную цену нельзя назвать после одного звонка, какие модели оплаты бывают и что проверить в договоре.
Когда нужна своя разработка, а когда — готовое решение
| Ситуация | Что обычно разумнее |
|---|---|
| Типовой процесс: учёт, бухгалтерия, простая CRM | Готовая система с настройкой |
| Готовая система закрывает 80% задач | Готовая система плюс доработка или интеграция |
| Процесс — ваше конкурентное преимущество | Своя разработка |
| Нужно связать несколько систем, которые не умеют общаться | Интеграционный слой или свой сервис |
| Дилерам и оптовикам нужен доступ к ценам и остаткам | B2B-портал поверх учётной системы |
Своя разработка дороже на старте и требует поддержки, но подстраивается под процесс, а не наоборот. Если сомневаетесь, начните с разбора: иногда выясняется, что хватит настройки готовой системы или автоматизации отдельных шагов. А если главная боль — клиенты, которые звонят узнать статус заказа или запросить документы, часто хватает клиентского портала поверх существующей системы.
Как проходит проект
- Разбор процессов. Как работа идёт сейчас, где теряется время и деньги, кто будет пользоваться системой.
- Техническое задание. Роли, экраны, данные, интеграции и что считается готовым результатом.
- Архитектура. База данных, серверная часть, интеграции, где будут храниться данные.
- Разработка короткими этапами. После каждого — демонстрация работающей части.
- Внедрение. Перенос данных, обучение сотрудников, запуск на реальных процессах.
- Сдача и поддержка. Исходный код, документация, доступы и договор на сопровождение.
Короткие этапы с демонстрацией — главная защита заказчика. Вы видите работающую систему каждые две недели, а не через полгода, и можете поменять приоритеты, пока это дёшево.
Почему цену нельзя назвать сразу
После первого звонка исполнитель знает о проекте слишком мало, и любая цифра будет либо с большим запасом, либо заниженной, чтобы выиграть заказ. Точность оценки растёт по мере того, как проясняется задача.
| Этап | Что известно | Насколько точна оценка |
|---|---|---|
| Первый разговор | Общая идея | Порядок суммы, не больше |
| После разбора процессов | Роли, основные экраны, интеграции | Диапазон, на который можно планировать бюджет |
| После технического задания | Всё, что входит в первую версию | Фиксированная цена на этот объём |
Поэтому разумно платить сначала только за разбор и техническое задание. Этот документ ваш: с ним можно сравнить предложения нескольких команд. Как составить задание, мы разобрали в гайде о техническом задании.
Фиксированная цена или оплата по времени
| Фиксированная цена | Оплата по времени | |
|---|---|---|
| Как считается | Сумма за описанный объём | Часы команды по факту |
| Подходит, когда | Задача понятна и зафиксирована в ТЗ | Требования будут меняться по ходу |
| Риск заказчика | Всё новое — отдельная доплата | Бюджет растёт, если не следить за приоритетами |
| Риск исполнителя | Недооценка съедает прибыль | Меньше, поэтому ставка обычно ниже |
На практике часто совмещают: первая версия — по фиксированной цене, развитие после запуска — по времени с лимитом на месяц.
Что проверить в договоре
- Исключительные права на код переходят к вам, исходники передаются по ходу проекта, а не только в конце.
- Серверы, домены и учётные записи оформлены на вашу компанию.
- Что считается готовым результатом и как проходит приёмка.
- Гарантийный срок на исправление ошибок и условия поддержки после него.
- Где хранятся персональные данные клиентов и сотрудников — это требование закона, а не только вопрос удобства.
Цена разработки ПО у нас считается после разбора процессов — готовых пакетов на такие проекты нет и быть не может. Если хотите начать с оценки, оставьте заявку и коротко опишите процесс, который хотите автоматизировать.