Это гостевой пост от Дипака Ченнаккадана, основателя Pollzy, разработчика-одиночки, который запустил Pollzy на iOS и Android.
Я создал и запустил Pollzy на iOS и Android в одиночку, хотя до этого никогда не разрабатывал мобильные приложения. Я также регулярно посещаю мероприятие Expo в Сиэтле, поэтому поделился своей работой с командой лично, и они попросили меня написать небольшой блог, так что поехали!
26 августа 2026 года я запустил , социальную платформу, построенную вокруг мнений, как на iOS, так и на Android. В приложении есть персонализированные ленты, обмени сообщениями, пуш-уведомления, модерация, подписки, реклама и многие другие системы, которые вы ожидаете от социальной платформы.
Команда инженеров за кулисами? Только я.
Я потратил годы на создание программного обеспечения в Microsoft и Turn 10 Studios, работая над франшизой Forza. Но создание собственного продукта оказалось совершенно другим опытом. Во-первых, я никогда раньше не строил мобильных приложений. Во-вторых, я хотел сделать то, чего никогда не делал профессионально: отвечать за каждый отдельный компонент продукта — от первоначальной идеи и дизайна до инженерии, инфраструктуры, монетизации и управления самим бизнесом.
Поэтому 15 июля 2025 года я начал создавать Pollzy. Чуть больше года спустя он уже работал в обоих магазинах приложений (я, очевидно, мог бы запустить его раньше).
Создание социальных сетей на основе участия
Идея Pollzy родилась из того, что я замечал в социальных сетях. Большая часть соцсетей стала сводиться к потреблению контента, а не к взаимодействию с людьми. Большую часть времени мы просто прокручиваем ленту, смотрим и время от времени ставим лайки.
Опросы всегда казались мне интересным исключением. Ответ на опрос требует почти нулевых усилий. Перед вами выбор, вы делаете его и сразу же хотите узнать, что думают остальные. Мне стало интересно, что произойдет, если такое взаимодействие станет основой для целой социальной сети. Так появился Pollzy.
Основной интерфейс прост: свайпайте опросы, голосуйте, смотрите, как проголосовали остальные, и находите людей с похожими взглядами. Я также хотел привнести в процесс элементы геймификации. В Pollzy предусмотрены различные способы участия, такие как классические опросы, викторины и дуэли один на один. Такие функции, как Vibe Check, позволяют пользователям узнать, насколько их выбор совпадает с мнением других. Я хотел, чтобы голосование занимало всего несколько секунд, но при этом у людей оставалась причина возвращаться.
Почему я выбрал Expo
Прежде чем приступить к Pollzy, я изучил различные подходы к кроссплатформенной мобильной разработке. Я знал, что хочу запуститься как на iOS, так и на Android, но создавать и поддерживать два отдельных нативных приложения не имело смысла для разработчика-одиночки. Expo и React Native казались очевидным выбором.
Был и практический аспект: у меня не было Mac, когда я начинал разработку Pollzy. Expo Build позволил создавать сборки для iOS в облаке без необходимости настройки локальной среды сборки macOS. Это существенно снизило порог входа.
Я начал с Expo Go, что отлично подходило для быстрой итерации базовых сценариев взаимодействия без беспокойства о нативных сборках. Как только я начал интегрировать зависимости, требующие нативного кода, я переключился на девелоперские сборки Expo. Это позволило сохранить привычный рабочий процесс разработки на React Native и одновременно тестировать нативные модули, от которых зависело продакшн-приложение. В конечном итоге сюда вошли подписки, реклама, верификация личности, отчеты о сбоях и процессы запроса разрешений на отслеживание.
Я держал под рукой iPhone и устройство на Android на протяжении всей разработки, чтобы тестировать изменения на обеих платформах. Даже при наличии общего кодовой базы было множество различий, которые нужно было учитывать, особенно в отношении навигации и масштабирования интерфейса на Android. Expo значительно упростила разработку под обе платформы, но общий код не избавил от необходимости тестирования под конкретные платформы.
Инженерная составляющая кажущегося простым приложения
С самого начала я старался делать архитектуру Pollzy максимально модульной. Я знал, что мне придется создавать множество разных систем, и не хотел, чтобы кодовая база превратилась в кошмар при добавлении новых функций.
В качестве бэкенда я выбрал Firebase: в основном Firestore для данных, Cloud Functions для серверной логики и Storage для медиафайлов. Это был практичный выбор для реализации необходимого функционала реального времени без самостоятельного управления большой серверной инфраструктурой.
Лента оказалась сложнее свайпа
Интерфейс свайпа и голосования на самом деле был первым взаимодействием, которое я создал. Я потратил больше времени, чем ожидал, на изучение карточных интерфейсов, включая механику свайпов в Tinder. Мне хотелось, чтобы свайп ощущался правильно, так как пользователи будут делать это постоянно. Но гораздо большей проблемой оказалось все, что находилось за кулисами ленты.
Я не хотел, чтобы Pollzy просто отображал опросы в хронологическом порядке. Мне нужна была персонализированная алгоритмическая выдача при сохранении эффективности бэкенда и контроля над операционными расходами. Мне пришлось поломать голову над тем, как выбирать, ранжировать и персонализировать опросы, не делая генерацию каждой страницы ленты ресурсоемкой. В итоге я создал общие пулы рекомендаций и задействовал сигналы личных интересов для персонализации контента, а также применил кэширование и пагинацию для контроля числа чтений из Firestore. Мне также пришлось учесть новых пользователей, которые еще ни за что не голосовали.
Функции, о которых никто не задумывается
Одной из функций, которую я явно недооценил, стала поддержка нескольких аккаунтов. С точки зрения пользователя, переключение между аккаунтами может быть простым двойным тапом. Реализация этого означала поддержку независимых сеансов аутентификации, изоляцию кэшированных данных и состояния в памяти, маршрутизацию уведомлений в нужный аккаунт и гарантию того, что информация из одной учетной записи никогда не попадет в другую.
Пуш-уведомления включали в себя гораздо больше, чем просто отправку алерта. Expo Notifications справилась с интеграцией на стороне устройства, но мне все равно пришлось настраивать серверную маршрутизацию, группировку, учет значков и специфичное для аккаунтов поведение при различных социальных взаимодействиях.
Система обмена сообщениями принесла свои трудности, такие как обработка запросов на сообщения, определение того, кто с кем может связаться, и обеспечение корректной работы уведомлений.
Я также интегрировал такие сервисы, как RevenueCat для подписок, Stripe Identity для верификации и Google AdMob для рекламы. Я думал, что интеграция AdMob будет относительно простой. Оказалось, что нет. Учитывая нативную рекламу, медиацию и различные интеграции SDK, я потратил на рекламу гораздо больше времени, чем предполагал.
Реклама также показала мне, что использование Expo не означает полного отказа от нативной конфигурации. Поддержка медиации AdMob потребовала нативных SDK-адаптеров и специфичных для платформ настроек для таких сетей, как Unity Ads, Meta Audience Network и Liftoff Monetize. Я реализовал эти интеграции с помощью локальных для проекта плагинов конфигурации Expo, что позволило сделать настройку нативной части воспроизводимой, избавив меня от необходимости вручную поддерживать раздельные проекты iOS и Android.
Вот соответствующий список плагинов из app.json:
Создание с помощью ИИ на протяжении всего процесса разработки
ИИ также сыграл большую роль в том, как я создал Pollzy. Я активно использовал Codex на протяжении всей разработки. На самом деле, одной из вещей, которые я хотел исследовать в этом проекте, было то, насколько далеко я могу зайти в разработке с помощью ИИ при создании реального продукта, а не просто экспериментируя с небольшими проектами. Я уже потратил время на работу над инициативами в области ИИ в Xbox, поэтому был знаком с тем, на что способны эти инструменты. Но применение их в проекте, где я отвечал абсолютно за все, было другим опытом.
Я использовал ИИ, чтобы помочь реализовывать функции, отлаживать проблемы, рефакторить код и разбираться в частях мобильной разработки, которые были для меня совершенно новыми. Codex был невероятно полезен, но дело было не в том, чтобы просто попросить его что-то построить и получить работающую функцию в ответ. Мне все равно приходилось разбираться в архитектуре, принимать продуктовые решения, просматривать код и замечать то, что было реализовано неправильно.
Даже со всеми связанными с этим проверками и тестированием, ИИ внес огромный вклад в то, как быстро я мог создавать продукт. Я не уверен, что попытался бы создать что-то столь масштабное в одиночку несколько лет назад.
Ошибки, которых я бы избежал в следующий раз
Одна из моихbiggest ошибок заключалась в том, что я оставил большую часть работы над правилами безопасности Firebase на поздний этап разработки. Я постоянно откладывал правила безопасности, потому что был сосредоточен на обеспечении работоспособности функций. Когда я наконец ужесточил их, я в итоге сломал кучу процессов, которые отлично работали в TestFlight. Затем мне пришлось возвращаться к приложению и исправлять то, что, как мне казалось, уже было завершено. Если бы я делал это снова, я бы внедрял и тестировал правила безопасности вместе с каждой функцией, а не оставлял их на потом.
Я также слишком долго не уделял внимания использованию Firestore. К тому моменту, как я начал внимательно изучать операции чтения и записи, особенно в лентах и реально-временных слушателях, я понял, что части реализации выполняют гораздо больше работы, чем необходимо. В итоге я реструктурировал часть этого, чтобы сократить ненужные операции. Определенно то, о чем в следующий раз я подумаю намного раньше.
Позже я создал реалистичные наборы данных эмулятора Firebase и инструменты профилирования затрат, чтобы я мог тестировать ленты, голосования, комментарии, обмен сообщениями и уведомления, не экспериментируя в продакшене. Это значительно упростило обнаружение неаффективных запросов, слишком широких слушателей и взаимодействий, которые генерировали ненужные операции чтения.
Путь от разработки до App Store
Что Expo сделала удивительно простым, так это доставку сборки тестерам и в конечном итоге в магазины приложений. С помощью Expo Build and Expo Submit распространение сборок через TestFlight и Google Play стало повторяемой частью моего рабочего процесса разработки. В преддверии запуска я распространял сборки TestFlight примерно раз в два дня, что значительно упростило тестирование и исправление проблем, специфичных для платформы.
26 августа 2026 года Pollzy официально запустился на iOS и Android. Переход от создания мобильного приложения с нуля до его выпуска на обеих платформах был весьма удовлетворительным. С момента запуска я поддерживал аналогичный темп, выпуская обновления примерно каждые два-три дня.
Самое трудное, возможно, наступит после запуска
Меня никогда особо не пугал инжиниринг, связанный с созданием Pollzy. Я потратил годы на решение технических проблем, и я также довольно упертый, когда дело доходит до завершения начатого. Я полагал, что в конце концов справлюсь с любыми трудностями, которые возникнут. Гораздо более пугающим мне показалось все, что последовало за созданием приложения.
Маркетинг, например. Создание социальной сети — это одно. Реально заставить людей ею пользоваться — совсем другое. Существует вся проблема холодного старта, когда для того, чтобы сделать платформу интересной, требуется существующее сообщество, и в то же время вы пытаетесь привлечь людей, когда этого сообщества еще не существует.
И затем есть все, что связано с ведением бизнеса. Бухгалтерия, налоги, юридические обязанности, поиск способов получения дохода и так далее. В Microsoft были целые команды, занимающиеся различными частями продукта и бизнеса. В Pollzy я отвечаю за все это. Пожалуй, это было самым большим изменением на данный момент.
Итак, сколько инженеров для этого требуется?
Когда я показывал Pollzy людям, одной из реакций, с которыми я довольно часто сталкивался, было удивление тому, что я создал все это в одиночку. Я могу это понять. За приложением скрывается гораздо больше, чем может показаться на первый взгляд из относительно простого опыта свайпов и голосования. Я не считаю, что это делает инженерные команды ненужными. Но это определенно меняет то, что один разработчик может реально построить.
Expo сделала кроссплатформенную разработку и дистрибуцию гораздо более доступными. Firebase позаботился о большой части бэкенд-инфраструктуры, а Codex помог мне справиться с разработкой намного быстрее, чем я смог бы иначе.
Я начал этот проект, не имея опыта создания мобильных приложений. Теперь у меня есть социальная сеть, работающая как на iOS, так и на Android, и я разбираюсь во всем, что связано с поддержанием ее работы и попытками ее вырастить.
Если вы хотите посмотреть на него, вы можете попробовать Pollzy. Я буду рад услышать ваше мнение.
Итак, сколько инженеров для этого требуется?
В данном случае всего один.
