Build or buy a patient app: the questions that settle it
Patient app build or buy is the wrong opening question. Ask what the app replaces, whether your case mix gives patients a reason to open it twice, whether it needs your registration system or only your brand, who owns it in year three, and what a failure costs. For most hospital groups I would buy the components, build the integration layer, and reach patients through mobile web and messaging first.
Somewhere in most hospital groups there is a slide about a patient app. It shows appointments, reports, prescriptions, payments, teleconsultation, health records, maybe a wearable. The debate that follows is always framed the same way: do we build it ourselves or buy something off the shelf.
Patient app build or buy is a real question, but it is almost never the first one. The first one is whether the app should exist at all, and what it is meant to replace. I have watched groups spend a year and a great deal of goodwill on an app that fewer patients used than the website booking page it sat beside. I have also watched a group buy a packaged product, brand it, and get something genuinely useful running in a quarter.
What separates those outcomes is not the choice of build or buy. It is whether anyone answered a short list of questions honestly before the choice was made. This piece sets out those questions, in the order I would ask them, and ends with how I would decide.
Question one: what does the app replace?
An app is not a channel you add. It is a channel that has to take work away from another one, or it becomes a fourth place where the same request arrives and nobody is sure who answers it.
So name the thing it replaces. Phone calls to the contact centre for appointment booking. Walk-ins to the report collection counter. Payment queues. Calls asking when a report will be ready. Follow-up reminders currently made by hand. Each of those is measurable today and each of them has a team attached who can tell you whether the app helped.
There is a second half to this question that groups skip. The team whose work the app removes has to agree that it should be removed. A contact centre that loses booking calls loses a reason to exist in its current size, and a report counter that empties becomes a staffing conversation. If nobody has had that conversation, the app launches and the old channel quietly stays open, staffed and preferred, and the adoption numbers never move. I have seen more apps defeated by an unchanged phone script than by anything technical.
If the honest answer is that it replaces nothing and simply offers a better experience, be careful. Better experience is a real goal, but it will not carry an app through two years of maintenance, app store updates, support tickets and a team that has moved on. I would rather see a narrow app that removes one queue than a broad app that improves everything slightly.
Question two: will patients open it twice?
This is where most hospital apps die, and it has nothing to do with engineering. A person visits a hospital rarely. The app they installed for a knee replacement is deleted three months later, and reinstalling it a year on means finding the password they never set properly.
The exceptions matter and they are worth naming. Chronic and long cycle care, where a patient returns often and there is something to do between visits. Maternity, where the relationship runs for months and the family wants the record. Diagnostics and health check businesses, where repeat is the whole model. Transplant and oncology, where the family is coordinating a long and complicated journey. If your case mix has a real share of these, an app has something to hold onto. If it does not, most of what you want is better delivered through a strong mobile web booking journey and a messaging channel.
I have argued that the booking journey on your website is a product in its own right, and in a lot of groups it is the product that deserved the app budget. The same applies to the messaging channel most Indian patients already live in, which I have written about in why messaging has become the hospital’s real front door. Neither needs an install.
Question three: does it need your systems, or just your brand?
Here is where patient app build or buy starts to become a technical question rather than a strategic one.
If the app is mostly content, appointment requests and a payment link, almost anything will do and buying is straightforward. If it has to show a real appointment slot from your registration system, a report the moment it is verified, a bill with the correct payer treatment, and a record that is identical to what the front desk sees, then the app is really an interface to your existing systems, and the hard work is integration. In that case what you are choosing is not a product, it is an integration project with a front end attached.
That distinction changes the buy decision completely. A packaged product that assumes one registration system, or that expects a modern interface where you have an older one, will need so much adaptation that the licence saves you very little. Ask any vendor to show the app running against the version of the registration system you actually run, at a unit that is not your flagship. The answer to that request tells you more than any demo.
Question four: who will own it in year three?
Software is not bought, it is adopted, and adoption has an owner. Building means you need product, design, engineering and testing capability that stays. That is a hiring and retention commitment, and hospital groups are not usually the employer a good mobile engineer chooses when they have other offers.
Buying moves the capability outside but does not remove the need for an owner. Someone inside still has to decide what changes, chase the roadmap, test each release against your systems, and handle the support queue. If nobody has that in their objectives, a bought app decays exactly like a built one, just with an invoice attached. The pattern I keep seeing is an app that was somebody’s project, then nobody’s, and is now a one star rating that shows up in search results next to your hospital’s name.
My rule is that if you cannot name the person who will own the app in year three, and they are not currently in the building, do not start.
Question five: what does it cost when it goes wrong?
A patient app holds health information, which means it carries obligations that a brochure site does not. Consent, purpose limitation, retention, access control, the ability to honour a deletion request, breach handling. Building means you own all of that and the security testing that goes with it. Buying means you inherit a vendor’s decisions, which is fine only if you have read them.
Ask where the data sits, who at the vendor can see it, what happens when the contract ends, and how a patient withdraws consent. Ask how quickly a security fix reaches production. These are contract questions, not features, and the group’s legal and IT teams should answer them before anyone looks at screens. The wider obligations here are the ones I set out in what consent under DPDP changes for hospital marketing, and they apply with more force when the data is clinical.
Support is the other cost that hides. Every app generates a stream of people who cannot log in, cannot see a report they were told is ready, or paid twice. Somebody has to answer them, in the languages your catchment speaks, at the hours patients are awake. A built app puts that queue on your team. A bought one usually does too, because the vendor supports you, not your patients. Plan the queue before launch, because the alternative is that it lands on the contact centre unannounced and the app becomes the thing the agents dread.
There is also the reputational cost of a bad app, which is underrated. A slow, broken or confusing app is worse than no app, because the patient experienced your hospital through it and formed a view.
The third option nobody puts on the slide
Build or buy is a false pair. There is a middle that most groups should look at first: buy the commodity parts, build only the thin layer that is genuinely yours, and deliver the whole thing through the browser and the messaging channel rather than an install.
In practice that means packaged components for payments, teleconsultation, notifications and identity, a small integration layer your own team owns, and a mobile web experience that needs no download. You keep control of the bit that touches your registration system and your patient data, which is the part that is hard to replace, and you rent the parts that every business needs. I have set out the broader version of this argument in buy, build or partner for a new care format, and the logic transfers cleanly.
The reason this option gets skipped is that it does not produce an app icon to show the board. That is a genuine cost. Icons carry meaning inside an organisation. But the question to put back is whether the group wants an icon or wants fewer people standing in a queue.
Patient app build or buy: what a sensible evaluation looks like
If you have answered the five questions and an app still makes sense, run the evaluation on your own terms rather than the vendor’s.
Write the three journeys that matter most, end to end, in plain language. Booking and arriving. Getting a report and understanding what happens next. Paying and getting a receipt that the payer will accept. Then ask every option, built or bought, to demonstrate those three journeys against your systems, at a unit that is not your best one, with a staff member who has not been coached.
Give weight to the unglamorous things: how a patient recovers a lost login, what happens when the network is poor, how the app behaves on an older handset, whether it works in the languages your catchment actually speaks. And avoid the trap of scoring feature lists. Every product will tick every box. What separates them is behaviour under your conditions, which is also the principle behind not letting vendors set the agenda, something I have written about in managing vendors without becoming their project manager.
How I would choose
For most Indian hospital groups, my answer is buy the pieces, build the integration layer, and skip the app for now in favour of mobile web and messaging. That is not a fence sitting answer, it is a preference with a shape: rent what is common, own what touches your data, and do not ask patients to install anything until you have something they will open twice.
I would buy a packaged patient app outright when the group needs a serviceable experience quickly, the registration system is one the product already supports, and the ambition is genuinely standard: appointments, reports, payments, teleconsultation. There is no advantage in building that, and the build will be slower and worse.
I would build when the app is the product rather than a convenience. A group running a chronic care programme, a home care business or a long cycle specialty where the between visit experience is the offering has something no packaged product will fit. In that case the app is a real product with real users, it deserves a real product team, and the build is justified by use, not by pride.
What I would not do is build a general purpose app because a packaged one felt like an admission of weakness. That instinct has cost hospital groups more than any licence fee.
What to put on the agenda this month
Bring three plain counts to the next meeting, not ratios: how many people booked through your website last month, how many enquiries arrived through messaging, and how many patients returned within a year. Those three tell you whether an app has anyone to serve.
Then run a short exercise. Take the most common reason patients call your contact centre and design the mobile web version of solving it. Ship that. Watch what happens to the call volume. It is a week or two of work and it teaches the group more about appetite than a year of app planning would.
Finally, write the ownership line before the technology line. Name the person, the team around them and the budget that keeps the thing alive after launch. If that paragraph is hard to write, you have your answer, and it is not a choice between building and buying. It is not yet.
Questions people ask
It is the choice between commissioning your own mobile application and licensing a packaged one that you brand and configure. In practice there is a third route that suits most hospital groups: buying commodity components such as payments, teleconsultation and notifications, building only the integration layer that touches your own systems, and delivering the experience through mobile web rather than an install.
Often not yet. An app has to take work away from another channel, and patients who visit a hospital rarely will not keep one installed. Where the case mix is heavy in chronic care, maternity, diagnostics, health check renewals or long cycle specialties, there is a genuine reason to return and an app can hold a relationship. Elsewhere, mobile web and messaging usually serve better.
Ask what queue disappears. If nobody can name a counter, a call type or a reminder that the app removes, the project is buying an icon rather than an outcome. Then ask who owns it three years from now. If that person is not already employed and does not have it in their objectives, the answer is to wait rather than to choose between building and buying.
The cost after launch rather than the cost of launch. Maintenance, store updates, support handling, security testing, integration work each time a connected system changes, and the internal time that none of the estimates include. A licence fee is visible and a built app looks free once the team is hired, which is exactly backwards. Ask for a view of the third year, not the first.
When the app is the product rather than a convenience. A chronic care programme, a home care business or a long cycle specialty where the experience between visits is the offering has requirements no packaged product will fit. That app has real users doing real things, so it deserves a real product team. Building a general purpose app to avoid the look of buying is the mistake.
When the group needs a serviceable experience soon, the ambition is standard, and the product already supports the registration system you run. Appointments, reports, payments and teleconsultation are solved problems, and building them again will be slower and worse. The condition is that the product must be shown working against your systems at an ordinary unit, not at the flagship in a rehearsed demo.
Whether the app is an interface to your existing systems or a mostly standalone experience. If it must show real appointment slots, verified reports and correct billing, the project is an integration project with a front end attached. Ask about the interfaces available on your registration system version, how older units differ, and what happens when a connected system is unavailable.
A patient app holds health information, so consent, purpose limitation, retention, access control, deletion requests and breach handling all apply. If you build, you own every one of those decisions and the security testing. If you buy, you inherit the vendor’s decisions, which is acceptable only once your legal and IT teams have read them. Settle where data sits and what happens at contract end before looking at screens.
Which clinical information belongs in a patient’s hands without a conversation, and how it should be worded. Reports and results that reach a patient before a consultation can cause avoidable distress, so release rules need clinicians to set them. They should also say what the app must never attempt, since anything resembling advice or triage sits on their licence rather than on the growth team’s plan.
A packaged product that already supports your systems can be branded and running within a quarter, with the time going into integration and testing rather than design. A built app takes longer than any plan allows, because the first release is the easy part and the second one arrives during a busy season. A mobile web improvement can ship in weeks and is the fastest way to learn.
Write the three journeys that matter, booking and arriving, getting a report and understanding what follows, paying and receiving a receipt the payer accepts. Ask every option to demonstrate those against your systems at an ordinary unit with an uncoached staff member. Score behaviour under poor networks, older handsets, lost logins and the languages your catchment speaks, rather than feature lists everyone ticks.
Yes, and it is underrated. An app store listing sits in search results beside your hospital name, and a slow or confusing app becomes a patient’s experience of your organisation. Abandoned apps are worse than absent ones because they signal that the hospital starts things and stops maintaining them. If you cannot commit to the upkeep, do not publish.
Choosing the technology before naming the owner and the outcome. The debate about building and buying is enjoyable because it feels like a decision, while the harder questions about who runs it and what it replaces get deferred. Groups that answer those first usually find the build or buy choice resolves itself, and often find they did not need an app this year at all.
