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

Привіт, спільното!

Мене звуть Роман. Маю багато років досвіду як розробник та Team Lead. Робив навіть спроби створити власну аутсорс/аутстаф-компанію, як і стартап, але через перші помилки та несприятливі обставини все пішло не так, як хотілось.

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

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

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

Я вирішив поставитись до задачі максимально серйозно: розділив знання на категорії та агрегував все, що знав, у документи.

aws

Перше, що мене трохи «заспокоїло» — це те, що все знати і пам’ятати неможливо. Друге — мені простіше показати та виконати завдання, ніж пояснювати і говорити. Я почав акцентуватись на вакансіях, де передбачались тестові, та виконував їх максимально якісно.

В деяких моментах були питання, які просто потребували відсутнього у мене досвіду (hands on) у розв’язанні тих чи інших архітектурних задач, де від кандата очікувалось здійснення міграції чи рефакторинг (тут все ок). На жаль, були і питання, неактуальні в реальній роботі; іноді — нерозуміння співбесідником глибини того, що він сам запитує. А також були випадки, коли просто була думка інтерв’юера і неправильна.

Що таке Supo

Загалом хотів з вами поділитись історією про новий стартап, який я розробляю вже декілька років. Він починався, як Pet-проєкт для навчання. Сфера — кур’єрська доставка страв та напоїв із закладів харчування на кшталт двох конкурентів (іспанського та естонського), що наразі панують в Україні.

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

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

Наразі мобільна версія містить одночасно три акаунти, які користувач може змінити в будь-який момент: клієнт, бізнес та кур’єр. Щоб приймати замовлення чи доставляти їх, необхідно пройти процес реєстрації та модерації службою підтримки:




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

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.

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

Щоб зробити успішний стартап треба працювати 24×7 скільки потрібно, я вже працюю 1 рік і 5 місяців, вірити в успіх, не відступати і не здаватись, не опускати руки, просто працювати, якщо потрібно навчатися, не звертати уваги на коментарі й відношення друзів, родичів і таких інших. Бути не задоволеним своїм життям, яким би гарним воно не виглядало, велика квартира, крута машина, будинок у селі и т.і. Тоді, мабуть у майбутньому прийде успіх.

Радий чути що при таких тяжких обставинах все ж знаходяться люди які щось будують.
Бажаю дійти до мети!

Радий чути що при таких тяжких обставинах все ж знаходяться люди які щось будують.
Бажаю дійти до мети!

Дякую що поділився, цікавий досвід!
Чому не зробити вебверсію на Flutter? виглядає легше ніж вчити реакт.

Хай щастить з проектом!

Дуже дякую!

У Flutter проблема із SEO, а із оптимального варіанту виходить React + NextJS
docs.flutter.dev/...​h-engine-optimization-seo

Це так, але навіщо тобі SEO для самого додатку?
Роби SEO на лендінг і все, а з нього перекидуй на вебверсію додатку

Спробую розглянути цей варіант.
Дуже дякую за пораду!

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

Справді була така проблема і так це дуже важко, але не було вибору так як була необхідність за щось жити.
Я ще намагався пробувати продвигати «старий» стартап, але якось під час презентації в Домінікані дуже багатій людині почув питання чи можу я зробити сайт з лотереї. Я розчарувався але погодився, але і до справи не дійшло.

З нетерпінням чекаю текст через рік

мені простіше показати та виконати завдання, ніж пояснювати і говорити.
Маю багато років досвіду як розробник та Team Lead.

Серйозний досвід ліда=)

Таки серйозний. Але що вам пояснювати. Далі сподіваюсь здогадуєтесь.

Не уявляю, як можна зараз влізти і втриматись на цьому ринку доставки, маючи в конкурентах таких ’китів’ як Глово і БФ.
Ну і про технічні деталі розробки прочитати було цікаво, але ж там ще є цілий айсберг організації процесу: потрібні брендовані термосумки для кур’єрів, а тоді мабуть і якась фізична точка де їх можна отримати, обміняти чи здати, пункт повернення для скасованих замовлень(якщо працювати по схемі Глово), а ще техпідтримка для проблем кур’єрів, закладів та користувачів — навіть якщо ви і починаєте з 1 міста, чи це посильна задача для команди, яка ’налічує лише декілька співробітників’?

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

З службами таксі, на мою думку, трохи інша ситуація, на прикладі Львова(можливо, у Вінниці і по-іншому):
1/ Убер в свій час заходив на ринок, на якому конкурентів фактично не було
2/ Уклон і Болт заходили на все ще зростаючий ринок, коли і потенційних клієнтів було значно більше, ніж вільних машин того ж Убера, так і грошей на таксі в них теж було не до порівняння більше, ніж зараз
Убер, до речі, в Львові повністю програв в подальшому ринок 2 вищезгаданим
3/ Служби таксі, які залишились — це ті одиниці, які були до приходу агрегаторів і зуміли адаптуватись або доживають на старому багажі, напр. у нас залишилась служба 838, в них і додаток з’явився, але якщо вони і виживають, то виключно на людях, які так і не спромоглися опанувати додаток, і як звикли ще 20 років тому викликати по телефону, так роблять це і зараз
4/ Ще важливий нюаснс, який залишає ті жалюгідні відсотки ринку після Болта та Уклона — що можна працювати на кілька служб одночасно, і коли на виклик в Уклоні приїжджає авто марковане 838 рекламою — це далеко не поодинокий випадок. З кур’єрами це так просто не працює
5/ В службі таксі 2 контрагенти, тобто проблема або на одній стороні, або на іншій. Тут же 3, а значить вас чекає в рази більше самих кейсів до опрацювання — від прорахування всіх можливих варіантів дій до власне їх ’хендлювання’
Тому тут буде в рази важче. Uber Eats не витримали, Ракета не витримали (з дуже печальними наслідками у вигляді мільйонного боргу).

Тут же аби аудиторії сподобався додаток і ним користувались

Для цього повинен бути
— великий список закладів, щоб було з чого вибирати,
— достатньо кур’єрів, щоб очікування і час доставки не відбивало в принципі бажання щось замовляти,
— достатньо замовлень для самих кур’єрів, щоб був сенс підписуватись на таку роботу.
Знову ж таки, продовжуючи аналогію з таксі, я зараз в Львові Убером взагалі не бачу сенсу користуватись, бо якщо У/Б авто буде в межах 3-6 хв, то Убер десь максимально далеко, в межах 10-15 хв, якщо буде взагалі, а це скоріш за все тільки тому, що в чуваків по кілька смартфонів на різні служби, що з кур’єрами малоймовірно.

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

Проблема великих компаній в тому що їм є що втрачати. А у нас реальність така що повітряна тривога по 16 годин поспіль. Відчай, дуже не комфортний і безжальний.
Друге це те що у компаній розробку ведуть розробники, а гроші дають інвестори. Інших суттєвих витрат я не бачу.
3. Вони знаходяться на «чужому» ринку і «проблема» тут тільки знову через війну. Я маю на увазі мотивацію для українців у вигляді робочих місць, технологій, податків та «повернених» інвестицій.
(до прикладу Нової Пошти, яка таке враження що останнім часом з «ланцюгу зірвалась» — тут максимально в доброму та хорошому сенсі, мова про їх власні розробки, технології, винаходи, соціальні ініціативи і допомоги)

Результат неминучий.
Але навіть якщо не так (не за мету чинити супротив). Я просто не впевнений чи це проблема.
Маю на увазі отриманий досвід який «під рукою». Будь яка інша розробка не займе довше місяця. Тут просто побачити що потрібно.

Нарешті щось корисне — а то або про тцк або геймерське ниття або пм з поштової компанії

Цікава стаття 👍🏻👍🏻🔥

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