A founder explains a healthcare app idea to a technology advisor across a meeting table.

By Praveen Soman, CEO, Sigosoft

Most founders who call us about a telemedicine app arrive with a feature list. Video calls, booking, e-prescriptions, maybe an AI assistant. Before we talk about any of that, I steer the conversation somewhere less exciting: which country, who holds the licence, where the data will live, and which national systems the app has to connect to. Those answers decide most of the budget and most of the timeline. The features are the easy part.

So here is the short version of what I tell every founder before they build a telemedicine app. Start with one market and one specialty. Remember that the licence belongs to a clinic, not to your app. Decide where your data lives before you choose a cloud. Treat national integrations as core features, not extras. Make video work on bad networks. And add AI only where it earns its place.

The rest of this article is the longer version, the one we usually give across two or three meetings.

One of the earliest lessons I learned came from building Medicino. Going in, it was tempting to think of telemedicine as a video-calling problem. It is not. The consultation is only one moment in a much longer experience. Patients need to find the right doctor and book without confusion, doctors need a consultation flow they can actually work with, and the operational side has to keep running reliably around both of them. Medicino is where that became clear to me, and it is still the first thing I tell founders: understand the healthcare workflow first, then decide what technology belongs around it.

A doctor holds a video consultation while clinic staff help a patient at the reception desk behind her.

Pick one market, one specialty, one city

Almost every founder wants to be regional from day one. UAE and Saudi Arabia, or India plus the Gulf, sometimes Nigeria as well. I understand why. A big map looks good in a pitch deck. But each of those countries has its own regulator, its own patient ID, its own data law and its own national health platform. Launching in two at once is not one project with a bigger scope. It is two projects that share a logo.

Specialty matters for the same reason. A dermatology service lives or dies on image quality. Mental health needs longer sessions and more privacy. General practice needs fast, safe prescribing. Each one shapes the app differently, so I ask founders to pick the one they can do best, launch it in one city, and learn from real consultations before they expand. We explain how to scope that first version in our guide to building a telemedicine MVP.

Illustration of four different city islands connected to a smartphone, representing four healthcare markets.
image

When founders ask me which of our four main markets is easiest, my honest answer is that none of them is easy. They are hard in different ways.

The UAE has three health regulators. Dubai’s rules are the most detailed: the DHA’s telehealth standard, version 4, took effect on 26 November 2025, and it is strict about hosting, certification and NABIDH integration. We turned it into a developer checklist for the DHA telehealth standards.

Saudi Arabia has set a very high public bar for virtual care through the Ministry of Health’s national virtual hospital, and private platforms are measured against that. Data stays in the Kingdom, and insurance runs through NPHIES. Our article on lessons from Seha Virtual Hospital covers what that means for software.

India has enormous volume and low prices per consultation. It also has the most developed national digital health rails: the Health Ministry reported more than 93.95 crore ABHA numbers in July 2026. The trade-off is compliance work under ABHA and ABDM integration and the DPDP Act.

Nigeria is changing fastest. The April 2026 Electronic Pharmacy Regulations brought in a national e-pharmacy platform that operators must connect to, which we covered in our guide to pharmacy app development in Nigeria.

A note on our own experience here. We have worked with businesses in Saudi Arabia and Nigeria in other software domains, and we are seeing more enquiries from both markets around healthcare and digital platforms. What I have written about those two countries comes from research and from those conversations, not from a telemedicine platform we have already delivered there.

The licence belongs to a clinic, not to your app

This is the conversation that surprises founders most. In most of the markets we work in, an app cannot practise medicine. A licensed facility does, through licensed doctors, and the app is the tool they use.

Dubai spells this out more clearly than anywhere else. Under section 7.8 of the DHA Standards for Telehealth Services, a platform licence covers only the technology that connects licensed facilities to patients. A platform may not deliver clinical services, may not act as a healthcare provider and may not recruit doctors to deliver care through it.

A doctor and nurse at a clinic nurses' station, reviewing a patient record and preparing medication.

That forces a decision every founder has to make early: are you a healthcare provider, or a technology company that serves healthcare providers? They are very different businesses. A provider owns clinical risk, hires doctors and earns per consultation. A technology company sells software to clinics and hospitals and never touches the clinical side. Some founders do both through two separate entities. What does not work is building the app first and choosing later, because the answer changes the licence, the contracts, the consent forms and even the app’s screens.

If you are setting up in the Emirates, we walk through the licensing route in how to start a telemedicine business in the UAE.

Decide where your data lives before you choose a cloud

Founders often pick a cloud provider because of free credits, then ask about data rules later. In health, that order is backwards.

In the UAE, health data tied to services in the country has to stay in the country under Federal Law No. 2 of 2019, and Dubai adds requirements for Tier 3 data centres and a cloud provider certified by the Dubai Electronic Security Center. Saudi Arabia’s national telehealth guidelines expect data to be hosted inside the Kingdom. India’s DPDP Act has no blanket localisation rule, but health data processed within ABDM must be stored in India, and the main DPDP duties apply from 13 May 2027.

The part founders miss is that “data” means more than the main database. It includes backups, logs, analytics events, the relay servers that carry video calls, and any AI service that hears or reads a consultation. A UAE-hosted app that sends call audio to an overseas AI model is still moving health data abroad. We go deeper on this in secure cloud architecture for telemedicine apps.

Two other things are hard to change after launch, so I ask founders to settle them now. The first is consent: record every consent with a version, a time and a purpose from the very first patient. The second is identity: Emirates ID in the UAE, ABHA in India. Retrofitting either one onto live patient records is slow and unpleasant work.

Your app is one node in a national system

Founders think of their app as a product. In the markets we work in, it is also one participant in a national system, and that system has its own rules, test environments and timelines that you do not control.

Illustration of a smartphone at the centre of a city block, connected to a hospital, pharmacy, lab, insurer and government building.

In Dubai, the DHA telehealth standard says the health record system shall integrate with NABIDH, and Abu Dhabi has Malaffi. In India, sharing records means certifying as a Health Information Provider under ABDM, and reading them means certifying as a Health Information User. In Saudi Arabia, insurance claims run through NPHIES and e-prescriptions commonly through Wasfaty. In Nigeria, e-pharmacy operators now connect to a national platform.

Each of these has a sandbox or test phase, required fields, coding rules and an approval step. None of them can be rushed by working weekends. So I tell founders to put integrations in the first roadmap, not in phase three, and to code clinical data properly from day one. Free-text diagnoses and drug names are the most common thing that blocks an integration later. Our guide to NABIDH and Malaffi integration shows what this looks like in practice.

Video is the feature patients will judge you on

Patients never see your consent records or your hosting region. They see a frozen face, or a call that drops halfway through describing their symptoms. That moment decides whether they come back.

The networks are not kind. Patients join from home Wi-Fi shared with a family, from mobile data in a car park, or from a hospital network that blocks most video traffic. Reliable video comes from unglamorous engineering: your own relay servers in the right country, a connection that works over the same port as normal web traffic, a pre-call check while the patient waits, and a plan for when video fails.

My rule is simple. A consultation that finishes on audio is a good consultation. One that drops is a refund and a bad review. So every app we build steps down from HD video to audio, then chat, then a phone callback, rather than giving up. The technical detail is in our article on reliable telemedicine video calls with WebRTC, and our piece on telemedicine in war zones shows how far poor networks can push this.

Selli, a telemedicine platform we built for the Mauritanian market, is the project that has stayed with me most. You cannot design telemedicine for that kind of market by assuming everyone has a fast, reliable connection. For some patients in remote areas, network access is itself part of the healthcare problem. That pushed us to treat reliability, simple flows and graceful fallback as part of the product, not as technical extras. But what I valued most was the other side of that challenge. When a product is built for those realities, telemedicine can connect people in remote areas with healthcare professionals without asking every patient to make a long journey to see one. That project still shapes how we think about emerging markets.

A woman in a small desert town holds a video call with a doctor on her phone while her father listens.

Add AI where it earns its place

Every founder asks about AI now, and most have been told it should be in version one. My view is more cautious. AI is worth adding where it saves a doctor’s time or helps a nurse spot a problem sooner. It is not yet something I would build a first version around.

A doctor talks with an older patient while a laptop beside them quietly records the consultation.
image 1

The best evidence so far is in documentation. In a randomized trial published in NEJM AI in late 2025, time spent on notes fell by about 22 minutes per clinician per day with an ambient AI scribe. But another trial at UCLA found doctors used the scribes in only about a third of eligible visits, so adoption is not automatic. And in Dubai, the DHA now requires patient consent for ambient AI and a doctor’s review before any AI-written note enters the record. We cover how to build this in our guide to adding an AI medical scribe to a telemedicine app.

The other place AI helps is remote monitoring, where the real problem is too many alerts rather than too few. Sorting readings so a nurse sees the right patient first is useful. Letting software make the clinical call is not, at least not yet. Our article on remote patient monitoring app development explains how we design those alerts.

I want to be clear that this is not a disclaimer. I am genuinely positive about AI that takes paperwork off a doctor’s desk, or that helps a nurse see the right patient first. Where I draw the line is software that makes the diagnosis or the treatment decision. That is a clinical product with its own regulation and its own safety questions, and it deserves to be treated as one, not added to a feature list.

My advice is to get the core consultation working well, then add AI to the step your doctors complain about most. That way you can measure whether it helped.

What telemedicine development websites often get wrong

While you research, you will read a lot of agency websites, ours included. Much of it is useful. Some of it is oversimplified, and a few claims are misleading when presented as universal requirements. Here are examples we found on public pages in October 2026, each linked so you can check the wording yourself.

WebsiteClaimWhat is actually true
Taction Software“100% HIPAA Compliance Guarantee”HIPAA is not a product certification. HHS says it does not endorse or recognise private “certifications”, and that they do not absolve covered entities of their obligations. Compliance depends on architecture, policies, contracts and day-to-day operations.
ITD Growth Labs“TURN servers in 3+ regions (mandatory…)”TURN relays are needed for users behind restrictive networks. The number of regions depends on where your users are, latency and data residency, not on a fixed count. A UAE-only service may need relays in the UAE only.
ITD Growth Labs“Business Associate Agreements with every vendor”HHS defines a business associate as one that creates, receives, maintains or transmits PHI on your behalf. Vendors with only incidental access, or pure transmission conduits, are not. The reverse matters too: a cloud provider storing encrypted PHI still is one, even if it cannot read it.
ProjectSupplyABDM integration as “The Core Mandate”ABDM matters a great deal in India, and the article itself frames it as a credibility benchmark. But we found no central rule making ABDM a legal precondition for every telemedicine app. Obligations arise through specific routes, such as AB PM-JAY empanelment and state directives.
Vedpragya“Zero breach guarantee”No provider can reduce security risk to zero. What a serious partner can commit to is controls, monitoring, testing and a rehearsed breach response.
ShieldForceAnnual penetration testing “became a mandatory HIPAA Security Rule requirement in 2026”Annual penetration testing is in HHS’s proposed Security Rule update, and HHS states the current rule remains in effect. As of August 2026, HIPAA Journal reported the final rule targeted for July 2027. It is good practice, not yet a HIPAA requirement.

A few broader misconceptions come up in almost every first meeting:

  • HIPAA is not the same as end-to-end encryption.
    Encryption is one safeguard. The Security Rule also covers risk analysis, access control, audit logs, staff policies and contracts.
  • FHIR support is not plug-and-play EHR integration.
    FHIR is a data standard. Connecting to a real EHR usually also means SMART on FHIR authorisation, permissions, data mapping and the EHR vendor’s own approval process.
  • WebRTC is not a complete video platform.
    It provides the real-time media layer. Production telemedicine still needs signalling, relay servers, monitoring, reconnection handling and, if you record, secure storage.
  • AI diagnosis is not just another feature.
    Software that drafts notes is a different category from software that suggests diagnoses or treatments. The FDA’s clinical decision support guidance, updated in January 2026, explains when such software is regulated as a medical device.

I do not share these to criticise anyone. Founders make expensive decisions based on what they read, and they deserve to know which statements are required by law, which are good practice, which depend on their architecture, and which are simply marketing. If a development partner cannot explain that difference clearly, keep looking. That includes us.

What we ask founders to bring to the first meeting

Dofody taught me something different: healthcare software has to be simple enough to disappear into the workflow. A patient should not need to understand how the technology works before they can speak to a doctor, and a doctor should not be fighting the software in the middle of a consultation. Working on Dofody changed how we approach products. We stopped treating features as separate items on a list and started looking at the complete patient journey from start to finish. That is why we now spend time on the business and clinical workflow before we estimate any development work.

Overhead view of a notebook with a hand-drawn patient journey, sticky notes and two people's hands planning.

None of this needs a developer yet. Most of it can be worked out on paper, and it makes the first meeting far more useful. These are the six questions I ask founders to think about before we meet:

  1. Where will you launch first?
    One country, and ideally one city.
  2. Who holds the licence?
    You, a partner clinic, or the hospitals you sell to.
  3. What is the first specialty, and where do the first doctors come from?
  4. How will patients pay?
    Out of pocket, through insurance, or through an employer.
  5. What is driving your timeline?
    A funding round, a hospital contract, a season.
  6. What do you already have?
    A brand, doctors, a clinic, existing software or patients.

If you have answers to all six, the first meeting turns into a plan. If you only have some of them, that is normal. Working out the rest together is a big part of what we do.

The honest version of our pitch

We build telemedicine apps for a living, so it would be easy for me to tell you that the app is the hard part. It usually is not. The hard parts are the decisions in this article: the market, the licence, the data, the national systems. Most of them can be settled before anyone writes a line of code.

The founders who settle them early tend to launch closer to their date and spend their budget on things patients actually notice, such as a call that connects and a prescription that arrives on time. The founders who postpone them usually end up paying for the same work twice, once to build it and again to change it.

So if you are planning a telemedicine app in the UAE, Saudi Arabia, India, Nigeria or another emerging market, start with the six questions above. Bring us your answers, or bring us the questions you cannot answer yet, and we will work through them with you before we talk about features. If you want to discuss the product, technology and market requirements before development begins, explore our telemedicine app development services or speak with our team.

praveen soman ceo sigosoft 3

I work from Bangalore, and I spend a lot of my time with healthcare businesses in Dubai and other markets. If those years have taught me one thing, it is that good healthcare technology cannot simply be copied from one place to another. The products I am proudest of came from taking the time to understand the people, the regulations and the everyday realities of the market they were built for, and that is the conversation I always look forward to having with a new founder.

Praveen Soman, CEO, Sigosoft

Further reading

If you want the detail behind any part of this article, these are the guides we have written for founders and their technical teams:

Sources