Onlayn Hamshira case study: a web app for booking a home nurse

What is Onlayn Hamshira

Onlayn Hamshira is a healthcare service that lets patients call a nurse to their home ("hamshira" means nurse in Uzbek). The Win to Win website describes it as a home nurse and doctor call service with a service catalog, booking, orders and news in a web app.

Everything below in this section comes from the project card. Editorial conclusions and advice sit in separate sections and do not describe how the product works internally.

That is why this case study has no figures for orders, revenue or timelines. Any such number today would be a guess, and we would rather show you what is confirmed.

What problem the project set out to solve

The goal was to make getting medical help at home as easy as ordering a taxi. The project card reduces the flow to three steps: choose a service, enter your address, get a confirmation.

The taxi comparison works as a product requirement, not just a slogan. Users should not have to understand how the service operates behind the scenes. They need to get from a need to a clear answer that their request was accepted, in one pass.

It is also a useful model for anyone commissioning a similar build. Instead of "we need a healthcare app", the brief names the action a user must complete. Every screen can then be tested against one question: does it move the patient closer to a confirmed request?

What the Win to Win team built

The W2W team delivered three parts of the product: a patient-facing web app with booking, a service catalog and an admin panel. Together they cover the journey of a request from the patient's choice to the work of the service's staff.

• A web app with step-by-step booking. Booking is split into steps instead of one long form.
• A catalog of services with prices and descriptions in Uzbek and Russian. Patients see what a service includes and what it costs, in the language they prefer.
• An admin panel for requests, staff and schedule. Incoming requests, employees and their schedule live in one place.

The key point is that the product has two sides. The patient sees a simple booking, but behind each confirmation sits operational work: a request has to be accepted and matched to staff and the schedule. The admin panel is therefore part of the core flow, not a side screen.

If that structure resembles your project, see what web platform development at W2W covers, including customer accounts, bookings and multi-role services.

Why moving nurse visits online makes sense

The digital channels for this kind of service already exist in Uzbekistan: nearly everyone uses a phone, and electronic health records are widespread. That shows the channel is ready; it does not prove demand for a specific service, which you still need to test.

What the public data shows:

• 99.3% of people aged 10 and over in Uzbekistan used a mobile phone in 2025, according to the National Statistics Committee;
• 33.3 million mobile internet subscriptions were counted as of 1 January 2026, 4.3 times more than in 2015 (subscriptions are not people; one person can hold several SIM cards);
• almost 38 million electronic medical records have been created in the DMED system, and all state medical institutions are connected to it, the Ministry of Health reported in February 2026;
• 5.8 million nurses were missing worldwide in 2023 against a workforce of 29.8 million, according to WHO, with the gap projected to narrow to 4.1 million by 2030.

The WHO figure is global, not specific to Uzbekistan. The practical takeaway still applies: nurses are a limited resource, so a home care service has to allocate staff time well, not just accept requests.

What to plan if you are building something similar

Before development, settle six questions: flow, pricing, scheduling, languages, roles and data. These are W2W editorial recommendations for future clients, not a description of how Onlayn Hamshira works.

Two common early mistakes:

• starting with a native app for everyone, when a first version can often be tested more simply on the web: the flow and catalog matter more than the number of platforms;
• leaving the admin panel for later, which pushes requests into messengers and spreadsheets and makes the patient's confirmation meaningless.

One question sits outside engineering altogether. Which services may be delivered at home, who may perform them and what permits the organization needs are not decisions for a developer. Confirm these with a local lawyer and healthcare specialists before design starts.

Which data rules to check in Uzbekistan

A nurse call service handles at least names, phone numbers and addresses, so Uzbekistan's Law on Personal Data (ZRU-547) applies. At minimum, your specification should cover the grounds for processing and where data is stored. This is not legal advice; a lawyer should confirm the requirements for your project.

What the texts on lex.uz confirm:

• consent of the data subject is listed in Article 18 among the conditions for processing personal data, and withdrawing consent is listed in Article 17 among the grounds for deleting data;
• biometric and genetic data, plus data of people who use the services of telecom operators working in Uzbekistan, must be stored inside the country (Article 27¹ as amended by Law ZRU-1125 of 26 March 2026);
• other personal data may be stored and processed abroad if one condition is met: the country is recognized as offering equal protection, the operator applies approved standard contractual terms or binding corporate rules, or it complies with approved international standards.

For a foreign company, settle this before architecture work and record it in the specification, because any local storage requirement affects hosting.

Where else this model works

The combination of a catalog, step-by-step booking and an admin panel fits almost any service a person delivers at a set place and time. Healthcare is just one example, and the most demanding one.

The same logic can power:

• on-site services such as cleaning, appliance repair or equipment installation, where the address and visit window matter;
• appointments with specialists such as clinics, salons or consultants, where the schedule matters;
• tutoring and training, where the program catalog and teachers' schedules matter.

All of these share one main risk: the customer side looks finished while internal processes remain undefined. So start by asking what happens to a request after the button is pressed: who sees it, who confirms it, what happens on a refusal and how the customer finds out. The answers define the scope.

This two-sided structure also appears elsewhere in the W2W portfolio. RIDO, for example, is an intercity rides and parcels platform with a web app, apps for passengers and drivers, and an admin panel. The industries differ, but the principle holds: a product is a customer flow plus a tool for the people doing the work.

Where to start

Describe your service in one sentence using the same pattern as Onlayn Hamshira: choose, enter, get confirmed. Then list who handles a request on your side, which shows the real size of the admin panel straight away.

From there:

• fill in the development brief on the Documents page for a first estimate;
• book a 30-minute call to go through the flow and constraints; W2W prepares a commercial proposal within 2–3 days;
• plan the budget from that proposal: W2W prices each project individually, with team rates of $10–30 per hour as a guide.