ТОВ Літа Хелз: медицина, профілактика, онкологія

Ми розкажемо, як будувався стартап - не тільки програмна частина. Обговоримо тонкощі та нюанси створення MVP без великих інвестицій, особливості організації процесів, тонкощі у виході на ринок, особливості проєктування та прототипування, тестування попиту, отримання дозволів на платіжки. ТОВ Літа Хелз - це медична софтверна компанія, партнер компанії Ingello Systems. Наш архітектор і наша бізнес-аналітик є співзасновниками та бенефіціарами цієї компанії, допомагаючи розробляти медичний софт, а також будувати саму компанію з нуля. Для розвитку компанії проєктувалася не тільки системна, а й ентерпрайз архітектура. Комплексно: від бізнес-структури, продуктової моделі до архітектури рішення, системної архітектури та контролю процесу розробки застосунків, баз даних і програмних інтерфейсів. Від моделі управління людьми та процесами до глибоких технологічних рішень. Історія цієї компанії пишеться і донині вже кілька років.

У загальних рисах про проєкт

Усі ми хочемо почуватися бадьорими та здоровими в будь-якому віці. Lita Health задумувалася як компанія-розробник застосунку та системи управління для комплексної профілактики: як продукт для сімей, який контролює графіки вакцинації, нагадує про планові візити, надсилає сповіщення, допомагає виявляти складні захворювання, зокрема онкологічні, на ранніх стадіях і прогнозує ризики.

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

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

Ось так виглядала предметна область: це схема всього лише одного сценарного потоку для жіночої онкології. Повний пайплайн навіть не помістився на скриншот. А таких схем було багато.

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

Рішення

Конструктор тестів з онкології та інших категорій

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

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

Чернова модель із розшифровкою виглядала приблизно так:

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

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

Це дозволило вносити тексти, задавати зв'язки з контекстами та типами віджетів. Різні питання вимагали різного способу введення з боку пацієнта, і це теж можна було задавати через конструктор. По суті, це нагадувало створення форм у Google Forms, тільки в Google Forms немає контекстуальних графів, які дозволяють змінювати питання залежно від відповідей, запам'ятовувати стани та запускати алгоритми визначення ризиків.

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

React-застосунок

Архітектура — це прийняття ключових рішень. Тому було прийнято рішення спочатку створювати веб-версію застосунку, а потім адаптувати її під різні платформи: iOS, Android і desktop. Це універсальний підхід, цінність якого давно зрозуміла багатьом. Спочатку запускається браузерний застосунок, а вже потім з'являються окремі клієнти під конкретні платформи.

Стратегія була приблизно такою: робимо браузерний застосунок, використовуємо підхід mobile first, запускаємося одразу на всіх пристроях, тестуємо без публікації в сторах, збираємо фідбек, а потім за потреби робимо обгортку через WebView або навіть PWA (прогресивний веб-застосунок, який можна встановити на пристрій).

Для фронтенду ми обрали React, тому що він добре підходив для наших завдань і дозволяв будувати плавний, живий інтерфейс. Для забезпечення застосунку даними на бекенді було створено API, документоване через Swagger / OpenAPI.

У результаті застосунок мав видавати пацієнту приблизно такий екран із результатами та планом подальших дій:

Екрани питань і поліморфізм

На старті пацієнта зустрічало анімоване інтерактивне коло, яке буквально запрошувало почати опитування. Ми зробили легку, мінімалістичну, але привабливу анімацію — пульсуюче коло, на яке прямо хочеться натиснути =)

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

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

Інтеграція платіжних систем

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

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

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

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

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

Сайт і лендинг

Так у нас з'явився повноцінний сайт-лендинг. Сайт був і раніше, але він радше грав роль презентації, ніж повноцінного корпоративного об'єкта. Його довелося серйозно переробити: оптимізувати, доповнити інформацією, зробити більш прозорим для держави, банків і платіжних комісій.

Крім того, з урахуванням планів на акселераційні програми та пошук інвестицій у маркетинг, ми одразу зробили й англійську версію сайту. У підсумку в проєкту з'явилося дві основні мовні версії: українська та англійська.

Виклики та проблеми

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

Учасники команди та партнери-співзасновники

Одна з перших і найбільш недооцінених проблем полягала у складі команди. У проєкті були сильні та розумні люди, але з дуже різним досвідом. Хтось добре розумів медицину і лікарську практику, хтось був ближче до аналітики, хтось — до бізнесової частини. Але практичного досвіду побудови IT-продуктів рівня стартапу або enterprise-системи по суті ні в кого не було.

Через це не існувало єдиного способу розподілу обов'язків. Учасники дивилися на проєкт із різних сторін, говорили різними професійними мовами і по-різному уявляли собі пріоритети. Для медичного стартапу це особливо небезпечно: продукт уже виглядає розумним, а внутрішня управлінська кухня ще не оформлена.

З точки зору enterprise-архітектури ми прийняли рішення почати не з приватних завдань, а з найзагальнішої картини. Спочатку був вибудуваний принцип робочого циклу, розподілені ролі та окреслені зони відповідальності. Ми зібрали наскрізний контур: від бізнес-аналізу, збору даних і проєктування до презентації гіпотез, утримання та залучення цільової аудиторії, аналізу конкурентів, аналізу продукту і повернення зворотного зв'язку назад у цикл. По суті, усе було замкнуто на постійній аналітиці, а не на спонтанних думках.

Амбітні глобальні плани

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

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

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

ТОВ, оргструктура, ролі

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

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

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

Відсутність достатнього бюджету

Ключова проблема була дуже земною: у проєкту не було достатнього бюджету. А це автоматично означає, що кожне рішення стає не просто технічним, а майже філософським. Що робити в першу чергу? У що вкладатися? Наскільки глибоко йти в розробку до перших підтверджень від ринку?

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

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

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

Цілі, план-факти

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

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

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

Робочі цикли та конвеєр взаємодії

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

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

Також були продумані послідовні цілі. Що за чим іде, як розподіляється в часі, яке завдання є умовою для наступного. Наприклад: почати розробку прототипу, щоб формалізувати цільову аудиторію і проблему; потім визначити ролі учасників і робочий цикл; потім провести опитування аудиторії та тримати з нею контакт; потім погодити й затвердити функціональність MVP; потім розробити прототип; потім провалідовувати його й отримати або готовність купити, або якісну критику. Суть була в тому, що цілі ставали пов’язаними, послідовними і, найголовніше, вимірюваними.

Зміни в команді

Команда в ході проєкту змінювалася. Хтось ішов, хтось приходив, у когось змінювалася роль, а разом із цим змінювався і контекст. Для складного продукту це завжди ризик: знання легко залишаються в головах конкретних людей, а не в системі.

Саме тому нам доводилося паралельно зміцнювати документацію, оновлювати ролі, синхронізувати очікування й фіксувати рішення. У таких проєктах кадрові зміни — це не просто HR-питання. Це питання стійкості архітектури, процесів і колективної пам’яті.

Бізнес-вимоги, ТЗ, аналітика

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

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

Дизайн, візуалізація, зміни

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

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

Проєктування архітектури застосунку та сервера

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

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

Аналіз і програмне впровадження схеми жіночої онкології

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

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

Мінімалізм — прибрати все зайве

Ще один важливий виклик — мінімалізм. Коли проєкт амбітний, дуже хочеться додати ще один екран, ще одну підказку, ще одну роль, ще одну функцію. Але саме так MVP швидко перетворюється на непідйомний комбайн.

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

Безпека та анонімізація користувачів

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

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

Розробка бази даних та адміністративних екранів

База даних мала зберігати не просто користувачів і відповіді. Їй потрібно було утримувати значно складнішу логіку: протоколи, розгалуження, контексти, типи питань, історію відповідей, обчислювані стани, результати, адміністративні сутності та пов’язаний сервісний шар.

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

Розробка застосунку

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

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

Розробка серверного API

Серверне API стало зв’язувальним хребтом системи. Воно мало бути достатньо строгим, щоб фронтенд і адмінка працювали передбачувано, і достатньо гнучким, щоб не ламатися при розширенні моделі.

Ми документували API через OpenAPI / Swagger, щоб контракт між клієнтською і серверною частиною був прозорим. Це особливо важливо в проєктах, де одночасно розвиваються інтерфейс, логіка, аналітика й адміністративний шар.

Юридичні питання та обробка даних

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

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

Проблеми з платіжними системами

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

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

Моделювання портрета клієнта та запуск реклами

Паралельно з розробкою потрібно було формалізувати, хто саме наш клієнт. Хто ухвалює рішення? Хто відчуває проблему? Хто платить? Хто користується? Це не завжди одна й та сама людина. У медицині особливо часто виходить так, що користувач, платник та ініціатор — три різні сутності.

Тому ми моделювали портрет клієнта, тестували повідомлення, запускали рекламу, дивилися, на що відгукується аудиторія, і намагалися не вигадувати ринок у голові. Хороший стартап зростає не з фантазії про клієнта, а з повторюваного контакту з реальними людьми.

Перші користувачі та проходження

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

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

Гарвардський хакатон і Lita Doctor

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

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

Перші продажі

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

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

Технології

Технологічний стек проєкту ми підбирали не за принципом модності, а за принципом здорового глузду. Інтерфейс застосунку будувався на React — це бібліотека для реактивних інтерфейсів, тобто таких екранів, які швидко й плавно змінюються у відповідь на дії користувача. Як основу веб-частини використовувалися звичні й надійні HTML, CSS і JavaScript: перша технологія відповідає за структуру сторінки, друга — за зовнішній вигляд, третя — за логіку в браузері.

На серверній стороні ми використовували PHP як основну мову веброзробки, а дані зберігали в MySQL — реляційній базі даних, де інформація живе в таблицях і зв’язках між ними. Усе це розгорталося на Linux — надійній серверній операційній системі, а вебзапити обслуговував Nginx, один із найпродуктивніших серверів і проксі у світі. Для автоматизації інфраструктурних завдань застосовувався Bash, а для контейнеризації та передбачуваного розгортання — Docker і Docker Compose, щоб середовище було однаковим у розробників і на сервері. Додатково використовувався FastCGI Process Manager — менеджер процесів, який допомагає ефективніше обслуговувати велику кількість запитів.

Окрему роль відіграли наші внутрішні інструменти. SFL — структурна фрактальна мова — допомагала автоматизувати прототипування баз даних, API і документації. А FRACTAL використовувався як внутрішній фреймворк Ingello для прискорення розробки та зниження бюджетів на проєкт. У низці місць ми також спиралися на компоненти Yii2 і Symfony — зрілих PHP-екосистем, які дозволяють збирати систему не з хаосу, а з уже перевірених будівельних блоків. У сумі це дало нам стек, який був не екзотичним, а робочим: достатньо гнучким для стартапу і достатньо серйозним для складної архітектури.