Разработка для стартапа: технический партнёр от идеи до первого релиза

Фаундеру на старте нужен не просто исполнитель задач, а человек, который задаёт неудобные вопросы до того, как деньги потрачены. Зачем эта функция в первом релизе? Как поймём, что гипотеза подтвердилась? Что будет, если пользователей станет в десять раз больше?

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

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

1. Гипотеза и метрика успеха. Формулируем, что именно проверяем и по какому показателю поймём результат.
2. Пользователь и сценарий. Описываем, кто будет пользоваться продуктом и какой путь он должен пройти до ценности.
3. Минимальный состав. Оставляем функции, без которых гипотезу не проверить, остальное — в список на потом.
4. Прототип. Показываем кликабельный прототип нескольким будущим пользователям до разработки.
5. Разработка и запуск. Делаем релиз итерациями с демо, подключаем аналитику, запускаем на первую аудиторию.
6. Решения по данным. Смотрим на поведение пользователей и решаем, что развивать, что упростить, а от чего отказаться.

Если вам нужна именно разработка MVP с понятными сроками и форматом, подробности — на странице разработки MVP.

• Делать всё сразу. Полный набор функций откладывает запуск и не отвечает на главный вопрос — нужен ли продукт пользователям.
• Выбирать стек по моде. Технологии должны подходить задаче и рынку найма, иначе собственную команду потом будет сложно собрать.
• Запускаться без аналитики. Без событий и воронки невозможно понять, что сработало, и решения принимаются на ощущениях.
• Оставлять код и аккаунты у подрядчика. Репозиторий, серверы, домены и аккаунты в магазинах приложений должны принадлежать компании фаундера.
• Не думать о жизни после запуска. Поддержка, обновления и план следующих итераций нужны с первого дня, а не тогда, когда что-то сломалось.

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

Отдельно продумываем данные и безопасность: модель данных, резервные копии, разграничение доступа, хранение персональных данных пользователей из России на серверах в РФ. Эти решения дорого переделывать позже, поэтому их принимаем на этапе проектирования.

Если продукт относится к недвижимости, загляните в раздел PropTech-решений — это наша основная специализация.

Неопределённость на старте — норма, поэтому формат работы подстраиваем под стадию продукта.

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

Если по итогам мини-проектирования окажется, что гипотезу можно проверить без разработки — лендингом, опросом или ручным процессом, — мы так и скажем.