Тендеры и лиды
Информация
В 2018-м к нам пришёл стартап. Ребята горели идеей: сделать приложение, «ну, как Uber, только с котиками». Курьерская доставка пушистых хвостов по городу — мило, вирусно, перспективно. Было ТЗ на три страницы и уверенность, что всё это «не сильно сложно, вы же профессионалы».
Через три месяца, пару выгоревших менеджеров и два миллиона рублей, они узнали, что геолокация - это не просто «карта на экране». Что push-уведомления с милашками нужно не просто отрисовать, а ещё как-то доставлять. Что если приложение крашится на каждом втором Xiaomi, то пушистики не спасут.
Это не единичный случай.
Именно поэтому мы решили собрать в одном месте все эти «просто сделайте нам приложение», которые обычно заканчиваются болью для клиента, команды и бюджета.
Потому что мифы о мобильной разработке, как грабли - наступают все. Просто каждый уверен, что с ним-то точно всё будет иначе.
— «У вас же наверняка есть какие-то шаблоны? Нам не нужно ничего сложного. Главное — чтобы работало.»
Такие фразы мы слышим почти каждую неделю. И, честно сказать, шаблоны у нас действительно есть. Компоненты, подходы, наработки и всё как положено. Но вот беда: даже если взять готовую форму авторизации, она всё равно должна знать, кто ваш пользователь, как вы с ним общаетесь, какие данные ему показывать, как быстро и в каком формате.
А если бизнес уникальный (а он почти всегда такой), то «шаблон» превращается в болванку, которую всё равно надо адаптировать, отлаживать, интегрировать. И тестировать. Да, тестировать обязательно, иначе потом будет весело, но больно.
К нам обратился банк, который решил «ускориться», пропустить аналитику и сразу делать. Приложение было внешне симпатичное. Но через месяц после релиза отток пользователей составил 80%. Люди просто не понимали, куда нажимать. Нельзя было оплатить счет без звонка в колл-центр. Всё работало, но не так, как ожидали клиенты. Исправлять всё это оказалось дороже, чем сделать нормально с самого начала.
Да, можно ускориться, если вы готовы на компромиссы и чётко понимаете, что именно упрощается. Но если хочется продукт, который будет развиваться, приносить деньги и не бесить пользователей, то путь примерно такой:
2 недели на исследование и аналитику → интерактивный прототип → тесты на живых людях → дизайн → разработка → тестирование → релиз.
Дольше? Да.
Зато не придётся всё переделывать через два месяца. И не придётся объяснять инвесторам, куда делись деньги.
Если очень-очень повезёт — можно уложиться в 1,5 месяца. Но если вы не хотите надеяться на удачу, то планируйте от 2–3 месяцев. И с запасом.
— «Давайте на Flutter. Говорят, быстро, удобно и всё сразу — и Android, и iOS.»
Говорят, и в целом не врут. Flutter и React Native действительно хороши. Мы сами их любим, особенно когда нужно быстро проверить гипотезу. Кроссплатформа позволяет сэкономить на разработке, ускорить выход MVP, и выглядит вполне достойно.
Но как только дело доходит до тонкостей, тут начинаются нюансы.
💥 Пример из жизни:
Делали мы как-то приложение для доставки еды. Сначала на Flutter. Всё было отлично, пока пользовательская база не перевалила за 100 тысяч. Тут начали сыпаться жалобы: "Тормозит на моём Xiaomi", "Карта не грузится", "Кнопка залипает" и понеслось.
Проблема была не в коде как таковом. А в том, что при большой нагрузке, множестве анимаций и нестабильном интернете кроссплатформа ведёт себя… ну, по-разному. Особенно на Android-смартфонах с трехлетней историей и убитой батареей.
В итоге: Пришлось точечно переписывать на Kotlin. Производительность выросла в два раза, количество жалоб почти обнулилось. Стоило дороже? Да. Но зато без костылей и с гарантией, что «не развалится на проде».
Когда выбираем натив (Kotlin/Swift):
Когда идём в кроссплатформу (Flutter/React Native):
👉 Важно:
Нет «универсального» решения. Есть адекватный выбор под ваши задачи. И да, иногда это гибрид: 80% на кроссплатформе + 20% нативного кода для критичных модулей.
— «Мы сами прикинули дизайн. Вот кнопка, вот логотип. Остальное — по вкусу.»
Ага. Только потом оказывается, что кнопка «Купить» где-то под фильтрами, логотип перекрывает меню, а пользователи закрывают приложение, потому что не могут найти, как оформить заказ.
Один наш дизайнер как-то сказал:
«Если пользователь не нашёл "Купить" за 3 секунды — это провал.»И был прав.
💥 История из практики: почему «красиво» ≠ «удобно»
Был у нас проект — агрегатор такси. По задумке всё выглядело круто: иконки, тени, анимации.Но вот беда: кнопка "Заказать поездку" была в четвертом экране, спрятана под меню "Мой профиль" → "История поездок" → "Повторить заказ".
Люди не понимали, как вызвать машину.Зато точно знали, как удалить приложение.
Что пошло не так:
👉 Главное правило:
Дизайн должен решать задачу, а не участвовать в конкурсе арт-объектов. «Но нам же хочется выделиться!» — выделяйтесь удобством, а не креативным беспорядком.
— «Ура! Приложение в сторе. Отмечаем?»
Можно. И даже нужно — команда заслужила. Но только пусть это будет не прощальная вечеринка, а перерыв перед следующим этапом.
Потому что публикация приложения — это не финал. Это, скорее, выпуск в открытый космос. До этого всё было под контролем: тестовые устройства, демо-аккаунты, команда рядом.
А теперь реальные пользователи, тысячи моделей устройств, новые версии iOS и Android, нестабильный интернет, неожиданные сценарии использования, и да, всё это одновременно.
💥 Реальность:
Примерно так проходят первые три месяца после релиза. И это нормально. Мы сами закладываем на этот этап плотное сопровождение, потому что знаем: даже идеальный код в бою начинает вести себя по-другому.
💬 Наш совет:
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13203 тендера
проведено за восемь лет работы нашего сайта.
Релиз — это не финиш, а только середина. Поддержка, обновления и вовлеченность команды после запуска - это то, что отличает хороший продукт от того, что «лежит мёртвым грузом в сторах».
— «Зачем переплачивать студии, если на фрилансе тоже могут сделать? У нас есть человек за 50 тысяч. Он всё умеет.»
Такая история не редкость. И иногда всё действительно идёт хорошо: фрилансер — профи, сроки чёткие, задачи ясные.
Но чаще бывает так:
«Наняли разработчика за 50к, он пропал через месяц. Теперь код никто не понимает. Ни он, ни мы.»
Это дословная цитата из чата с одним из клиентов. Фрилансер начал проект, сделал часть, ушёл без документации. Потом ещё один переписал часть логики.Когда мы вошли в проект, там был красивый интерфейс и полный хаос под капотом.
✅ Процессы
У нас всё фиксируется: задачи, сроки, приоритеты. Никакой «сделал и забыл». Промежуточные сборки, code review, тестирование, трекинг в Jira или отечественных аналогах, чтобы всё было как положено.
✅ Гарантии
Фрилансер уехал в горы без связи и всё. А студия отвечает по договору. Если один разработчик заболел, то подключится другой. Проект не стоит на месте.
✅ Документирование
Архитектура, API, логика интерфейсов — всё описано. Чтобы через 2 года можно было прийти и понять, что к чему.
💬 Фраза, которую мы повторяем очень часто:
«Дешево - не значит плохо. Но если дёшево - готовьтесь к рискам.»Срывы сроков, отсутствие поддержки, «уникальные» решения без документации стоят дороже. Просто не сразу.
✔️ Наш совет:
Если выбираете фриланс, то просите архитектуру, описание логики, регулярные коммиты и внятный трекер задач. А ещё резервируйте бюджет на доработки, потому, что почти всегда они будут.
— «У нас полное ТЗ, давайте сразу делать весь функционал. Чтобы потом не переделывать.»
Звучит логично. На бумаге вообще отлично: всё продумано, описано, список фичей внушительный, амбиции — выше крыши. Но есть нюанс: пользователи не читают ТЗ. Они кликают, свайпают, закрывают. Или остаются — если приложение попадает в цель.
💥 История с деньгами (и спасением):
В одном проекте клиент планировал большой запуск: лента, личный кабинет, чат, система рекомендаций, фильтры, бонусы, аналитика, бейджики.
Мы предложили начать с MVP: только ключевой сценарий — загрузка и продажа товара. Без лишнего.
Запустили через 2 месяца. Первые 500 пользователей показали, что люди не хотят сидеть в приложении. Они хотят быстро продать, получить деньги и уйти.
Результат: ✅ Оставили только нужное. ✅ Не потратили бюджет на «чаты, бейджики и геймификацию». ✅ Уложились в срок и сэкономили около 700 тысяч рублей. Просто потому что не стали делать то, что оказалось ненужным.
MVP — это не «обрезанный продукт».
Это инструмент проверки гипотезы:
💬 Наш совет:
MVP — не экономия, а стратегия. Хуже, чем сделать слишком мало — только сделать слишком много, а потом всё выкинуть.
— «У нас есть концепция. Ну, примерно как Avito, только для аренды детских костюмов. Мы скинули ТЗ, а дальше вы сами, ладно?» Нет, не ладно.
Мы с радостью возьмемся за проект. Но чтобы сделать рабочий продукт, нам нужно больше, чем просто идея и файл в Word с пунктами «Главный экран, фильтры, корзина».
Почему так не работает:
Любое приложение — это отражение процессов внутри бизнеса. Если мы не понимаем, как у вас работает логистика, оплата, возвраты, поддержка, сезонность, то мы делаем не продукт, а догадки. А догадки, как показывает практика, редко работают на прибыль.
💥 Кейс:
Один клиент прислал схему приложения и уточнил: «Нам важна скорость. Коммуникацию сведем к минимуму.» Мы сделали по описанию. Всё строго по ТЗ. В срок. На запуске оказалось:
В итоге потребовалась перепланировка, новые итерации, потери по времени и деньгам.
💬 Мы не просто «кодим»:
Мы делаем инструмент, который должен работать в живом бизнесе. Для этого нам нужно быть частью процесса, а не просто исполнителями.
Мы уже 7 лет исправляем чужие косяки. Знаем, как это бывает: идея отличная, команда на энтузиазме, а потом всё упирается в сроки, баги, пользователей, которые «чего-то не поняли и удалили приложение».
80% проблем, с которыми к нам приходят, — это последствия тех самых мифов, про которые мы только что рассказали.
P.S. Котики из первого примера всё же получили свой Uber. С геолокацией, оплатой и пушами. Правда, после трёх итераций дизайна и одной бессонной ночи с проджектом, который мимикрировал под клиента в тестах. Но теперь всё работает. И мурчит.
