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

Мы раскажем как строился стартап - не только программная часть. Обсудим тонкости и нюансы создания 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-экосистем, которые позволяют собирать систему не из хаоса, а из уже проверенных строительных блоков. В сумме это дало нам стек, который был не экзотическим, а рабочим: достаточно гибким для стартапа и достаточно серьёзным для сложной архитектуры.