Как мы запустили наш первый MVP на рынке приложений для iOS
18 декабря 2023 г.Привет всем, меня зовут Макс Нечаев. Я iOS-разработчик и основатель стартапа. За последние полгода я прошел действительно интересный путь, полный сложностей, неопределенностей, проб, ошибок и фанатов.
Каждый из нас когда-нибудь задумывался о собственном бизнесе. Что делать, если ты не работаешь на кого-то другого? Что, если бы вы могли попробовать начать что-то свое? Смогу ли я это сделать? Я довольно часто сталкиваюсь с этими вопросами. Но в чем здесь причина? Дело в том, что если вы отбросите свои страхи и попытаетесь ответить на этот вопрос максимально правдиво, то, скорее всего, не сможете дать четкого и лаконичного ответа. Здесь мы сталкиваемся с крылатой фразой «Не узнаешь, пока не попробуешь».
Именно после этого осознания в моем сознании поселилось семя, которое проросло и давало мне все больше и больше пищи для размышлений каждый день и каждую неделю. Со временем я понял, что попробую создать свой стартап в IT-индустрии.
Подготовка и анализ рынка
Первое, что для меня было важно, — это моральная подготовка. Я читаю книги по менеджменту и бизнесу. Я провел много времени, просматривая YouTube видеоролики о разных нишах, анализируя предпринимателей и их стратегические решения. Прежде чем приступить к работе над любым проектом, очень важно быть к этому готовым изнутри, а не просто «придумать что-то и сделать».
Во-вторых, проанализировать рынок. Нельзя просто взять и сделать какую-то заявку, потому что рынок большой, есть преобладающие тенденции, есть лидеры и аутсайдеры, есть ниши денег, а есть ниши, где денег нет вообще, сколько бы маркетинга ни было. бюджеты, которые вы вкладываете в это. Существует множество нишевых аналитических сайтов, сначала я использовал SensorTower. Это помогает нам находить приложения в разных нишах в разных странах. Более того, вы можете увидеть, кто сколько зарабатывает (единственная проблема заключается в том, что здесь не показано, сколько кто-то тратит на маркетинг, поэтому вы не увидите реальную чистую прибыль).
В этой статье я хотел бы поделиться предпринятыми нами шагами, а не конкретным примером, поэтому я не буду вдаваться в подробности исследования. Мы пока не компания-миллионник, поэтому рабочих кейсов пока нет, но те, кто интересуется этой темой, найдут здесь много полезных советов.
И вот что я скажу. Мы остановились на нише приложений, которые помогают создателям контента и SMM-специалистам.
Создание команды
«Один человек не может сражаться в одиночку». Я продолжаю бомбардировать вас крылатыми фразами. Но в 21 веке это чистейшая правда. Я не привык слышать «истории успеха» о том, как какой-то программист из деревни что-то сделал и стал миллионером. Потому что даже если такие случаи и есть, то это скорее исключение из правил. Очень важно не впасть в «синдром выжившего». Не поймите меня неправильно: каждый хороший разработчик может написать свой первый MVP в одиночку. Но только если мы говорим о реальном коммерческом успехе, многократном финансовом росте и высокой продуктивности, мы говорим о команде.
На первых этапах нам не нужен большой офис и несколько отделов разработки. Нам нужно охватить несколько областей: интерфейс, серверная часть, дизайн, маркетинг.
Вам не обязательно нужны четыре человека, поскольку зачастую многим мобильным приложениям не требуется серверная часть, а один человек может выполнять несколько ролей.
Мне здесь повезло, у меня есть опыт работы маркетологом. Я понимаю, как работают метрики, рекламные помещения, что такое креативы, как они должны выглядеть и что нужно, чтобы все это запустить. Я не говорю, что я в этом лучший, но этого уровня достаточно для первых этапов жизни стартапа. Поэтому я занимаюсь разработкой iOS и маркетингом этого проекта.
Пройдя крутую школу от Y Combinator, я понял, что нужен сооснователь. Человек, который разделит мои ценности и будет двигаться в том же направлении, что и я. У стартапов с соучредителями во много раз больше шансов на успех, чем у стартапов с одним основателем. Об этом свидетельствует статистика, собранная специалистами Y Combinator. Если вас интересуют конкретные цифры, я призываю каждого пойти в свою школу.
Мой соучредитель (сюрприз-сюрприз) — бэкэнд-разработчик. Это означает, что помимо принятия некоторых бизнес-решений он сможет взять на себя и эту роль. Это значительно упростит разработку под iOS (поскольку большая часть логики будет вынесена на серверную часть). И, конечно же, это значительно увеличит нашу скорость. Мы оба старшие разработчики, а это значит, что мы сможем все грамотно продумать и сделать оптимально с минимальными финансовыми и временными затратами.
Осталась еще одна нераскрытая роль. UX/UI дизайнер. Поскольку я работаю в ИТ-индустрии, вокруг меня много талантливых людей. Так что, честно говоря, дизайнера я нашел даже раньше, чем сооснователя. Также она получит долю в собственности стартапа и должность главного дизайнера, когда штат сотрудников вырастет.
Итак, вместе мы покрываем все первоначальные потребности. С такой командой мы не сможем сделать ни одного, ни двух приложений.
Возможно, расширим команду и возьмем новых людей. Пока мы планируем брать лишь временный аутсорсинг за адекватные деньги (при необходимости).
С самого начала мы встраиваем процессы. Ставьте цели и задачи. Делаем доски разработки, расставляем вехи и распределяем все по датам. Просчитываем экономику проектов, планируем инвестиции, в каком объеме и на каких этапах. В общем, оперативная деятельность тоже начинает идти полным ходом.
Разработка дизайна
На этом этапе мы приступили к созданию пользовательского интерфейса приложения. Наша цель — стиль, удобство использования и красота с точки зрения пользователя. Мы тщательно проанализировали конкурентов и выявили слабые стороны каждого. После этого, улучшая их приложения, мы создаем свои.
В рамках проектирования я также определил ряд целей. У дизайнера есть сроки проработки каждого экрана. У нее есть описание функционала. Цели приложения и проблемы, которые оно решает.
В среднем мы работаем 4-5 дней (не полный рабочий день) на один экран. Опять же, кому-то это покажется слишком длинным, а кому-то слишком быстрым, но на данном этапе это работает, и мы этим довольны. Весь дизайн мы прорабатываем в Фигме. Все описания задач, доски и описания проектов находятся в Notion.
Наше приложение позволяет пользователям создавать и генерировать текстовый контент для социальных сетей. Именно поэтому мы разработали максимально простой и понятный дизайн, который полностью закроет проблемы с написанием постов, скриптов, их организацией и т.д.
Архитектура приложения
Я сейчас говорю не об архитектуре iOS-части, а скорее об архитектуре в целом. Скажу честно, изначально приложение делалось только для платформы iOS и хранит все локально. Я не собирался добавлять бэкэнд, но позже пересмотрел свое решение. Для этого мне пришлось переписать часть функционала. При этом было важным замечанием не нарушать существующее.
Итак, получается, что мы делаем полноценное клиент-серверное приложение, поэтому с архитектурой всё становится понятнее.
У нас есть «сервис», который отвечает за регистрацию и авторизацию пользователей, он упрощает работу iOS-приложения, ведь нужно всего лишь отправить пару запросов на бэкенд и «волшебство» начинается. На следующем этапе нам нужно было загрузить базу данных. Здесь мы будем хранить пользователей, их идентификаторы, данные и контент.
Отдельно нам нужно создать сервис для работы с базой данных. Потому что приложение должно хорошо синхронизироваться с ним каждый раз, когда пользователь открывает приложение.
Да-да, вы не ослышались. Пока мы работаем с несколько ограниченным функционалом полной синхронизации, так как она нам не так уж и нужна. Основная цель создания серверной части и загрузки туда пользовательского контента — сохранить прогресс. Никто не хочет удалять приложение или менять телефон и терять все свои данные и весь контент. Поэтому на данном этапе целью по-прежнему является сохранение, а не создание плавной мгновенной синхронизации для кроссплатформенности.
Здесь я хотел бы затронуть тему «оптимальности». Часто начинающие стартапы (такие как мы) совершают огромную ошибку, пытаясь создать идеальный продукт. Они тратят огромное количество времени (и некоторых даже финансовых ресурсов), чтобы создать идеальный продукт, который превзойдет всех остальных на рынке. Но правда в том, что, скорее всего, они никогда не дойдут до релиза. При ограниченных ресурсах слово «идеально» неприменимо. Даже первые версии Facebook были довольно нелепыми (не говоря уже о Amazon). Я, наоборот, сторонник слова «оптимальность». Это гораздо важнее и лаконичнее. Вместо того, чтобы делать идеальный продукт, идеальный дизайн, идеальную архитектуру и идеальные серверы, способные выдерживать колоссальные нагрузки, я придумаю оптимальное решение. Все будет работать нормально. НОРМАЛЬНЫЙ. И не более того. Все остальное я могу совершенствовать постепенно, пока оптимальное решение будет приносить мне немного денег.
Архитектура iOS
А теперь самое интересное.
Поскольку я разработчик iOS, я бы хотел написать здесь больше технических «материалов». Что мы использовали, почему и с какими проблемами столкнулись.
SwiftUI
О да. Мы отказались от UIKit. Еще точнее сказать: «Я сдался». Я решил, что раз начинаю писать что-то с нуля, пусть это будут новые и перспективные технологии. Более того, SwiftUI довольно легко верстается, экраны делаются быстро. Анимацию также легко реализовать. Более того, SwiftUI реактивный, мы работаем с фреймворком Joint и он работает вполне хорошо, кто бы что ни говорил.
Более того, я считаю, что для будущего найма это будет большим плюсом. Есть огромное количество талантливых разработчиков, которые уже очень хотят перейти на 100% SwiftUI, но пока не могут этого сделать. Подавляющее количество приложений все еще находится на UIKit. Переписывать их в новую структуру — это долго и дорого, а предприятиям не нравятся эти слова.
Пожалел ли я, что выбрал SwiftUI?
Если честно, несмотря на все плюсы нового фреймворка, есть и откровенные минусы. Например, навигация. Да, у большинства разработчиков с этим проблемы. Не совсем очевидно, как вынести логику маршрутизации в отдельную сущность, инкапсулировать ее там и снять эту ответственность с пользовательского интерфейса (как мы привыкли в UIKit). С iOS 16 это стало намного проще и понятнее, но проблема в том, что мы все еще поддерживаем iOS 15. Некоторые ребята пишут свои расширения и каким-то образом находят способ вывести логику маршрутизации через несколько уровней абстракции, у нас на это не было ресурсов. Вот почему мы получили классическую маршрутизацию SwiftUI.
Мы также столкнулись с проблемами с пользовательским TabBar, который не хотел работать корректно. Потратил около 4 дней, все сделал грамотно.
Реактивность – это боль? Для многих разработчиков создание реактивных приложений является непростой задачей. Особенно для тех, кто никогда не работал с этой парадигмой. У меня был довольно хороший опыт работы с RxSwift, так что в целом подход был знаком. Мне просто нужно было понять, как все это работает внутри SwiftUI и как построить архитектуру.
На заре запуска SwiftUI все говорили о том, что MVVM является для него идеальным шаблоном проектирования. Последние полгода я слышу противоположную точку зрения, что MVVM не подходит для SwiftUI, но MVI уже довольно интересно ложится. Я воспользовался классическим подходом, который рекомендует Apple. У меня было несколько менеджеров, которые были нужны во многих местах приложения, я создал один экземпляр и передал его по иерархии пользовательского интерфейса как переменную среды. Признаюсь, я пару раз делал отдельные ViewModel для экранов, так как не видел смысла делать класс наблюдаемым менеджером.
Выводы
Итак, хотелось бы подвести итоги вышеизложенного и итогов первого запуска.
Выберу ли я SwiftUI для своего следующего приложения? Скорее всего да. Но при написании приложения я буду более осторожен в написании кода, создам больше повторно используемых компонентов пользовательского интерфейса и более строго придерживаюсь архитектуры MVI.
Действительно ли нужна команда? Да, когда ты не один, ты чувствуешь себя увереннее и чувствуешь ответственность не только за свою судьбу, но и за своих ребят. Вместе продумывать бизнес или техническую архитектуру всегда интереснее и точнее. Плюс поговорка «одна голова хорошо, а две лучше» здесь отлично работает. Сейчас желание только увеличить штат компании.
А что насчет финансов? Было бы глупо ожидать большого дохода на старте проекта, поэтому я рассматриваю только инвестиции, инвестиции и еще раз инвестиции. Конечно, начинает появляться небольшой доход, и люди покупают подписки, но он не сравним с той суммой денег, которая поступает от инвестиций. Я понимаю эти риски и принимаю их во внимание.
Построение собственного бизнеса – это долгосрочная игра, полная рисков и затрат. Эмоционально я к этому готов. Это нелегкий путь, но я думаю, что он вполне реален для меня. Советовал бы я всем разработчикам идти по этому пути? Конечно, нет. Вокруг меня десятки талантливых разработчиков, они счастливы и зарабатывают много денег при достаточно низкой ответственности. У них много свободного времени. Они путешествуют и тратят деньги на все, что хотят. Нужно ли им бросать деньги в костер бизнеса, который может погаснуть в любой момент? Возможно нет. Каждый выбирает свой путь. Я, например, без всего этого жить не могу, а для некоторых это настоящий ад. Я не осуждаю никого из них и очень рад, что каждый человек выбирает свой путь.
Спасибо за уделенное время, по любым вопросам вы можете обращаться ко мне по почте или в Telegram (@maxnech) (или LinkedIn< /а>).
Оригинал