Buying vs building: how I decide on healthtech vendors
Every quarter a hospital digital head sits across from a vendor whose product does most of what the group needs, at a price that looks reasonable, with a demo that works. And every quarter the same head has an internal team that says it could build the thing in six months for less. Both are usually right about the parts they can see. The decision depends on the parts they can’t.
Here is the framework I use to decide, the questions that actually discriminate, and the patterns that repeat in Indian healthcare specifically.
Start with the question, not the options
Before comparing a vendor to a build, decide what kind of capability you are acquiring.
Commodity capability is something every hospital needs and nobody differentiates on: email delivery, SMS gateways, payment processing, appointment reminders, form builders, basic analytics. Buy it. Building commodity capability is a waste of scarce engineering time and produces a worse version of something already available cheaply.
Regulated capability carries compliance obligations that are expensive to get right and dangerous to get wrong: electronic health records, e-prescriptions, lab information systems, PACS, consent management, data-protection tooling. Buy it from a vendor who carries the compliance burden and the certifications, unless the group is large enough to run its own regulatory function.
Differentiating capability is where the group’s own patient experience, data and workflow create an advantage: the patient app’s journey design, the CRM logic that decides who gets followed up and how, the contact-centre orchestration that routes by intent, the analytics layer that unifies data across units. This is where build, or build-on-a-platform, deserves serious consideration.
Most buy-versus-build arguments happen because someone is treating a commodity as a differentiator or a differentiator as a commodity.
The five questions that actually decide it
1. Who owns the data, and in what form?
The most expensive vendor decisions in healthcare are the ones that leave the group’s patient data inside a system it cannot fully extract. Ask for the export format, the API coverage and the exit terms before you ask for the price. If the answer to “can we get all our data out in a usable structure at any time” is anything other than an unqualified yes, the product is a rental of your own data.
2. What is the true cost over five years?
Licence fees are the visible cost. The invisible ones: integration with the HIS and other systems, customisation, per-user and per-unit scaling, mandatory upgrades, professional services, and the internal team needed to manage the vendor. For a build: the engineering team, the platform costs, the ongoing maintenance, and the cost of the capability being unavailable during the build. Compare the five-year totals, not the year-one licence against the year-one salary bill.
3. How fast does the need change?
If the capability will be stable for years, a vendor’s roadmap is probably adequate. If the capability sits at the centre of a patient experience the group intends to keep changing, vendor release cycles and customisation queues become the bottleneck. A rough test: if the group would want to change it monthly, it is a differentiator and a build candidate.
4. Does the vendor understand Indian healthcare?
A global platform built for a different market will lack things that are non-negotiable here: multilingual patient communication, WhatsApp as a primary channel, TPA and cashless workflows, government scheme integration, ABDM compatibility, Indian data-residency requirements, and the reality that the patient’s phone number belongs to a family member. A vendor that has to build these for you is a vendor whose product you are financing.
5. Can we hire and retain the people to build and run it?
The honest constraint on building is not money. It is whether the group can attract and keep engineers and product managers in a market where technology companies pay more and offer more interesting work. A build plan without a credible answer to hiring and retention is a plan to end up with an unmaintained system and a vendor call two years later.
The third option: build on a platform
The binary is false. The most durable pattern in healthcare digital is to buy a platform for the commodity and regulated layers, and build the differentiating logic on top using the platform’s extension points. A CRM platform, for example, is bought; the patient-journey logic, the segmentation rules and the integrations with the HIS are built by the group’s team on that platform.
This works when the platform has genuine extensibility: open APIs, a scripting or workflow layer, and a data model the group can extend. It fails when the platform’s “customisation” is a professional-services engagement with the vendor. Test extensibility in the pilot by building something small and real, not by reading the brochure.
The patterns that repeat
The point solution that becomes a platform by accident. A group buys a chatbot. Then a WhatsApp tool. Then a feedback tool. Then a campaign tool. Each was a sensible purchase. Together they are five patient-communication systems with five patient identities and no shared history. Decide the platform layer before buying the first point solution, or accept that a consolidation project is coming.
The build that becomes a product company. A group builds a good patient app. Leadership notices that other hospitals would pay for it. The internal team is now split between serving the group and serving customers, and the group’s own roadmap slows. Unless the group intends to become a software company, keep the build focused on the group’s own needs and license it out, if at all, only with a separate team.
The vendor that is really a services firm. The demo is a product; the delivery is a project. Every requirement is a change request; every integration is a statement of work. This is common in Indian healthcare IT. The tell is that the vendor’s reference customers all run materially different versions of the “product”. Price the professional services explicitly and cap them contractually.
The HIS vendor that wants to be everything. The hospital information system vendor offers a patient app, a CRM, a contact-centre module and analytics. The integration is seamless because it is all one system. The lock-in is total for the same reason. Take the HIS vendor’s modules for regulated, tightly coupled functions and resist them for patient-facing experience, where the group needs to move faster than an HIS release cycle.
Running the decision
- Classify the capability as commodity, regulated or differentiating. Write down why.
- Define the five-year requirement in terms of patient and operational outcomes, not features.
- Answer the five questions for each option, in writing, with the finance and IT heads co-signing the cost model.
- Pilot before committing. For a vendor, a paid pilot on one unit with real integration and real data. For a build, a working slice of the differentiating logic within one quarter. Both should have a pre-agreed success threshold.
- Negotiate exit before entry. Data export, contract termination, transition assistance and IP ownership of any customisation, all agreed before signing.
- Name the owner inside the group who is accountable for the capability regardless of who builds it. Vendors do not own outcomes; people do.
What I’d push back on
The claim that building is always cheaper. It is cheaper in year one and frequently more expensive by year three, once maintenance, attrition and opportunity cost are counted.
The claim that buying is always safer. Buying the wrong platform, or buying five point solutions that do not share data, is the most common way hospital groups spend heavily and end up with nothing that works together.
The claim that the decision is about technology. It is about data ownership, speed of change, and the people the group can retain. Get those three right and the technology choice is usually obvious.
A worked classification
Apply the framework to the typical hospital digital stack and the pattern becomes clear.
Buy outright: SMS and WhatsApp business messaging, payment gateway, email, video consultation infrastructure, form and survey tools, analytics collection, consent and cookie management, the HIS, LIS, RIS and PACS. The group has no reason to be better than the market at any of these and every reason to keep them compliant.
Buy a platform, build on it: the CRM and marketing automation layer, the contact-centre platform, the chatbot and voice framework, the data warehouse and reporting layer. The platform provides identity, storage, channels and compliance; the group builds the patient-journey logic, the segmentation, the intent handling and the dashboards that reflect how it actually operates.
Build, usually on a platform: the patient app’s experience layer, the doctor and service-line content system with its fact base, the internal analytics that unify data across units, and any integration layer that connects the HIS to everything else. These are where the group’s data and workflow are the product, and where speed of change matters most.
Almost never build: anything regulated, anything where a vendor’s scale delivers reliability the group cannot match, and anything the group would not be able to staff in year three.
Contract terms that matter more than price
When buying, five clauses determine whether the relationship survives.
- Full data export in a documented, structured format, on demand, at no additional cost
- Ownership by the group of all configuration, customisation and integration code written for it
- Capped professional-services rates and a defined change-request process
- Data residency in India and compliance with Indian data-protection law, with audit rights
- Transition assistance on termination, with a defined duration and scope
A vendor who agrees to all five is a partner. A vendor who resists any of them has told you how the relationship will end.
If you have a decision in front of you this quarter
- Classify it. If it is commodity or regulated, stop deliberating and buy well.
- If it is differentiating, look for a platform to build on before considering a full build.
- Get the data-ownership and exit terms in writing before you look at price.
- Pilot with real integration, real data and a threshold.
- Be honest about who will maintain it in year three.
Buy the plumbing. Build the experience. Own the data either way.
Questions people ask
Commodity capability is what every hospital needs and nobody differentiates on: SMS, payments, reminders, forms, basic analytics. Buy it. Regulated capability carries compliance obligations that are expensive to get right — EHR, e-prescriptions, LIS, PACS, consent tooling. Buy it from a vendor who carries the certifications. Differentiating capability is where your own patient journey, data and workflow create advantage: CRM logic, contact-centre routing, the app experience. That is where building deserves serious thought.
When the capability sits at the centre of a patient experience the group intends to keep changing. A rough test: if you would want to change it monthly, it is a differentiator and a build candidate. Even then, the best pattern is usually to buy a platform for the commodity and regulated layers and build the differentiating logic on its extension points. A full ground-up build is rarely the right answer for a hospital group.
Licence fees are the visible part. The invisible costs are integration with the HIS and other systems, customisation, per-user and per-unit scaling, mandatory upgrades, professional services and the internal team needed to manage the vendor. For a build, count the engineering team, platform costs, ongoing maintenance and the cost of the capability being unavailable while it is built. Compare five-year totals, not year-one licence against year-one salary.
You buy a platform — a CRM, a contact-centre system, a chatbot framework, a data warehouse — for identity, storage, channels and compliance, and your own team builds the patient-journey logic, segmentation rules, intent handling and dashboards on top using its extension points. It works when the platform has open APIs, a workflow layer and an extensible data model. It fails when customisation turns out to be a professional-services engagement with the vendor. Test extensibility in the pilot.
Five clauses decide whether the relationship survives: full data export in a documented, structured format on demand at no extra cost; group ownership of all configuration, customisation and integration code written for it; capped professional-services rates with a defined change-request process; data residency in India with compliance with Indian data-protection law and audit rights; and transition assistance on termination with a defined duration and scope. A vendor who resists any of them has told you how it ends.
The hospital should, in a form it can actually use. The most expensive vendor decisions in healthcare leave patient data inside a system the group cannot fully extract. Ask for the export format, the API coverage and the exit terms before you ask for the price. If the answer to whether you can get all your data out in a usable structure at any time is anything other than an unqualified yes, you are renting your own data.
This is the honest constraint on building, and it is not money. Technology companies pay more and offer more interesting work, so a hospital group has to be clear-eyed about whether it can attract and keep engineers and product managers for years. A build plan without a credible answer on hiring and retention is a plan to end up with an unmaintained system and a vendor call two years later.
Take the HIS vendor’s modules for regulated, tightly coupled functions, where integration is genuinely seamless because it is one system. Resist them for patient-facing experience, where the group needs to move faster than an HIS release cycle. The seamlessness and the lock-in come from the same fact. A group that puts its entire front door inside the HIS will find every experience change waiting in the vendor’s customisation queue.
For a vendor, a paid pilot on one unit with real integration and real data — not a demo environment — with a pre-agreed success threshold. For a build, a working slice of the differentiating logic within one quarter. Both should be judged against the threshold set before the pilot started, not against how the team feels about it afterwards. A pilot without a threshold is a delayed purchase decision.
A chatbot, then a messaging tool, then a feedback tool, then a campaign tool. Each was a sensible purchase. Together they are five patient-communication systems with five patient identities and no shared history. Decide the platform layer before buying the first point solution, or accept that a consolidation project is coming. This is the most common way hospital groups spend heavily and end up with nothing that works together.
No. Building is cheaper in year one and frequently more expensive by year three, once maintenance, attrition and opportunity cost are counted. The reverse claim — that buying is always safer — is also wrong, because buying the wrong platform or five point solutions that do not share data is the most reliable way to waste a digital budget. The decision is about data ownership, speed of change and people, not about cost alone.
The demo is a product; the delivery is a project. Every requirement becomes a change request and every integration a statement of work. The tell is that the vendor’s reference customers all run materially different versions of the same product. This is common in Indian healthcare IT. If you still want to buy, price the professional services explicitly and cap them contractually, and get the change-request process in writing before signing.
Usually not. Once leadership notices other hospitals would pay for a good internal build, the team is split between serving the group and serving customers, and the group’s own roadmap slows. Unless the group intends to become a software company, keep the build focused on its own needs. If licensing it out is unavoidable, do it with a separate team so that the hospital’s product does not become the second priority.
A named owner inside the group, regardless of who builds it. Vendors do not own outcomes; people do. Have the finance and IT heads co-sign the five-year cost model so that the decision is shared, but keep the accountability for the capability — its adoption, its results, its data — with one person. Many failed hospital platforms were technically delivered and never owned by anyone.
