Создание приложения за 200 тысяч рублей: запускаем MVP
Осенью прошлого года к нам обратился основатель, которому нужно было проверить идею стартапа. При этом бюджет был крайне ограничен — инвестора, готового вложиться просто в идею не нашлось, поэтому MVP пришлось запускать на свои. В статье расскажу о переделке готового решения под другую идею.
Суть приложения заключается в общении между автолюбителями. Получается некая соцсеть для водителей. В рамках MVP:
- Мессенджер с поиском по номеру авто: если заблокировал выезд или понравилась девушка в пробке:)
- Барахолка: простенькая доска объявлений
- Возможность вводить номера авто из РФ и Молдовы
В перспективах:
- Оплата штрафов и прочая интеграция госорганов
- Услуги / товары для авто с таргетированием по модели (если у вас лексус, то рекламу калины не покажут)
- Развитие в качестве рекламной площадки
Сколько стоит?
Недавно писал статью про калькулятор для примерной оценки стоимости приложения. Так вот, забив наши рейты я тогда получил оценку в ±300 тыс. рублей. Снижение суммы даже до критичных 200 означало бы сделать проект без прибыли, да ещё и доплатить из своих.
При этом, цена в 300 тыс уже учитывает экономию х3 на серверной архитектуре, за счёт использования Firebase и на разработке приложений х2 за счёт кроссплатформенной разработки на Ionic.Framework.
Было решено использовать нашу заготовку RTPlatform — сверив ТЗ и готовый функционал увидели ряд соответствий, хоть изначально идея проекта далека от маркетплейса услуг. Вот какой мы получили список экранов и перечень работ, по итогу сравнения ТЗ и заготовки:
- Регистрация / авторизация. Берётся стандартная из заготовки без доработок, 0 часов
- Создание / редактирование профиля. Нужно доработать поля и подправить в БД профиль мастера. По средней оценке доработки экрана 4 часа
- Список диалогов. Такого экрана нет, решили делать не с нуля а переделать готовый экран списка уведомлений, где есть уведомления и о новых сообщениях. По средней оценке доработки экрана 4 часа
- Переписка. доработки внешнего вида и мелкого функционала. По средней оценке доработки экрана 4 часа
- Просмотр профиля пользователя. По средней оценке доработки экрана 4 часа
- Отправка сообщения по номеру авто. Такого экрана нет. Посчитали, как создание нового: 9ч
- Push-уведомления. Настройка новых уведомлений. По средней оценке доработки экрана 4 часа
- Список объявлений. Без изменений: 0ч
- Фильтр по категориям. Без изменений: 0ч
- Просмотр объявления. Запретили откликаться на объявление и изменили внешний вид. По средней оценке доработки экрана 4 часа
- Создание объявления. Без изменений: 0ч
- Мои объявления. Без изменений: 0ч
- Пользовательское соглашение. Без изменений: 0ч
- Меню. По средней оценке доработки экрана 4 часа
Суммарно вышло доделок на 33 часа, плюс цена лицензии. Это на 40% дешевле, чем разработка с нуля и в 4 раза быстрее.
Что получилось
При очевидности плюсов такого подхода в цене и сроках, нельзя забывать, что это MVP — будут мелкие огрехи при переходах между экранами, решение в типовом простеньком дизайне и т.д.
Для тестировании идеи или внутреннего использования вполне подойдёт такая реализация, но, если идея пойдёт, нужно реализовывать масштабируемый продукт, с автотестами, нагрузочным тестированием, дизайном и прочими атрибутами проверенной идеи. В среднем — это от 1 млн за такой же функционал.
MVP же можно воспринимать, как страховку. В данном случае основатель вложил ±180 тыс за то, чтобы узнать спрос, получить обратную связь от реальных пользователей своей идеи и сформировать требования — что же всё-таки нужно заказывать «от 1 млн» и стоит ли заказывать вообще.
Как минимум — это экономия денег, если идея не взлетит, как максимум — получение ценнейшей информации о потребностях рынка, которые не узнаешь в таком объёме ни через какие опросы.
Подобный принцип переделки готового решения под себя можно использовать и в сайтах, и в приложениях.
Использование готовых шаблонов это круто, но бывает проблема с масштабируемостью. Однажды клиент налетел на такие грабли, когда решил переделать приложение от старого подрядчика. Мы никогда не испытывали столько боли.
Для MVP — абсолютно правильно использовать всё, что ускорит разработку.
Быстро запускаешь > Зарабатываешь > Переписываешь всё как нужно > Покупаешь Порш
а не
Долго и дорого пишешь как нужно > Ой, уже 10 конкурентов появилось > Ничего не зарабатываешь и ничего не покупаешь
Так и есть. Но по опыту "переписываешь как нужно" разбиается о стену непонимания. Начиная от сделать как нужно сразу, с уверенностью, что тестировать идею смысла нет. Заканчивая подозрением в разводе на деньги, мол два раза хочешь на мне заработать. И это крайне печально.
Просто у людей далёких от IT отсутствует понимание, как именно разрабатывается софт.
Например, приложение стоило 400 000 денег. В нём было 20 кнопок. Когда заказчик просит добавить ещё 2 кнопки, а ты ему выкатываешь счёт ещё на 400 000, у него ломается в голове. Он не понимает, почему там 1 кнопка стоила 20 000, а тут уже 200 000.
Показательная история была в Чехии, когда за выходные 60 программистов что-то написали, подарили государству. По моим прикидкам решение за выходные и бесплатно выходит дороже коррупционного договора. Подробно по ссылке.
ЧТОБЫ МИНИМИЗИРОВАТЬ РИСК НЕГАТИВА
Всегда раскладываю стартаперам варианты разработки их MVP.
1. Делаем сразу качественно. Получается долго и дорого. Переделка потом вдруг будет дорогой, если потребуется. Опыт показывает, что доделки есть почти всегда.
2. Делаем вначале как можно проще и дешевле. Быстро проверяем валидируем маркетинговую гипотезу. С вероятность близкой к 100% будут доделки. По идее, с доделками должна получиться сумма близкая к стоимости 1 варианта.
Если человек понял, какие у него риски, как вообще работает и оценивается разработка, ему будет меньше поводов для негатива.