Мобильное приложение с чат-интерфейсом и эквайрингом
Мы сейчас работаем над проектом, близким по концепции с американскими Homee, Jiffy, Handy – то есть такой убер для небольших ремонтных работ. Ну, точнее, как работаем – офлайн-инфраструктура (в части исполнителей и процессов) у нас есть, а сейчас пришло время для технической части.
Что нам нужно?
Мобильное приложение (желательно сразу на 2 платформы) со следующими условиями:
1. Чат-интерфейс как основа взаимодействия (как пример – онбординг Яндекс.Драйва). Но в нашем случае весь процесс взаимодействия между клиентом, нами и исполнителем строится через чат-интерфейс, так что тут должна быть поддержка Rich Media и прочих плюшек. Поэтому в первую очередь, смотрим на Sendbird, но так же рассматриваем варианты с Chatkit, ChatEngine или Layer – но здесь нужна экспертиза с вашей стороны.
2. Полагаем, что оптимальным для старта будет использование Firebase в качестве BaaS, так что опыт работы с Firebase'ом тоже важен. К тому же, мы планируем, чтобы авторизация происходила только через номер телефона, а у Firebase есть бесплатный сервис по авторизации через смс.
3. Мы будем проводить все платежи через нас, так что важен функционал привязки карточки и автоплатежей. В этой части смотрим на CloudPayments, но платежных решений на рынке такое множество, что опять же готовы рассмотреть вашу экспертизу по этому вопросу.
Как видите, здесь не будет полноценного "самостоятельного" приложения, которое надо писать с нуля: все приложение – это своего рода конструктор, который собирается из различных сторонних SaaS (чат-интерфейс Sendbird или аналогов + оплата через эквайринг + Firebase как BaaS и средство авторизации). На этом функционал на данный момент исчерпывается – все остальное будет результатом личного взаимодействия и предоставления услуг.
Именно поэтому важно, чтобы у вас был опыт работы со всеми тремя направлениями, перечисленными выше, чтобы вы не тратили время на курение мануалов и могли сразу предложить оптимальный путь. Здесь нет сложностей разработки, здесь больше требуется опыт работы с отдельными кубиками, из которых соберется целое.
Что еще важно для понимания:
1. Российский рынок – не приоритетный для нас. Сейчас стоит задача исключительно отработать процессы и получить первичный traction, важный для пула инвесторов, с которыми мы общаемся. В ближайшем будущем мы будем полностью сконцентрированы на иностранных рынках.
2. Как следствие, сейчас не стоит задача построить глубокую архитектуру сервиса и проч. Мы делаем именно MVP – добротный и качественный, но с наименьшими усилиями и в наименьшие сроки. Прекрасно осознаем, что в ближайшем будущем будем переписывать практически весь сервис с нуля. Именно поэтому был выбран подход с "конструктором".
3. Мы готовы рассмотреть варианты с хорошей кросс-платформой (типа React Native или Flutter) либо же нативку. Но здесь выбор должен быть подчинен оптимальности соотношения двух вещей: тем, насколько вышеприведенные "кубики" хорошо работают с выбранным решением, и тем, насколько это ускоряет или, наоборот, усложняет процесс разработки. То есть, с одной стороны, важно наименьшее количество костылей и общая элегантность финального результата, а с другой, скорость его достижения.
4. У нас в команде сейчас не закрыта техническая компетенция, важная для полноценности команды и дальнейших взаимодействий с инвесторами. Были бы рады, если бы вы, откликаясь на заказ, потенциально рассматривали для себя такое развитие наших отношений – то есть условную позицию CTO. По этой причине, полагаю, что нам будет не очень интересно общаться со студиями разработки и прочим "коллективным" разумом – нам нужна личность, которую бы мы могли в дальнейшем презентовать как технического ко-фаундера.
Если текст выше вас заинтересовал и вам захотелось в этом поучаствовать – откликайтесь, будем рады пообщаться.