Як ми за пів року створили конкурента Notion, і чого навчились в процесі

Привіт, я Віталій — СТО стартапу xTiles.app. Вже понад 7 років я займаюсь розробкою на Java, поступово приділяв увагу менеджменту, був Team та Tech Lead, наразі дійшов до рівня СТО.

Хочу розповісти історію створення продукту, який має серйозні амбіції та цікаву ідею. Звісно, заголовок виглядає клікбейтним, але попри зовсім різний рівень розробки, в цьому є своя правда, частково, бо наші користувачі кажуть, що xTiles порівняно з Notion є простим і гнучким інструментом.

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

Трохи про проєкт

Щоб зрозуміти, чи буде мій досвід релевантний, уточню, що xTiles.app — це стартап на ринку Productivity Tools, створений для користувачів, яким потрібна візуальна організація ідей та проєктів.

Головна ідея — вертикальний канвас, на якому можна створювати візуальні нотатки (тайли) та працювати з ними, розвиваючи свій задум. Ця ніша поки що не має точної назви, тож Tool for thoughts або Second Brain, Personal Place of Truth — це ті вирази, які найчастіше використовуються для опису подібних інструментів.

Власне, сам ринок з’явився як запит аудиторії на гібридні гнучкі тули, які б допомагали айтівцям та й взагалі будь-кому в різних процесах: writing, brainstorming, research тощо.

Останнім часом з’явилось досить багато подібних продуктів, їх відрізняє намагання скомбінувати в собі фічі з декількох інструментів, як-от, наприклад, Notion комбінує документи й таблиці, Roam Research та Obsidian — графіки та нотатки, Milanote — дошку та картки. xTiles має функції як Notion, так і MIRO, хоча жоден з наведених інструментів не може повністю замінити інший.

Коли потрібно швидко починати працювати над проєктом

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

Тож ми з командою почали працювати. Ми розуміли, що все треба робити швидко, бо ідея, ще й на такому конкурентному сегменті ринку може не злетіти, час грає проти нас і нам якомога швидше потрібно її перевірити.

З іншого боку, якщо ідея підтвердиться, то потрібно продовжувати розвиток продукту, і було б непогано, якщо наш прототип стане гарною основою для майбутнього продукту.

Технологічний стек — обирати, спираючись на свій досвід

Вибір технологій — це завжди компроміси. З одного боку розробники хочуть спробувати нові технології, з іншої — бізнес, і у нього зовсім інші пріоритети.

У випадку, коли важлива швидкість, то для максимально швидкої реалізації спочатку POC і надалі вже чогось більш фундаментального потрібно брати перевірені технології, в яких учасники мають достатньо досвіду, і які дозволять команді з легкістю масштабувати функціонал.

Опишу наш приклад і досвід. Попередні кілька років для веброзробки наших проєктів ми використовували React, стейт-менеджером — mobX, та писали на Typescript. І ця комбінація нам подобається, тож вирішили їй не зраджувати.

Що стосується бекенду, то раніше ми переважно мали справу з JVM мовами програмування: це була і чиста java, потім groovy, знову java. Десь з 2020 року почали використовувати kotlin. І майже завжди це був spring-boot.

Тож, маючи такий досвід, вибір технологій був для нас очевидним: для web-клієнта ми взяли React + mobx. І оскільки одним з важливих побажань було швидке перше завантаження сторінки, то ми вирішили спробувати SSR з використанням nextJS.

Для серверної частини взяли kotlin + spring-boot (webflux).

Тут можна ще багато писати про архітектуру, про вибір баз даних, про процес CI/CD. Але думаю, що краще я напишу про це окрему технічну статтю, де буде доречним розкрити ці питання :)

Особливості роботи з текстовим редактором та фічі, які викликали найбільші складнощі в розробці

Одним з основних елементів нашої системи є текстовий редактор. Робота в ньому постійно повʼязана з вводом тексту, вставкою з інших джерел, його форматуванням та створенням нових блоків. І якщо кожен крок буде якось уповільнювати роботу користувача чи створювати перепони для процесу взаємодії з продуктом — це створить відчуття дискомфорту і небажання продовжувати взаємодіяти з ним.

Під текстовим редактором я маю на увазі не тільки компонент редактору на UI. Це і система керування виділенням тексту та блоків, їх створення, вставка та парсинг даних з інших джерел, розпізнавання медіаконтенту, імплементація гарячих клавіш, історія змін контенту для реалізації ctrl+z, принцип збереження даних на сервері. Комплекс цих функціональностей дає можливість користувачу не відчувати дискомфорту в роботі з сервісом, а концентруватись тільки на своєму робочому процесі.

Нам потрібно, щоб користувачі мали змогу редагувати документ одночасно та бачили зміни один одного. З першого погляду здається, що потрібно просто використати вебсокети. Але цього не достатньо: потрібно ще вирішувати багато пов’язаних питань, таких як масштабування вебсокетів, блокування окремих частин контенту, де працює користувач, або робити систему вирішення конфліктів, якщо дозволяти їм редагувати контент в рамках одного блоку.

Потрібно ще забезпечити механізм актуалізації контенту у випадках втрати підключення до сокету, а це трапляється досить часто.

Як вдалося майже не рефакторити й швидко просуватись у розробці

Щоб отримати гарний темп розробки, потрібно декілька складових частин. По-перше, потрібно добре розуміти, що саме ми хочемо отримати і коли. Які саме фічі потрібно буде зробити, який буде їх UI/UX.

По-друге — це мотивована і злагоджена команда, яка заряджена на кінцевий результат. У нас був план на пів року вперед. Хоча він і був складений дуже «широкими мазками», але його було достатньо, щоб мати можливість робити прототипи, проводити кастдеви та оформлювати у вигляді майже готової документації для розробки.

Допомагало і те, що розробники дуже тісно працювали з бізнес-командою, брали участь у спрощенні функціональних моментів, щоб раціонально витрачати час на їх реалізацію.

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

Пошук клієнтів навіть під час війни

Непростим для нас видався пошук продакт-маркет фіта. Ми отримали перші відгуки вже за два місяці після початку розробки. Вони були непоганими, але користувачі видавали досить довгі переліки фіч і недоліків, які треба було зробити або ж пофіксити, щоб вони почали користуватись нашим продуктом на постійній основі.

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

Заявити про себе на ширшу аудиторію та почати залучати більше користувачів ми були готові практично вже в кінці 2021 року, тобто, через пів року роботи. Єдиним слабким місцем залишався дизайн, концепція якого за ці місяці розробки встигла морально застаріти, чи, можливо, ми стали інакше дивитись на наш продукт. Мабуть, це вже філософське питання, але в будь-якому випадку ми вирішили його оновити, бо він вже нікому з нас не подобався :)

Старт масової кампанії був призначений на 23 лютого 2022 року. А наступного дня, наче страшний сон, розпочалася повномасштабна війна. За наступні 3 дні ми пережили стадії шоку, усвідомлення та прийняття ситуації, яка є в Україні.

На наступний місяць ми забули про продукт і про запуск, почали шукати можливість допомагати ЗСУ та силам Тероборони. Ми самі знаходимось у місті Кременчук Полтавської області, тож шукали житло для тимчасово переміщених людей з більш небезпечних територій, допомагали продуктами й теплим одягом настільки, наскільки була можливість це робити. Робили коктейлі, протитанкові барикади, шукали дрони та ліки...

Поки ми були зайняті цим, наш слак-бот працював і розсилав повідомлення у слак-тіми, де ми розраховували знайти свою аудиторію. Десь через місяць ми почали повертатись до довоєнної роботи, і були приємно здивовані, у нас зʼявились користувачі, які активно щось роблять у нашому сервісі. Так, їх було тоді не багато, але вони були.

Ми розпочали новий етап комунікації з ними, повернулись до кастдевів. Це, своєю чергою, допомогло в формуванні чіткого плану на наступний період розвитку продукту. Тож рухаємось далі.





Проміжні висновки та рух далі

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

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

Мої поради тим, для кого реальною є схожа робоча ситуація:

  • беріть перевірені технології;
  • з’ясовуйте ТЗ максимально детально;
  • поцікавтесь, яким може бути розвиток продукту;
  • не збирайте велику команду, краще беріть перевірених людей;
  • плануйте стратегічно на місяць-два наперед.

До речі, коли ми починали, то найбільше в оцінці продукту боялися порівняння з Notion, який є взірцем на цьому ринку, дійсно крутий продукт як в технічному плані, так і за ідеологією. І от коли з’явилися користувачі, які сказали, що для них Notion це складно, а xTiles — просто, але достатньо гнучко, я відчув, що ми робимо все правильно. Звісно, в нас поки небагато користувачів, але й нам усього рік.

Виявляється, з монстрами ринку можна конкурувати, і навіть робити це в непростих українських реаліях. Хочу, щоб ми всі про це знали і пам’ятали.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному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

Дякую за статтю!
— Можете більше розповісти про то як знаходили перших клієнтів? Що саме ви через слак бота розсилати? В які саме канали?
— Скільки вас в команді і хто які ролі виконує? знайшов
— І ще бачу вас захантила на РН доволі популярна людина, як це робиться якщо не секрет? :)

Кліпчик прикольний. Чи є вже перші платні користувачі? Я так розумію ви бутстрапили? Скільки людей в команді? Які плани по мрр? Яка most requested feature so far?

Є платні користувачі. Так це бутстрап. По MRR — зростати якнайшвидше))

Окремі фічі не мають значення, має значення завершений вокрфлоу для користувача

Спільне питання до цього та йому подібних продуктів: а як працює Garbage Collector? Тобто, вони просто гарнюні, коли справа йде про маленький проектик, чи його частинку. Але колі інформації дійсно багато, вона разносортна, важко піддається систематизації та тим більше пошуку, і все це тоне у часі під тиском вже нових справ — що відбувається із накопиченим хламом?
Звісно, це питання не має єдиного рішення у психології. Але коли ми кажемо вже про Second Brain концепцію, то власне цей алгоритм і є фундаментальна цінність продукту (або ж її відсутність). То як саме працює продукт при збільшенні часу та кількості, яке маємо «Big O» для його алгоритмів?

Спробую пояснити: продуктом досить легко зацікавити людей, які нічого подібного раніше не робили в той чи інший спосіб, або ж не придавали значення тому, як це звикли робити. Для тих, хто має постійно проблему [нібито] вирішувану продуктом — ви конкуруватимете насамперед із вже побудованими звичками, наймовірніше із застосованням якогось софту. Це найтяжча конкуренція, тому для її виграшу треба пропонувати або щось дуже революційне [і власне тестити це на людях], або ж щось незаслужено забуте старе перевірене.

Гарне запитання

Так змінити звички користувачів — дуже складно і це довгий шлях. Тож ми намагались зібрати гарні UX рішення з різних інструментів та дати користувачи ніби звичні речі, але в незвичному поєднанні. Об’єднавши механіки нотаток, вайтбоардів, майндмепів, та навіть трохи спредшітс, ми дали комбінацію про яку користвачі кажуть всього три важливих слова: simple, visual та flexible. Вони кажуть що освоєння сервісу не є проблемою, особливо порівнюючи з Roam Research, Obsidian та навіть Notion. Це додає нам впевненості, що ми на вірному шляху.

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

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

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