Сколько на самом деле стоит приложение на заказ: честная, прозрачная разбивка

Спросите три агентства, сколько стоит приложение на заказ, и вы получите три цифры, у которых нет ни одного общего разряда. Одно скажет четыре тысячи, другое — сорок, а третье тихо ответит «зависит» и назначит вторую встречу. Никто из них не врёт, строго говоря, — но никто и не говорит вам того, что вам действительно нужно знать: куда уходят деньги и почему именно ваше приложение оказывается там, где оно оказывается. Так что давайте откроем капот.

Я составил больше оценок для приложений, чем могу сосчитать, — для компаний от мастера-одиночки до региональной сети. Самая частая реакция на цену — не шок от итоговой суммы, а недоумение по поводу разброса. Как одно и то же задание из трёх слов («приложение для записи») может давать оценки, отличающиеся в десять раз? Честный ответ: «приложение для записи» — это не задание. Это пожелание. Цена живёт в сотне мелких решений, спрятанных под ним.

Этот материал — та самая разбивка, которую я хотел бы видеть у каждого владельца бизнеса перед первым разговором с разработчиком. Без воды, без запугивания, без впаривания. Только реальные составляющие стоимости, вещи, которые незаметно удваивают бюджет, и несколько честных способов потратить меньше, не получив в итоге то, о чём пожалеете.

Почему две оценки «одного и того же приложения» отличаются в 10 раз

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

Объём — это очевидное. «Приложение для записи» может означать один экран, где клиенты выбирают слот, — а может означать графики сотрудников, оплату, напоминания, личный кабинет клиента, панель администратора, возвраты и отчёт, который владелец читает в понедельник. Те же три слова — в десять раз больше работы. Дешёвая оценка часто подразумевает маленькую версию; дорогая тихо закладывает большую. Ни та, ни другая не спросила, что именно вы имели в виду.

Есть ещё риск — то, что никто не любит оценивать. Расплывчатое задание, клиент, который не решил, чего хочет, интеграция с дряхлой устаревшей системой — это не просто добавляет часов, это добавляет неопределённости. Опытные команды закладывают запас на неопределённость, потому что уже обжигались на ней. Более дешёвая оценка часто вообще не учитывает риск — и именно поэтому она иногда раздувается на полпути.

Куда на самом деле уходят деньги

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

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

Исследование и дизайн: этап, который все хотят пропустить

Исследование — это когда вы превращаете «приложение для записи» в точный список экранов и правил. Кажется, что это накладные расходы, ведь пока ничего не строится. Но каждый час здесь экономит несколько часов дальше, потому что именно тут устраняется двусмысленность, пока она ещё дёшева. Команда, которая называет вам цену без этапа исследования, либо угадывает, либо планирует выставить вам счёт за исследование позже под другим названием.

Основная разработка: видимый двигатель

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

Интеграции: обманчиво дорогая часть

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

Расходы, которые никто не вписывает в оценку

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

Ничто из этого не обман и не скрытая ловушка — это просто та часть, которая не помещается аккуратно на одностраничную оценку, поэтому более слабые партнёры опускают её, чтобы выглядеть дешевле. Хороший рассказывает об этом сразу, даже если из-за этого его первая цифра выглядит больше. Спрашивайте прямо: во что мне обойдётся год эксплуатации после запуска? Качество ответа многое говорит о том, с кем вы имеете дело.

Что незаметно удваивает цену

Некоторые вещи добавляют стоимость пропорционально ценности, которую приносят, — и это честно. Другие добавляют стоимость совершенно непропорционально, обычно из-за того, как организована работа, а не из-за того, что делает приложение. Это рычаги, которые стоит понимать, потому что несколько из них целиком в ваших руках.

• Две платформы вместо одной. Нативное приложение для iPhone и нативное для Android — это, грубо говоря, две сборки. Кроссплатформенные инструменты или веб-приложение могут свести это обратно к одной. Один этот выбор способен сдвинуть итог сильнее любой функции.
• Индивидуальный дизайн вместо разумных стандартов. Выверенный до пикселя, полностью индивидуальный интерфейс стоит реальных денег в проектировании и сборке. Чистый, привычный, использующий проверенные паттерны — быстрее, дешевле и часто удобнее для клиентов.
• Передумать после начала сборки. Решения дёшевы на доске и дороги в коде. Самое частое превышение бюджета — не плохая оценка, а объём, который всё рос, потому что ничего не было зафиксировано.
• Реальное время, офлайн или тяжёлые данные. «Должно работать без связи» или «обновления должны появляться у всех мгновенно» — разумные просьбы, которые незаметно умножают инженерную работу под капотом.
• Интеграция с чем-то старым и недокументированным. Подключение к современной, хорошо построенной системе — рутина. Подключение к пятнадцатилетнему внутреннему инструменту без документации — это археология, и оплачивается она по часам.

Реальный пример: оценка в 60 000 €, ставшая приложением за 14 000 €

Несколько деталей изменены ради конфиденциальности, но суть этой истории правдива и абсолютно типична. Региональная сервисная компания — представьте десяток выездных сотрудников и загруженный офис — пришла к нам в растерянности. Они хотели приложение на заказ, чтобы их клиенты могли оформлять заявки, отслеживать ход работ и оплачивать. У них уже была оценка в другом месте около 60 000 € плюс солидная ежемесячная плата, и это отпугнуло их от всей идеи почти на год.

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

Что мы сделали на самом деле

Первые сессии мы посвятили исключительно исследованию — раскладывая пожелание на «без этого бизнес встаёт» против «это было бы неплохо когда-нибудь». Обязательное оказалось уже, чем кто-либо ожидал: удобный способ для клиента оставить заявку и отследить её, автоматические напоминания и онлайн-оплата. Диспетчеризация в реальном времени и индивидуальный бэк-офис оказались решениями проблем, которые их существующее ПО уже прекрасно закрывало.

1. 1
   Сократили объём до реальной задачи

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

   Вместо двух отдельных нативных приложений одно кроссплатформенное покрыло и iPhone, и Android — это примерно вдвое сократило основную разработку.
3. 3
   Использовали проверенные паттерны дизайна

   Чистый, привычный интерфейс вместо индивидуального. Клиентам было удобнее им пользоваться, а сроки сократились на недели.
4. 4
   Подключили, а не заменяли

   Мы связали приложение с офисным ПО, за которое они уже платили, вместо того чтобы переписывать его. Дорогая «индивидуальная админ-платформа» просто исчезла из объёма.

Результатом стала сборка примерно на 14 000 €, запущенная за несколько месяцев, с предсказуемыми текущими расходами. Она не такая разветвлённая, как версия за 60 000 €, — и не должна быть. Она делает ту работу, которая бизнесу действительно была нужна. Через год они добавили поверх две небольшие функции, оплаченные из денег, которые сэкономила им первая версия. В этом весь принцип: начни с реальной задачи, заработай дополнения результатами.

Как удержать стоимость в разумных рамках без ущерба для качества

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

Во-первых, соберите самую маленькую версию, которая реально полезна, а затем наращивайте её. Сфокусированный первый релиз, который хорошо делает одно дело, быстрее выводит вас в прод, стоит долю от мечты «всё в одном» и — что важно — учит вас, что строить дальше, на реальных клиентах, а не на догадках. Во-вторых, примите решения до начала сборки; нерешительность — самое дорогое, что вы можете принести в проект. В-третьих, подключайтесь к тому, что у вас уже есть, вместо замены работающих инструментов, и переписывайте что-либо только тогда, когда оно действительно вас тормозит.

Частые вопросы