LLC Lita Health: medicine, prevention, oncology

We will tell how the startup was built - not only the software part. We will discuss the subtleties and nuances of creating an MVP without large investments, the specifics of organizing processes, the subtleties of going to market, the specifics of design and prototyping, demand testing, and obtaining permissions for payment systems. LLC Lita Health is a medical software company, a partner of Ingello Systems. Our architect and our business analyst are co-founders and beneficiaries of this company, helping to develop medical software as well as build the company itself from scratch. For the company’s development, not only system architecture but also enterprise architecture was designed. Comprehensively: from the business structure and product model to the solution architecture, system architecture, and control of the process of developing applications, databases, and software interfaces. From the model for managing people and processes to deep technological solutions. The story of this company is still being written to this day, already for several years.

In general terms about the project

We all want to feel energetic and healthy at any age. Lita Health was conceived as a company developing an application and management system for comprehensive prevention: as a product for families that monitors vaccination schedules, reminds about planned visits, sends notifications, helps detect complex diseases, including oncological ones, at early stages, and predicts risks.

But a system of this scale requires years of work and hundreds of thousands of dollars at a minimum. Therefore, we decided to start with female oncology. The application was supposed to become an MVP that predicts the risks of different types of cancer according to approved American medical protocols.

However, even such a reduced product turned out to be significantly more complex than it seemed at the very start. How to ensure the security of sensitive medical data? How to anonymize it without losing the connection with patients and leads? How to implement survey protocols so that they can be scaled? How to obtain permission from payment gateways for sales? How to get the first traction? Finally, how to organize a team if at the start about 10 people were involved in the project in total? And how to balance on the edge of complex functionality and pragmatism while simultaneously making releases, updates, and collecting user feedback? If you have tried to create a non-trivial technology startup, you understand us perfectly.

This is what the subject area looked like: this is a diagram of just one scenario flow for female oncology. The full pipeline did not even fit into the screenshot. And there were many such diagrams.

Looking ahead: over the years, we created several online services and management subsystems, received user feedback, pitched the project, launched advertising, participated in hackathons, strengthened the team with new specialists, faced many problems, and solved them.

Solutions

Builder for oncology tests and other categories

Since the subject area was practically boundless, an important architectural decision was made: to create a flexible model of medical protocols, which can be expanded without hardcore programming, and ideally without programming at all. This is usually called a builder.

Our architect, Oleg Grigoriev, analyzed the subject area not only within the framework of the nearest tasks, but also in the logic of future scaling. It became obvious: if everything were solved programmatically head-on, a serious budget would be required not only for implementing the algorithms, but an even larger budget for maintaining them. Therefore, our own model of a protocol builder was designed. It is important to understand: we did not use a ready-made builder, but created our own, because ready-made solutions for such protocols essentially did not exist on the market.

The draft model with decoding looked approximately like this:

And this is how a more visual way of working with the builder was documented. The specific feature of medical protocols was that, depending on a number of contexts, the system had to decide which question to display to the patient at that moment. At the same time, it remembered contexts and answers, and based on them predicted risks.

For convenient input, we quickly developed an administrative system. It looked boring, but it allowed protocols to be quickly transferred from diagrams into a real working software model.

This made it possible to enter texts, set connections with contexts and widget types. Different questions required different input methods from the patient, and this could also be configured through the builder. In essence, it resembled creating forms in Google Forms, except that Google Forms does not have contextual graphs that allow questions to change depending on answers, states to be remembered, and risk determination algorithms to be launched.

As a result, the builder received the necessary number of degrees of freedom: it was sufficient not only for the first test protocol on female oncology, but also for further expansion of the tests, which was critically important for the application’s growth.

React application

Architecture is the making of key decisions. Therefore, the decision was made to first create a web version of the application and then adapt it for different platforms: iOS, Android, and desktop. This is a universal approach whose value has long been clear to many. First, a browser application is launched, and only then separate clients for specific platforms appear.

The strategy was approximately this: we build a browser application, use the approach mobile first, launch immediately on all devices, test without publishing in stores, collect feedback, and then, if necessary, make a wrapper through WebView or even a PWA (progressive web application that can be installed on a device).

For the frontend, we chose React, because it was well suited to our tasks and allowed us to build a smooth, lively interface. To provide the application with data, an API documented through Swagger / OpenAPI was created on the backend.

As a result, the application was supposed to show the patient approximately this kind of screen with results and a plan for further actions:

Question screens and polymorphism

At the start, the patient was greeted by an animated interactive circle that literally invited them to begin the survey. We made a light, minimalist, but enticing animation — a pulsing circle that you just want to click =)

Next, the user went through a series of questions. Technically, each question screen was polymorphic, that is, all screens had the same idea — to get a user response, but the form of that response could differ. Sometimes it was choosing one of several options, sometimes entering a date, sometimes multiple choice.

Accordingly, the input type could be set through the administrative system, and the task of the mobile web application developer was to correctly pick up this polymorphism dictated by the data from the API. This is exactly what was implemented.

Integration of payment systems

Integration of payment systems is always an interesting story. In practice, it is almost always more complicated than it seems at the beginning. And when it comes to a medical project where sensitive patient data is stored, everything becomes even more complicated. This is influenced both by the legislation of the launch country and by the requirements of payment services that operate in this legal field.

There were many requirements for us. We had to make many changes. We were not accepted either the first or the second time. We applied to different payment aggregators and banks, and for some time it looked like a dead end: we were simply refused.

A feature of payment systems in recent years is that they explain the specific reason for refusal less and less often. Usually the answer sounds along the lines of: everything is according to internal policies, laws, and regulations; figure out for yourselves what is wrong. And only experience from previous projects, persistence, and a series of improvements helped us change the application, the legal packaging, and the accompanying materials so that we eventually launched with the Fondy payment system, which now operates under a different brand.

We had a registered LLC, and this, of course, added trust. But at the start we did not want to create a separate website at all, did not want to overload the application interface with extra consents, and did not want to add excessive information. But the world is not particularly interested in what we did not want, so we had to implement an entire block of tasks that initially seemed secondary. And so our already complicated MVP became even more complex.

A separate large topic is data storage and requirements for server infrastructure. As it turned out, this also directly affected the possibility of launch. Perhaps later we will make a separate article about this.

Website and landing page

This is how we got a full-fledged landing website. The website existed before, but it played more of a presentation role than that of a full-fledged corporate object. It had to be seriously reworked: optimized, supplemented with information, and made more transparent for the state, banks, and payment commissions.

In addition, taking into account plans for acceleration programs and the search for marketing investments, we immediately made an English version of the website as well. As a result, the project got two main language versions: Ukrainian and English.

Challenges and problems

Below is not just a list of difficulties, but, in essence, a map of real managerial and engineering bottlenecks that the project had to go through.

Team members and partner co-founders

One of the first and most underestimated problems was the composition of the team. The project had strong and smart people, but with very different experience. Some understood medicine and medical practice well, some were closer to analytics, some to the business side. But essentially no one had practical experience building IT products at the level of a startup or enterprise system.

Because of this, there was no unified way to distribute responsibilities. Participants looked at the project from different sides, spoke different professional languages, and imagined priorities differently. For a medical startup, this is especially dangerous: the product already looks smart, while the internal management kitchen has not yet been formed.

From the point of view of enterprise architecture, we decided to start not with individual tasks, but with the most general picture. First, the principle of the work cycle was built, roles were distributed, and areas of responsibility were outlined. We assembled an end-to-end loop: from business analysis, data collection, and design to the presentation of hypotheses, retention and attraction of the target audience, competitor analysis, product analysis, and returning feedback back into the cycle. In essence, everything was closed around constant analytics, not spontaneous opinions.

Ambitious global plans

From the very beginning, the project was more than just an MVP. Behind the idea was the ambition to build an ecosystem of preventive medicine, not yet another narrow questionnaire for a couple of screens. This was inspiring, but at the same time it also got in the way, because too broad a horizon easily turns a team into a circle of strategic dreamers.

Therefore, in the company’s enterprise architecture, we made several important decisions regarding the work scheme itself. We were inspired by the ideas of the scientific method: observation → hypothesis → testing → model adjustment. We adapted this logic for the company. We did not just come up with a beautiful concept, but turned it into an operational cycle: first we collect facts from the outside world, then build hypotheses, then validate them through the product, marketing, interviews, user behavior, and only after that do we закрепляем decisions.

For a startup, this is critical. Without such discipline, any ambitious idea begins to resemble a castle in the air: beautiful, high up, and very expensive until it collides with reality.

LLC, organizational structure, roles

The next layer of work was already closer to the institutional formalization of the company. The project had an LLC, and this required not just a legal form, but a proper organizational structure. It was necessary to define who is responsible for what, where the boundary between strategy and operational management lies, who makes decisions, and who prepares the material for decision-making.

We built the organizational structure, distributed responsibilities, and began formalizing regulations. Rules for setting goals appeared, along with regulations for requirements gathering, regulations for systems analysis, and regulations for work cycles. All of this sounds boring only until the first conflict, after which it suddenly turns out that these exact documents save the project from managerial fog.

When a startup has no structure, people often work sincerely, a lot, and chaotically. When structure appears, the work begins to form into a system.

Lack of sufficient budget

The key problem was very down-to-earth: the project did not have a sufficient budget. And this automatically means that every decision becomes not just technical, but almost philosophical. What should be done first? What should be invested in? How deep should development go before the first confirmations from the market?

When we joined the project, it turned out that because there was no consolidated way to store information, no common information architecture, and no regulation for recording decisions, different team members had very different, and in some places contradictory, views of the project itself. This included different understandings of the budget issue.

Part of the team leaned toward investing their own money and moving technical development forward as quickly as possible: first the application, everything else later. We leaned toward a different position. In our opinion, even minimal investments should at least partly come from outside — from presales, first clients, donors, partners, or other external sources. Not because we felt sorry for our own money, but because market money is a form of proof of value.

That is why we fixed for ourselves the principle of a minimal budget and began designing development based on this reality. This decision affected the architecture, the priorities, and the pace of implementation. When money is scarce, architecture must be not just beautiful, but economically honest.

Goals, plan-fact tracking

After that, we transferred project management into the logic of setting goals according to the SMART methodology. It was important to us that goals were not inspiring slogans, but measurable units of movement. What exactly needs to be done, who does it, by what deadline, and by what criteria the result will be understood.

We thought through a system for maintaining plan-fact tracking, regular meetings, synchronization sessions, task distribution, and clear recording of who specifically did what on the previous task. This approach gradually removed the feeling of fog and replaced it with manageability.

The cycle itself was formalized as an interactive diagram so that the team could see not only a list of tasks, but also the cause-and-effect relationships between them.

Work cycles and interaction pipeline

Later, this logic grew into what we called an interaction pipeline or work cycle. It described how the company's institutional work is ensured, that is, how an idea turns into a systemic result instead of disappearing in a chat after an emotional call.

The cycle looked roughly like this. Everything starts with the target audience: data, problems, expectations, observations, and feedback are collected. The manager receives this information and sends it further. Then the material is processed by analytics and a product specialist: they analyze, document, and formalize it. After that, the information passes through the architect, who adjusts the documentation of key engineering decisions for the project. Then everything goes into development, where it travels the path from layout and prototype to product. Then the product reaches clients again — through presentation, testing, advertising, or direct use — and the cycle closes, because the client again returns data and feedback.

Sequential goals were also thought through. What follows what, how it is distributed over time, which task is a condition for the next one. For example: start developing a prototype in order to formalize the target audience and the problem; then define participant roles and the work cycle; then conduct audience surveys and keep in contact with it; then agree on and approve the MVP functionality; then develop the prototype; then validate it and obtain either readiness to buy or high-quality criticism. The essence was that the goals became connected, sequential, and, most importantly, measurable.

Changes in the team

The team changed over the course of the project. Some people left, some joined, someone's role changed, and along with that the context changed as well. For a complex product, this is always a risk: knowledge can easily remain in the heads of specific people rather than in the system.

That is why we had to simultaneously strengthen documentation, update roles, synchronize expectations, and record decisions. In such projects, staffing changes are not just an HR issue. They are a question of the stability of the architecture, processes, and collective memory.

Business requirements, technical specifications, analytics

As the project developed, we accumulated business requirements, technical specifications, and analytics. And this was inevitable. A medical product cannot be properly built on the principle of let's figure it out later. Every scenario, every branch, every user type, every input field, every risk, and every assumption had to pass through an analysis stage.

At the same time, the technical specification was not supposed to turn into a bureaucratic monster. We tried to make the documentation a working tool: so that it helped design, discuss, transfer knowledge, and reduce the cost of mistakes, rather than existing just for show.

Design, visualization, changes

Design in a medical product is not just beauty. It is a matter of trust, clarity, and reducing anxiety. We gradually improved visualization, changed the presentation, simplified the interface, and tested where exactly the user feels confident and where they feel confused.

Internal visual materials also played an important role: diagrams, scenario maps, charts, screens, and logical models. They helped synchronize the team. When the domain is complex, visualization becomes not a decoration, but an engineering tool.

Designing the application and server architecture

We had to design not just an interface and not just a server, but an entire system of coordinated layers. It was necessary to think through how the frontend, API, administrative part, database, authorization, payment layer, logging, deployment, and internal product support are connected.

Architecture in such a project is a bridge between medical logic, business constraints, and technical implementation. A mistake at this level later spreads across the entire product like a crack across glass.

Analysis and software implementation of the female oncology scheme

One of the most difficult tasks was translating medical schemes from human language into machine logic. The protocols had to be not just read, but decomposed: contexts, questions, transition conditions, accumulation of risk factors, scenario branches, and final recommendations had to be identified.

In essence, we were turning expert medical knowledge into a formal computable model. It is precisely in such places that a startup suddenly stops being a beautiful presentation and becomes engineering work in its pure form.

Minimalism — remove everything unnecessary

Another important challenge is minimalism. When a project is ambitious, there is a strong temptation to add one more screen, one more hint, one more role, one more function. But this is exactly how an MVP quickly turns into an unwieldy combine harvester.

Therefore, we had to constantly cut away the unnecessary. Leave only what works for the product's main value. Minimalism here was not poverty, but discipline. Not everything that can be implemented needs to be implemented right now.

User security and anonymization

Security was not a decorative topic for a landing page, but a fundamental architectural constraint. It was necessary to think through how to separate medical data, contact data, leads, payment information, and service information so that the system remained useful while not turning into a fragile legal nightmare.

We paid great attention to data anonymization and pseudonymization, access control, the principle of minimally necessary information, and ensuring that sensitive data did not wander through the system unnecessarily. For a medical product, this is not an option, but basic engineering hygiene.

Development of the database and administrative screens

The database had to store not just users and answers. It needed to hold much more complex logic: protocols, branches, contexts, question types, answer history, computed states, results, administrative entities, and the related service layer.

The administrative screens, in turn, became not a beautiful showcase, but a working tool for the team. Through them, it was possible to promptly make changes, transfer schemes into the system, and maintain the domain model without constantly rewriting code.

Application development

The application itself was developed as a living product, not as a monument to an idea. We needed to release versions quickly, test hypotheses, observe user behavior, fix bottlenecks, and at the same time preserve the feeling of interface integrity.

The layer of polymorphic screens was especially important, because it was what allowed the application to adapt to data from the protocol constructor instead of living as a set of hardcoded pages.

Server API development

The server API became the connecting backbone of the system. It had to be strict enough for the frontend and admin panel to work predictably, and flexible enough not to break when the model was expanded.

We documented the API through OpenAPI / Swagger so that the contract between the client and server sides was transparent. This is especially important in projects where the interface, logic, analytics, and administrative layer are developing simultaneously.

Legal issues and data processing

The legal layer of the project turned out to be much heavier than it might seem from the outside. A medical startup cannot exist only on enthusiasm, a beautiful UI, and a strong idea. Correct consents, a data processing policy, clear corporate transparency, correct texts, well-thought-out storage infrastructure, and an overall legal package are needed.

Part of this experience closely echoed our work on designing an MIS for eHealth, where requirements for processes, regulations, and data structure also played a defining role.

Problems with payment systems

Payment systems became a separate obstacle course. Formally, the product already existed, the legal wrapper was gradually being assembled, but passing the filters of banks and aggregators turned out to be much harder than expected.

We received refusals several times without clear details. This is one of the most unpleasant types of problems: when you know there is a mismatch somewhere, but you are not told exactly where. We had to rebuild the presentation of the project, strengthen transparency, refine the texts, and change individual elements of the product and infrastructure. In the end, this knot was untangled, but it clearly showed that a medical MVP is by no means a small project.

Modeling the client portrait and launching advertising

In parallel with development, it was necessary to formalize exactly who our client is. Who makes the decision? Who feels the problem? Who pays? Who uses it? This is not always the same person. In medicine, it especially often turns out that the user, payer, and initiator are three different entities.

Therefore, we modeled the client portrait, tested messages, launched advertising, watched what the audience responded to, and tried not to invent the market in our heads. A good startup grows not from a fantasy about the client, but from repeated contact with real people.

First users and completions

The first real users provided more value than many internal discussions. We saw where people got lost, where they got tired, where they did not trust, where they abandoned the flow, and where, on the contrary, they went through the scenario calmly and confidently.

It was these completions that began to turn the abstract idea into a living product. When real use appears, it immediately becomes clear which decisions were successful and which were beautiful only on paper.

Harvard hackathon and Lita Doctor

Participation in the Harvard hackathon became an important point of external validation and internal concentration. At such moments, the project is forced to answer itself very honestly: what is its essence, what problem does it solve, how is it different, and why does it have the right to exist at all.

In parallel, adjacent product directions began to emerge, including those related to the doctor circuit. Part of this logic later took shape as a separate direction, which we described in more detail in the case study Lita Doctor — online offices for doctors.

First sales

Most importantly, all of this ultimately led not just to a beautiful prototype, but to the launch of a fully working product and the first real sales. It was no longer a concept, not a set of screens, and not an intellectual draft. The product worked, users went through the scenarios, the system performed its function, and the market began to respond with money.

It is at this moment that it becomes clear that years of design, analytics, debates, regulations, diagrams, and refinements were not an academic exercise, but a real path to launch.

Technologies

We selected the project's technology stack not according to what was fashionable, but according to common sense. The application interface was built on React — a library for reactive interfaces, that is, screens that change quickly and smoothly in response to user actions. The web part was based on the familiar and reliable HTML, CSS and JavaScript: the first technology is responsible for the page structure, the second for appearance, and the third for logic in the browser.

On the server side, we used PHP as the main web development language, and stored data in MySQL — a relational database where information lives in tables and the relationships between them. All of this was deployed on Linux — a reliable server operating system, and web requests were served by Nginx, one of the most high-performance servers and proxies in the world. For automating infrastructure tasks, we used Bash, and for containerization and predictable deployment — Docker and Docker Compose, so that the environment would be the same for developers and on the server. Additionally, we used FastCGI Process Manager — a process manager that helps serve a large number of requests more efficiently.

Our internal tools played a separate role. SFL — structural fractal language — helped automate prototyping of databases, APIs, and documentation. And FRACTAL was used as Ingello's internal framework to accelerate development and reduce project budgets. In a number of places, we also relied on components of Yii2 and Symfony — mature PHP ecosystems that make it possible to assemble a system not from chaos, but from already proven building blocks. Altogether, this gave us a stack that was not exotic, but practical: flexible enough for a startup and serious enough for a complex architecture.