Прошу мнения экспертов в выборе технологий для образовательного стартапа

Привет, douвчане,

так вышло, что пару лет назад я ввязался в образовательный онлайн-проект, да еще и в мягких нишах. на готовых no-code решениях мы сделали сервис, который подтвердил маркетинговую гипотезу и бизнес-модель, начал генерить ревенью и теперь пришло время писать свою платформу, чтобы масштабироваться, быть гибким и независимым.

Стартап называется ONEHOBBY, мы работаем как сервис по подписке и предлагаем ученикам курсы в теме хобби. сейчас это рисование, в планах на 2-3 года еще минимум 20 направлений (ближайший известный аналог из штатов — skillshare или masterclass).

основа бизнес-модели:

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

платформа продает подписку (ежемесячную/годовую) ко всему контенту, часть ревенью распределяет между экспертами пропорционально просмотрам (также, платформа выдвигает требования к контенту, модерирует курсы и управляет качеством).

немного вводных для технически одаренных читателей:

  • видео-стриминговый сервис по подписке (хостинг на vimeo)
  • 75% пользователей смотрят на мобильных, 20% пк/ноутбук, 3% планшеты
  • интеграция с платежками и рекуррентные платежи (fondy, liqpay, paypal)
  • возможность вывода средств на карту физика/ФОПика
  • сервис email рассылок
  • dau до 10.000 чел
  • гео: Украина+СНГ, через 2 года Африка и Азия

в релизной версии 1.0 должны быть:

  • web и mobile приложения для пользователей (7-10 экранов)
  • web админка для менеджинга контента, пользователей и ролей
  • аналитика просмотров каждого видео по минутам относительно эксперта (это основа БМ)
  • умная лента, которая советует курсы по вподобанням и прогрессу (YT, deezer, spotify)
  • геймификация с ачивками за часы, курсы и т.д.
  • скоринг видео, на основании оценок, глубины просмотра и количества просмотров
  • клендарь-плэнер, который напоминает посмотреть запланированные курсы

учитывая то, что мы привлекаем инвестиции под разработку, инвесторы хотят MVP через 3 месяца. я его вижу примерно так: тыць

сейчас речь идет не про оценку в часах, годах или человеках. мне нужна ваша экспертиза именно в технологиях.

исходя из моего понимания

  • бекенд на node.js
  • web UI на react или vue
  • mobile на react native

но опять же, мой бекграунд QA и шо я там ото вообще понимаю в технологиях))

в этом топике хочу попросить небезразличных IT экспертов дать свое мнение на каких технологиях лучше писать приложение (особенно, если у вас есть опыт создания коммерчески успешных мобильных ап).

а также, если это случайно увидит UI/UX дизайнер который захочет отрисовать нам экраны и сделать топовый кейс в портфолио, пишите, буду рад познакомиться))

если какой-то инфы не хватает, пишите, добавлю.

заранее спасибо!

👍НравитсяПонравилось2
В избранноеВ избранном1
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
react native

Только не это. Возьмите лучше Flutter.

Потому что объективно RN это г**но собаки, которое постепенно загибается и катится на свалку истории в виду того что все на него забили в том числе и создатели самого RN.

Сколько я не общался с людьми которые имели дело с RN (будь то веб-разработчики на React либо нативщики iOS / Android) — все вспоминают это время как хождение с бутылкой / пробкой в одном месте

Куча библиотек в которых баги фиксить нужно либо руками (и потом пробемы с npm install) — либо форкать и писать фикс уже там под конкретный проект себе.

Чего не скажешь о Flutter — все отзывы ± положительные.

Так же просто стоит глянуть на рынок вакансий кандидатов чтобы понять что Flutter выгоднее и что RN — это поддержка существующих проектов которые уже сложно переписать.

Если не хотите закопать мобильное приложение со старта — то либо Flutter (чисто для MVP) либо сразу на нативе.

Но после прочтения технических требований — а именно

видео-стриминговый сервис по подписке (хостинг на vimeo)
интеграция с платежками и рекуррентные платежи (fondy, liqpay, paypal)

Советую начинать сразу на нативе, чтоб потом не сесть на бутылку по производительности на стримминге

+ не знаю как обстоят дела с платежными SDK на Flutter — тоже могут быть проблемы с интеграцией

Поскольку есть таргетинг планируется не на особо богатые регионы то лучше стартовать с Android — в случае выбора только нативщины, потом и iOS подтянется.

не могу сказать, что со всем согласен, но принимаю ваше мнение. спасибо за ответ

Мне кажется вы зашли чуть не с той стороны, у вас очень наивно написанное ТЗ
У нас на аутсорсе огромное кол-во подобных проектов создается, я лично знаю человек 5 которые руководят разработкой разнообразных LMS или аналогов skillshare
Попробуй просто поискать по Линкедину и спросить совета у людей которые уже делают подобное.
Из личного опыта могу сказать, что те проблемы которые описаны тут вообще не проблемы.

Если прямо отвечать на вопрос который был задан — делай попроще, учитывая реалии рынка ИТ труда ты просто не соберешь на Ноде тиму имея сроки в 3 месяца.
Ты хантить будешь месяца 2 минимум. И не факт что через неделю кто-то не уйдет в условный Софтсерв и вся разработка встанет.
Если ты думаешь что с бюджетом это не проблема — нет, посмотри для примера эту вакансию на Джине, неделя прошла — 0 откликов djinni.co/...​-developer-node-angular
А у тебя еще стартап под урк рынок, это далеко не плюс в глазах опытных разработчиков.

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

неделя прошла — 0 откликов

С такой вилкой можно долго ждать)

Василий, добавьте пожалуйста чуть больше конкретики. На какую вилку сейчас идут многорукие мастера?

спасибо за советы. что касается ТЗ, то это высокоуровневые требования, чтобы было понимание, что в принципе надо сделать. вряд ли ты бы тут сидел и читал 100+ страниц исчерпывающей документации.

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

Другими словами, ты начинаешь с узких мест, и уже от них пляшут твои требования к разработчику.

Неочевидный момент: MVP стадия в твоём проекте опасна, я бы сказал даже недопустима. При DAU 10 000 ты попросту рискуешь просрать проект, потеряв аудиторию, и риски огромны. Проще послать нахер «инвестора». Если инвестор не готов выигрывать, такой тебе не нужен. Классическая дилемма курицы и свиньи: инвестор теряет лишь небольшую денежку, ты теряешь проект целиком.

Что тебе нужно, так это разбить проект на задачи и делать их по-отдельности.
1) Бэкенд. Его можно делать на чём угодно и переписыввать сколько угодно раз, как целиком, так и по частям. Грубо говоря, это самый подконтрольный зоопарк, потому несёт наименьшие риски.
2) Видеохостинг. Тут вопрос денег, и правильнее всего поднимать собственный сервер. Потому что с облаками никогда не бывает просто: либо дорого, либо ненадёжно, а чаще — и то, и другое сразу.
3) Видеопроигрыватель. Он должен быть максимально быстрым и минимально раздражительным. Ничто так не отстреливает клиентов как баги с контентом. Потому-то Vimeo не особо популярен.
4) Защита контента. Разумеется, твой контент попытаются спереть. Потому нужно сделать так, чтобы он был зашифрованным, а расшифровывался непосредственно на устройстве, притом не самым очевидным образом. То есть любая краденая копия со временем имела какие-нибудь проблемы, например оказывалась битой посередине, имела вставки того же самого фрагмента видео вместо замещённого, метки пиратства, и так далее. А это значит написание своего плеера — что не так-то просто. Либо идти на риски кражи — а они растут экспоненциально вместе с популярностью сервиса. В один момент ты обнаружишь всё это на торрентах или в чужой продаже.
5) Обёртки и оболочки — чтобы всё это пускать на разных устройствах. Сам функционал программ обычно минимальный и написан может быть на чём угодно. Лишь бы это «что угодно» не создавало конских требований к производительности и оперативке. Глупо считать, что если на твоём телефоне к примеру 2 гигабайта оперативки и 8-ядерный процессор, то у остальных то же самое. От тех же 2 гиг могут остаться какие-нить 50-100 Мб после уже существующего софта, да и за те придётся повоевать, а от 8 ядер даже 1 не раздуплится в результате «оптимизации» энергопотребления кривым софтом.

Пример: нужны ли тебе бэкапы? Правильный ответ — не нужны для тяжёлых данных. Проще рискнуть потерей видео, зато вложиться в качественное железо хранения, зато без RAID и прочего дерьма, которое несёт ещё и свои риски. Так ты получишь вероятность отказа 10+ лет без потери всех данных. Когда проект поднимется, купишь себе ленточный накопитель и просто регулярно заберёшь данные себе домой, им нечего делать в колокейшене. Потому что копии новых видео всегда есть у авторов, риск потери есть только для старых (от 2 месяцев).
А что бы ты получил в облаке? Обещание RAID в технопарке 1 уровня, на деле — дерьмовейшие Seagate в пыльном подвале.

И так по каждому вопросу. Ты должен обострять противоречия, и чем острее они будут, тем дешевле ситуативные решения и риск-менеджмент, и никаких закладок «на будущее», не подкреплённых риск-моделью.

И ни по одной части не допустимо MVP решение. Либо оно реально жизнеспособно, либо ты отдаёшь клиентов конкуренту прямо лояльными на блюдечке. Так что всё решается последовательно. Хочешь сократить сроки? Вот и подумай, как. IMHO никак. Свой видеохост = свои решения. То же самое кодирование видео: сжатие на лишних 2% более чем в 4 раза поднимает требования к производительности.

Если кратко: ты рано взял инвестиции. Инвестиции надо брать только тогда, когда у тебя есть готовые решения, которые можно ускорить или мультиплицировать вложением денег. Пример: что случится, если ожидания инвестора не оправдаются — не попросит ли он денег назад, заявив что ты сделал совсем не то, что ему обещал? Вернее не то, на что он сам раскатал губу, додумав хотелки задним числом, и требуя чтобы ты на себя взял все риски.

Деньги токсичны ровно потому, что не задают вопросов. Только зная ответы заранее, можно брать деньги. Если знаешь только 1 ответ из многих — возьми деньги ровно на 1 ответ. Если так не дают — напиши план, и бери деньги ровно в соответствии с планом. Так и ты, и инвестор, будут чётко видеть наступление рисков. И вместо одного общего провала будут видны малые проблемы, решаемые малой кровью. Когда инвестор видит, как идут дела — он по итогу даст тебе и больше времени, и больше денег, и поймёт когда (если) лучше не давать и «зафиксировать убытки». Либо же наоборот, увидит возможность и даст существенно больше, чтобы выстрелить.

спасибо за ответ, Алексей, все звучит очень логично. все же, исходя из твоего опыта, если опустить МВП фазу, взять срок разработки в год с бюджетом 200-250к$, какой стек оптимальнее всего?

Имея лимит в 250 килобаксов я бы искал гения в предметной области. То есть того человека, который может сделать именно самую важную часть продукта самой лучшей. А уже на то что останется от его найма — пусть бы он сам искал себе исполнителей. Грубо говоря, сделать «на троечку» все части софта, а самую главную — на «оху€ть дайте две!»

Стек — тот, который проще поддерживать. Я бы делал на Java, но потому что я знаю Java. Точно так же тебе будет каждый нахваливать то, что знает. А на деле — искать сходные проекты, в любом состоянии, на фриварных ресурсах, смотреть из чего сделаны, и оценивать разработку.

В общем случае для выстрела тебе нужны 2-3 человека всего. Первый — «гений», который сделает продукт прорывным. Второй — который фуллстек на любом стеке, и сможет собрать под него посредственные обёртки. Или двоих, если не найдётся фуллстек. Двух последних я бы нанимал удалённо, просто так дешевле. Недостаток удалёнщиков — они делают дольше, потому что работают не только на тебя, и даже если никого кроме тебя не взяли, за ними хвост доработок на уже знакомые им проекты, который они будут брать. Но тут работает правило «если вы подождёте чуточку дольше — мы обслужим вас чуточку лучше».

Почему так: продукт всё ещё стартап, и всё ещё может не выстрелить, когда окажется что клиенты не приносят прибыли, или быстро уходят, или перенасыщаются контентом, или же их тупо сложно-дорого привлекать. И никак это не проверить, пока ты не выйдешь на нужную часть «правила Парето», и не заимеешь фанатов. А для этого нужно именно выстреливать. Но выстреливать не по рынку (это очень дорого), а по ограниченной аудитории. И уже допилив на их активнейшем фидбеке продукт (за обслуживание фидбека берись сам, держи руку на пульсе) — будешь готов стрелять по рынку, или же по нерыночным нишам (читай партизанить).

Так что по сути — дели задачу на составляющие. И ничего страшного, если стек окажется зоопарком, особенно на бекенде. Хорошие проекты и есть зоопарк. Потому что вопреки сказкам бюрократов, люди все разные, и разным людям нужны по сути разные продукты.

PS. Где искать гения? А ты поищи продукты схожие (пусть и совсем на другие темы), которые загнулись просто потому что себя исчерпали (например, будучи бесплатными и экспериментальными по сути). И точно так же на их фидбеке сидели люди, которых фанаты пытались (с переменным успехом) прогнуть на доработки (но не сильно стремились донатить) — и среди них нередко были сами разрабы. Да, такой вот «секрет Полишинеля», настоящих исполнителей невозможно найти, не затрагивая «низовых» механизмов. В отличие от всяких ЛинкедИнов и ему подобных помоек, которые давно уж превратились в «рынок лимонов».

спасибо, Алексей, приму к сведению, много здравого смысла в твоих словах

А не проще взять LMS и допилить под ваши потребности? А потом, когда (если) будет большое количество пользователей — уже писать ТЗ на разработку.

сейчас так и есть, на готовых решениях все работает, пришло время делать свое.

видео делай свое в последнюю очередь если оно пока устаривает и работает .

да, пока вопрос именно в обертке для кастомеров и логика на бекенде. вимео по цене пока норм для меня.

Учитывая что нужно быстро. То возьмите разработчика или несколько на Ruby on Rails. Самый быстрый в плане разработки техстек.

Мне кажется главная деталь всего ТЗ — это

инвесторы хотят MVP через 3 месяца

Значит задача должна звучать так: «на каком стеке можно построить MVP за 3 месяца, размер команды = X, бюджет при этом =Y»

Попытки построить MVP, планируя какую-то серьезную нагрузку имхо premature optimisation. DAU 10k это же фантазия на данном этапе, без обид. Потому советую выбрать максимально дешевый/быстрый вариант, при котором вы сможете нормально разделить фронт и бек. Если проект дойдет до уровня, при котором вы упретесь в потолок возможности какой-то части стека (например бек) — тогда можно думать о том, чтобы переписать его.

спасибо за ответ.

«на каком стеке можно построить MVP за 3 месяца, размер команды = X, бюджет при этом =Y»

здесь вы чуть путаете причину и следствие. сначала я показываю инвесторам смету, скоуп и говорю: вот что будет в МВП, размер команды Х, бюджет нужен Y. и только после этого получаю бюджет Y. бюджет и размер команды это не константы) это неизвестные, которые выясним после того, как поймем на чем писать, чтобы потом не надо было переписывать. вот в чем моя логика. инвестор готов вкладывать в разработку до релиза, но через 3 месяца хочет увидеть результат (МВП), который я прикрепил в файле.

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

почему сразу не заложить то, что будет через год-два и потом не переписывать?

бюджет и размер команды это не константы

В любом случае срок в 3 месяца накладывает очень серьезные ограничения как на размер/качество команды, так и на выбор стека. Потому мне все-таки кажется рановато решать что-то насчет стека не зная даже бюджета.

почему сразу не заложить то, что будет через год-два и потом не переписывать?

Мой опыт говорит о том, что вы пытаетесь решить проблему, которой на данный момент нет. Заложить что-то на год-два в MVP противоречит самому понятию MVP. MVP за 3 месяца это попытка проверить фидбек юзеров на сделанный на коленке проект и попытка убедить инвестора вкладывать дальше.

Лично мой совет — сфокусироваться на том, где вы сможете найти (и удержать) спецов уровня мидл по незаоблачной цене, которые согласятся посмотреть в сторону 3-месячного проекта. Нужно принять за данность, что вы не знаете как будет выглядеть продукт через год-два. Потому решать проблему сколько там RPS выдержит бек ну оооочень рано.

понял, принял!
эксперты говорят, что за фикспрайс 25-30к готовы сделать МВП. в принципе, это то, на что я рассчитывал, просто изучив опыт други стартапов. в таком бюджете, что советуете по технологии?

Фронт. Лично у меня очень хороший опыт с Vue. Скорость разработки хороша, найти замену исполнителя будет несложно, а если переключиться на typescript, то откровенной дичи и багов в проекте будет меньше.
Бек. Наверное таки нода, может посмотреть в сторону готовых фреймворков, которые заточены под создание API (NestJS). Хотя мне кажется исполнители на подобном уровне будут стоить примерно одинаково: что PHP, что Python или Node.
Хранилище. Тут на вкус и цвет полно вариантов. Думаю наименее узкое место для такого проекта, можно не заморачиваться.

Используйте ту технологию в которой есть экспертиза. Многие успешные проекты вообще стартовали на LAMP, и со всех точек зрения ужасные PHP и MySQL позволили успешно стартонуть. Вполне возможно в лампе есть готовый солюшн в рамках какой нибудь CMS вроде joomla, drupal, wordpress и т.п. который вам надо будет только поднастроить и немного доработать 2. Планы у вас наполеоновские, вы пытаетесь скопировать Coursera для рунета это будет стоить очень прилично и нужна серьезная команда.

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

Ну ваши «конкурентные преимущества» с точки зрения тех. стека роли не имеют. Online платформа обучения от этого каким-то другим продуктом не становится. Упор «на мобилу» это вообще ваш личный «бздык», для того чтобы понять что нужно вашим пользователям в самом деле нужны UI/UX профессионалы которые проанализируют кто и как будет пользоваться платформой. Ну или хотя бы умыкнуть статистику у тоже курсеры. И в целом это только UI который прикручивается одинаково к любой технологии. В таких платформах большее значение имеет CDN и вообще все dev ops направление, интеграции с пеймент провайдерами и т.п. В общем это пустые разговоры пока, чтобы понять что и как, нужно делать анализ проекта — а это уже стоит денег само по себе ибо консалтинг.

Упор «на мобилу» это вообще ваш личный «бздык»

это не мой бздык, это статистика нескольких тысяч активных пользователей, которые сейчас пользуются продуктом, 75% смотрят курсы на мобильных)

о всех точек зрения ужасные PHP и MySQL

чем же они такие ужасные?
давай похоливарим :)

если на ноде сделать правильно — не прийдется переписывать много лет.
перед глазами стриминг платформа написанная 8 лет назад и основной функционал и реализация до сих пор работают в довольно приличном масштабе.
тут главное выбрать правильного человека который это напишет. тем более я так понимаю что уже концептуально все сложилось и ясно что и как должно работать со стороны бизнеса.

спасибо за ответ. да, вы правы, с точки зрения бизнеса я понимаю как это будет выглядеть в ближайшие 2 года так точно)) а о какой восьмилетней платформе вы говорите? скиньте ссылку пжлст

Node та react зараз дуже хайпують, буде важко знайти адекватний не захмарно дорогих співробітників, дивіться на Python.

или PHP — там можно найти кадры сильно дешевле

я бы сказал, что вопрос скорее не в цене разработки, а в том, насколько технология подходит к тому, что я задумал. в чем плюсы PHP?

А у вас уже были какие-то подводные камни, чтобы что-то могло не подойти на фоне аналогов? По-моему цена разработки — достойный критерий для выбора при отсутствии других

статью я написал именно с той целью, чтобы эксперты выразили свое мнение и объяснили, что стоит учитывать в разработке, какие преимущества одной технологии перед другой и что мне выбрать, чтобы избежать тех самых подводных камней, о которых вы говорите и при этом решить свои бизнес задачи.

если вы эксперт в php то я бы попросил вас написать так:
я предлагаю писать бек на пхп потому что 1 2 3
фронт на ... потому что 1 2 3
мобилку на ... потому что 1 2 3

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

спасибо за ответ. имеете ввиду python в плане бекенда или фронт тоже? а мобилки на чем?

Python наразі годиться для всього окрім мобільних, для Web UI це Django пітоновський фреймворк, для беку теж є ряд фреймворків або навіть чистий пайтон піде.

Для мобільних платформ наразі хз, з таким не стикався.
Тут можна, як на мене, піти двома шляхами:
1. Простіший — оптимізувати ваш майбутній сайт для мобільних платформ, різних екранів. Це дуже поширена практика і відносно не складна.
2. Складніший але теоретично більш потужніший і красивіший — Робити самостійно додатки для андроїда та айфонів на відповідно котліні та свіфті.

Якщо у вас немає інвестора який вже кинув хоча б мільйон баксів вам в лице, раджу йти по першому шляху і не розпорошувати сили.

дякую за відповідь, матиму на увазі

python только для бека. для мобилок выбор react native / flutter или пилить отдельно для iOS или Андроид. Я все же склоняюсь к тому стеку который вы указали в посте если вопрос не стоит в деньгах.

спасибо, а как думаете с точки зрения эффективности разработчиков, будет лучше чтобы и бек и фронт был js? скажем найти фулл стек js который сможет на ноде сделать бек и так же успешно UI, чем брать на бек питонщика, который только там сможет сидеть.

просто учитываю то, что это все таки стартап и гибкость наше всё, по крайней мере в первый год точно.

Сложно сказать на счет эффективности. Для экономии денег можно взять и full stack js чтобы пилил и бек и фронт. Но и качество кода может быть соответствующее. Какая то часть будет хромать или бек или фронт. Отличный вариант если стек будет один JS, но разработчики разные.

Можем помочь, обращайтесь.

Подписаться на комментарии