Зачем мы переписываем с нуля продукт, который работает и зарабатывает?

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

Немного предыстории. Проект sboard.online развивается с 2020 года как онлайн-доска для преподавателей. Команда сделала упор на узкоспециализированные функции для обучения техническим дисциплинам и на сегодняшний день являемся самыми популярными разработчиками онлайн-досок в России по количеству проведенных занятий (более миллиона занятий за 2022 год).

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

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

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

В продукте слишком много легаси. Дело в том, что на старте ребята взяли за основу опенсорсное решение, которое дорабатывалось outstaff командой разработчиков. Это позволило быстро выпустить продукт на рынок, провалидировать бизнес-гипотезы и привлечь инвестиции, но под текущие задачи это решение не очень подходит.

Изначально система была написана на чистом JavaScript без TypeScript. А это значит: код без статической типизации, больше требований к тестированию, выше вероятность ошибок при добавлении нового кода и менее безопасный код в результате. Да, можно придумать технику, чтобы вытеснить старый код и переписать на TypeScript, но это не спасет ситуацию, потому что дело не только в этом.

Идем дальше и смотрим, что у нас “под капотом”. Первая версия доски работала на svg. Это нормальный движок, только при масштабировании бизнеса начнет подводить. Чем больше функций мы добавим для пользователей, тем медленнее станет работать доска. Здесь мы приходим к решению, что svg нас не устраивает, а вот canvas — подходит. Этот движок позволит сохранить качество продукта при росте бизнеса.

Еще один фактор в пользу решения переписать код — время. С одной стороны, это время работы разработчиков, с другой — время выпуска новой версии продукта на рынок. По моей оценке, при расширении функционала доски мы бы слишком часто сталкивались с багами и в итоге потратили больше часов на их исправление, чем на разработку продукта с нуля под цели бизнеса.

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

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

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

Тем не менее, для нас аргументы “за” перевесили потенциальные риски и мы приняли решение рискнуть и начать разработку.

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

До рефакторинга мы выкатывали новую фичу раз в 2 недели, а после рефакторинга и смены архитектуры некоторые фичи добавляются за неделю.

Сейчас мы сделали первый релиз, понимая, что это закрытая бета и там неминуемо найдутся проблемы. Зато мы сможем понять, что нужно нашим пользователям в первую очередь, на что нам следует обратить внимание. Вы можете присоединиться к бета-тесту в телеграме https://t.me/sBoard_betabot

Определены 2 вектора работы по доске: повышение стабильности (мы покрываем код тестами, проводим рефакторинг для эффективности и скорости) и добавление новых фичей.

Спасибо, что дочитали статью до конца, надеюсь, было полезно! Расскажите в комментариях, был ли у вас опыт принятия подобных решений