Как получить скидку 68% при разработке приложения в студии?

Денис Гордиенко, генеральный директор Bright Mobile, о том, как сэкономить, заказывая приложение в студии.

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

Общий лейтмотив прошлой статьи заключался в том, что проект можно заказать в студии (у нас это в среднем около 700 тысяч рублей), а можно попытаться сэкономить и заказать такой же объём функционала на фрилансе (в этом случае приложение обойдётся в 300-400 тысяч рублей). Однако в таком случае вы берёте на себя:

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

Клиентам, которые попросят скидки, большинство студий откажут: у них и так достаточно заказов, какой в этом смысл? Но потом я всё-таки задумался, а нельзя ли действительно и скидку предложить, и выгоду сохранить – так, чтобы в плюсе остались и клиент, и заказчик?

В итоге, я нашёл несколько вариантов, при которых на самом деле можно скинуть до 68% от изначальной стоимости. Лично для меня это было чуть ли не шоком. Чуть ниже я распишу, как же это мне так удалось уменьшить стоимость разработки, но сначала о том, как не стоит заводить разговор о скидке.

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

Разработчики будут уверены, что раз вы так себя показали ещё на стадии заказа приложения, то и на протяжении всей работы будете вести себя точно так же. У неадекватных заказчиков – самый низкий приоритет. Их задачи выполняют в последнюю очередь, с ними чаще всего расторгают сделки: смысл расторгать сделку с лояльным заказчиком, если есть договор на менее выгодные условия, с которым расстаться будет куда удобнее?

Разумеется, у всех разные понятия неадекватности. Для меня такой ярлык сводится к двум пунктам:

Итак, давайте перейдём к подходам, которые имеют низкую вероятность на одобрение.

На самом деле всё достаточно очевидно. Самый неправильный вариант – просто просить скидку безо всякой мотивации. Меня, мол, всё устраивает, всё нравится, но давайте сделаем ценник на 10% ниже. Для разработчика, у которого и так есть ряд проектов, это выглядит как предложение недополучить 10% за ту же работу. А если оценивать маржинальность — это порядка 30%. Ухудшение условий на 30% само собой отразится на мотивации.

Естественно, от хорошей жизни на это никто не согласится: если только совсем пусто с проектами. Тут уже сам заказчик должен задаться вопросом, а нужно ли ему работать с командой, которая не смогла найти себе проект: что это за такая команда, что у неё нет заказов? Здесь либо что-то не так с их уровнем компетенции, либо с организацией управления проектами и экономической грамотности руководителя. Иными словами, за скидку вы покупаете риск: кто знает, смогут ли эти люди довести ваш проект до конца?

Второй вариант – просить у студии скидку, обещая заказать у неё второй проект. На это сразу же хочется предложить заключить договор: у второго проекта сразу же скинуть 10%, а первый сделать по нормальной цене. Ни один из клиентов, которым я это предлагал, не согласился.

Я, как руководитель команды разработки, вижу это как самый банальный разводняк: человек и не собирался заказывать второй проект, а просто пытался выбить 10% от стоимости. В лучшем случае он рассчитывает на какое-нибудь туманное будущее, когда запустит свой первый проект, и только после него закажет второй (и, скорее всего, будет пытаться выбить скидку за третий проект).

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

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

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

Судите сами: когда капитализация проекта обещает вылиться в миллиарды, смысл отдавать даже хотя бы один процент, просто так теряя десятки миллионов в пользу разработчиков? Куда проще взять кредит и реализовать продукт за миллион. Очередное перекладывание рисков, причём обманным путём, ведь клиент обещает разработчику горы золота в будущем, хотя, по факту, скорее всего тот не получит ни гроша.

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

68% скидки, которые я смог получить после долгих расчётов, вы, вряд ли сможете получить. Студия скорее всего просто не согласится на все предлагаемые вами условия. Обычно в комплексе срабатывают одно-два условия, которые в конечном итоге обеспечат вам процентов 10-30. А делать всё сразу студии делать невыгодно: не бывает у них в жизни всё так плохо, чтобы соглашаться на всё. Однако хоть какой-то из этих моментов может выстрелить, и будет честной сделкой.

Я выделил два технических момента, на которых можно сэкономить и три экономических.

Технические – это те, на которые студия попросту не будет тратить своё время разработки. Экономия идёт благодаря отсутствию ряда пунктов в смете: разработчики за них не берутся, а вы экономите. Порой заказчики и не подозревают, что запуститься можно и без них: например, без прорисовки дизайна.

Дизайн

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

Будет, конечно, очень простенько, но в целом нормально: можно даже подправить цветовую гамму под собственный корпоративный стиль и поиграться со шрифтами. Если вы запускаетесь в сфере, в которой красота – не главное, дизайн будет лишним, и подобный вариант для вас – самое то.

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

Отсутствие работы дизайнера и верстальщика могут позволить сэкономить аж 25% от общего ценника.

Админка

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

В качестве БД мы используем Битрикс (для серверных приложений), у которого уже и так есть админка, или Firebase (для облачных приложений). В случае Firebase есть интерфейс управления и данные можно отредактировать из него. Для приложения в ~20 экранов в среднем закладывается 6 экранов админки. Без них можно сэкономить 12% бюджета.

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

Деньги вперёд

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

Работа над грядущим проектом в 1 миллион (для примера) займёт по меньшей мере три месяца. В таком случае, студия может согласиться на скидку в 5% (в редких случаях можно сторговаться до 10%), если клиент выплатит предоплату полностью здесь и сейчас. Таким образом, он получит тот же продукт без каких-либо ограничений, но расплачивается не в несколько этапов, а одномоментно отдаёт всю сумму. Выгодно для обеих сторон: клиент получает скидку, исполнитель решает свои финансовые проблемы.

Минус такого варианта в том, что он основан сугубо на доверии. Компания может слить ваш бюджет, а потом ей снова потребуются деньги, а на ваш проект средств нет. И тогда начинается тягомотина, которая вам вряд ли придётся по вкусу.

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

Увеличение срока

Момент, который подходит не всем. Так, у нас есть клиент, которому приложение нужно к следующему лету. У него спортивная тематика, и к нынешнему сезону он просто уже опоздал, поэтому приложение ему понадобится только к марту-апрелю. Делать его надо 3-4 месяца нормального темпа. Мы с клиентом договорились, что я даю ему скидку в 20%, но делаю приложение с перерывами, увеличивая срок выполнения в три раза. (т.е. не 3, а 9 месяцев, как раз к сезону).

Зачем это нужно мне? Клиенты есть и так, какой смысл терять в деньгах, растягивая срок выполнения проекта в три раза? Всё просто: у нас немало проектов отвалилось из-за коронавируса: у клиента деньги кончились, финансировать не из чего, проекты заморожены. Я понимаю, что у кого-то из текущих клиентов может случиться то же самое, и мне нужно иметь что-то сейчас, чтобы не выплачивать программистам за простой из своего кармана, а предложить им подобную задачу, когда нечего делать.

Я подстраховываюсь, а клиент получает за это скидку аж в 20%. Я не то что бы не тороплюсь его делать – я делаю его, когда у меня есть свободные руки и время. Например, когда один проект завершили, а за второй ещё взяться не успели. Или в пожарной ситуации, как, например, на днях: вроде планировали клиенту сделать вторую версию, а он и говорит, что до Нового Года, денег пока точно на это не будет.

Я заранее продумываю количество свободных часов у программистов, и беру подобные проекты как раз на случаи, когда разработчики ничем не будут заняты. Сейчас, за октябрь-ноябрь мы потихонечку соберём серверную часть и админку, к Новому Году, скорее всего, как обычно будет завал, в январе делать нечего, все две недели празднуют, а в феврале только начинают раскачиваться, вот тогда и доделаем, поправим баги – и готово.

Клиент получает сэкономил 20%, я недополучаю примерно 160 тысяч, но зато подстраховываюсь и точно имею проект, даже когда нет входящих в межсезонье. Я рассматриваю это как покупку страховки по оптимальной стоимости: я точно знаю, что смогу загрузить программистов, и мне будет чем платить им зарплату.

Экономия на налогах

Не совсем законно, но очень популярно. Сам я его не применяю и за него не ратую, однако знаю, что его используют. Суть его в том, что договор заключается между физлицами, и вся оплата проходит на карту. Большинство разработчиков приложений, работает на УСН, чаще всего это 6%, и, если оплата придёт на карту, в 99% случаев налоги с суммы платиться не будут. Про 13% дохода физлица обычно забывают, т.к. налоговая не шибко прессует.

Разработчикам не нужно выводить с расчётника, он экономит, и потому может предложить скидку при оплате сразу на карту. Получается скидка в 6% — и, давайте быть честными, обман государства. В нашей студии эта скидка уже зашита в изначальную стоимость, потому что в Самарской области действует патентная система на IT-компании, с фиксированной налоговой базой: платим примерно 3 тыс в год.

Поэтому такую скидку я не даю: я просто оптимизировал налоги законно и уже сразу снизил цену на эти 6%. В других регионах, кто висит на 6% УСН, может попробовать договориться. Схема опять же опасная, при платеже на карту вам будет сложнее доказать через суд, что вы платили за разработку, поднимутся вопросы о незаконной коммерческой деятельности, почему вы на это пошли, кто инициировал и пр. Если хочется – можете рискнуть.

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

Чисто теоретически такую схему представить можно, но в жизни настолько плохо всё не бывает. Тем не менее, процентов 15-20 получить вполне реально. Выбор, конечно, за вами – я раскрыл все карты, которые в принципе актуальны для всего рынка с небольшими погрешностями в ту или иную сторону.

Главное, договаривайтесь о скидке честно, чтобы не было взаимного обмана: скидка должна быть выгодной и вам, и студии.

Больше информации по разработке и наши кейсы можно посмотреть на YouTube.