Від розробника до фаундера. Як я повернувся в IT після першого невдалого стартапу та наважився створити новий

Які технології

Java MySQL Spring

Так вийшло, що з часів студентських років я потрапив у світ Java. Тому коли постало питання стеку, не побачив причин змінювати на NodeJS чи Go. Десь я бачив аргументи в стилі, що у Java Spring імена класів дуже довгі і BeanPostProcessors вже всіх «задовбали». Але як можна взагалі таке брати до уваги? «У NodeJS Express легше створити Rest API». Чи ті люди мали досвід з Spring Boot RestController? Щодо того, що у Go «Threads management простіший», а код можна написати тільки одним способом. Ну по-перше, це просто досвід, бажано необхідний для обох мов. А по-друге — я вже згодом писав на Go і це твердження хибне.

Я ще довго вагався, бо не дуже полюбляю SpringDataJPA, але коли побачив, що є SpringDataJDBC, все стало на свої місця. Мене повністю влаштовує відсутність «автоматичного» кешу і до вподоби custom SQL на пів екрану в коді, де я можу в будь-який момент підправити те, що мені потрібно.

Dart Flutter

З Flutter також не було «особливо вибору», оскільки Dart для мене дуже схожий на Java. А принцип побудови інтерфейсу Layouts майже ідентичний до Java Swing , з яким у мене також був немалий досвід. Коли постало питання вибору, Google ще не звільняв людей з Flutter-направлення, community дуже добре розвивалось, все виглядало перспективно. Тоді писали, що React Native трохи відстає за Performance, але я не перевіряв. Згодом знову писали, що вже навпаки (не дивно). Але я б і не сказав, що така конкуренція — це щось нездорове. Швидше зворотнє, адже змушує обидві технології розвиватись. Загалом мова Dart дуже полюбилась і хотілось би, щоб Java рухалась в цьому напрямі (Kotlin не пробував).

AWS

З Cloud Provider обрав той самий шлях найменшого супротиву. До війни я дуже активно готувався на сертифікацію AWS Certified Solutions Architect і вже обирав день екзамену, аж раптом о шостій ранку пролунав дзвінок першої повітряної тривоги. Сертифікацію довелось відкласти назавжди, а AWS виявився в нагоді. Із дуже важливих факторів — 12 місяців Free Tier, а також отримав лист «AWS Ukraine» з пропозицією в додаткових $300 на розвиток стартапу. Форма була дуже проста і я вирішив to give it a try. І таки так — все було, як обіцяли.

Чому так довго

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

1. Flutter State management

Якщо коротко, State Management довелось переписувати три рази. Найімовірніше, ця проблема не мала б бути чимось дивним для Senior Mobile-розробників. Я ж явно недооцінював перспективу. Тобто при натисканні кнопки, наприклад, мав би перемальовуватись тільки відповідний елемент замість всього components tree. Але останнє мене зовсім не хвилювало. Аж доки я не помітив, що такий процес тягне за собою всі server api, дані яких необхідні для віджетів. Негативний вплив на performance дуже серйозний і було очевидно, що довго такий сервіс не протягнув би.

2. Синхронізація дій користувача / UX

І це також, мабуть, стосується відсутності досвіду розробки під Mobile. Але тут на противагу це вже стосувалось б прямого враження користувача про застосунок. Проблема полягає в тому, що користувач може здійснити декілька дій одночасно. Перша з яких може закінчитись неуспішно. В результаті ми матимемо неочікувану поведінку на екрані мобільного застосунку та inconsistent state в базі даних. Тобто ситуацію, яка б не мала трапитись. Наприклад, користувач двічі натискає «здійснити замовлення», а потім ще й кнопку «назад».

3. Адмінка

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

4. OTP login

Використання FirebaseAuth реалізувалось за години, але головної болі згодом було дуже багато. Процес Captcha здійснює декілька редіректів і працює не з першого разу. Загалом я розумію, чому цей алгоритм такий, і що відбувається, але по факту це перше враження користувача про застосунок. І навіть коли все працювало ок, я чув відгуки від друзів, що «застосунок глючний». І це було дуже сумно, адже до фактичного функціоналу люди так і не доходили.

Якось сервіс взагалі перестав працювати на місяць в Україні, і Google Support «офіційно» заявили, що нам (розробникам) потрібно розглянути інші варіанти. В результаті так і відбулось, і все переробилось на AWS Lambda. Це дуже дорого в порівнянні з «безплатним» FirebaseAuth, але я подумав, що «перше враження» важливіше.

5. Реєстрація на Google Play і Apple Store

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

6. Оплата карткою

У мене був досвід старту проектів з нуля (переважно він тільки такий і був). Коли отримував документацію на розробку, перше, на що я звертав увагу — залежність від інших сервісів, тобто 3rd integration. З цим завжди були проблеми. Будучи Team Lead, в таких випадках я передавав «звичайну» розробку команді. А з замовником ініціював процес інтеграції на максимально ранній стадії, щоб запевнитись: «це працює» до того, як «все готово», а інтеграція не виходить або неможлива. Бувало, клієнти, часто необізнані в цій сфері, піддавались впливу Sales Team компаній, які продавали щось взагалі не те, що там мало б бути. Як результат очікування — реліз, а в реальності — провал.

В Україні дуже багато платіжних систем. В моєму випадку проблематика це:

• таке враження, що вони підлаштовані під інтернет-магазини, тому API не таке як потрібно, а ще відсутній необхідний SDK.
• ситуація ще більш ускладнилась, оскільки використовувати Native SDK дуже не хотілось, адже це виглядало потенційною чорною дірою у time consuming.

Сумарно процес триває вже дев’ять місяців. На початку літа вдалось домовитись про розробку і інтеграцію FlutterSDK. Серед усіх фіч вона забрала найбільше часу на тестування і мала найбільше багів. Довелось дуже багато переписувати Order Flow і очікується, що протягом найближчих місяця-двох ця фіча все ж буде доступна у prod.

Що найважче

Спочатку я думав зазначити тут слово дисципліна, але це не зовсім так. Адже вона передбачає планування, графік і якісь зусилля для відповідності йому. Під час війни це неможливо: світло, тривоги, новини. Але є ще і побутові ситуації, які також легко можуть витягнути з контексту. А вмикатись назад нелегко. Необхідно постійно адаптуватись під обставини, тобто йдеться про напругу 24/7 . З цим потрібно навчитись жити.

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

Нести відповідальність і думати одразу за три частини загальної системи: Mobile, UX і сервер. Flow можна змінювати як на етапі дизайну, так і на етапі розробки, коли щось не дуже ок лягає. Таким чином все може трансформуватись on the go, але фічу вдається зробити за день-два одразу, а не за місяць. Сам час розробки був би приблизно однаковий, але справа в тому, що треба звільнити мозок і сфокусуватись на наступних задачах. І здавалось би, так — в певній мірі це прискорює розробку, але самопочуття після такої роботи — максимальна виснаженість.

Що далі

Стосовно функціоналу найближчим часом планується ще дві основні фічі:

• відгуки на заклади і сортування за рейтингом (зараз тільки за віддаленістю);
• можливість редагування замовлення після його розміщення. Тут флоу ще взагалі не продуманий, але з відгуків конкурентів це має бути актуальним.

Далі вебверсія застосунку плюс SEO, що також дозволить зробити сервіс популярнішим, наскільки це можливо. Тому крім Flutter доведеться вчити ще React, але мені не звикати. Тут одразу win-win: це передостаннє в todo list, в чому було бажання розібратись. А також це може бути основою, якщо Google продовжить свій journey халатного ставлення до Flutter і доведеться переходити на React Native.

---

Всім дякую за увагу.

Якщо у когось будуть запитання — радий відповісти, і, звичайно буду дуже вдячний за будь-які відгуки до застосунку.

Cайт та Instagram проєкту, а також мій LinkedIn.