Build versus buy

The correct answer: A. The app is a strategic differentiator that no product meets, and the organization has skilled developers and can support the app long term

✅ Why this answer

Building in-house suits situations where three conditions come together:

• The solution is a strategic differentiator for the organization, and no product on the market meets it.
• Qualified internal capabilities for development exist.
• There is capacity for long-term support and maintenance, not just building.

❌ Why the other options are wrong

• (B): mature products that meet most of the need favor buying, with minor configuration.
• (C): without developers, building becomes a big risk or complete dependence on contractors.
• (D): a short deadline favors buying; building usually takes longer.

💡 Key concept

The initial cost of building is often counted while the cost of maintenance, updates and security over the system’s life is forgotten. So the total cost of ownership (TCO) of both options is compared. There is a middle option: buying a platform and configuring or extending it, or building on top of standard application programming interfaces (APIs).

In the exam: “a strategic differentiator no product meets + skilled developers + the ability to support it long term” = build. “Mature products meet most needs”, “a short deadline” or “no developers” = buy.

🔗 Related facts and questions

• Configuration or customization: configuration uses the vendor’s own tools, while customization changes the product’s source code.
  Practice question: the hospital wanted a special feature in a purchased product, so it changed the source code instead of using the configuration tools. What is the main risk later? → Harder upgrades; each new vendor release may undo or clash with the change, and needs retesting and rebuilding.
• Apps on top of the EHR through an open standard: a middle path between building everything and buying. SMART on FHIR (Substitutable Medical Applications, Reusable Technologies on Fast Healthcare Interoperability Resources) lets a small app run inside the electronic health record (EHR) and read its data through the open FHIR standard, so it can run with more than one EHR system.
  Practice question: a hospital wants its own dosing calculator inside the EHR screen, and may change its EHR vendor in three years. Which is safer: changing the EHR’s source code, or building a SMART on FHIR app? → A SMART on FHIR app; it connects through a standard interface and does not change the product’s code, so vendor upgrades are far less likely to break it, and it can move to another EHR that supports the standard.
• Sustaining an in-house app: in-house building does not end at delivery; the app needs people who understand its code years later. Relying on a single developer for that is called key person risk.
  Practice question: an app was built by one developer who did not document it; it works well, and the developer still works at the organization. The manager says nothing needs to be done now. Is that right? → No; the key person risk exists now, and dealing with it after the developer leaves is too late. It is reduced with documentation, code review and spreading knowledge across more than one person.
• Evaluating a purchase: it usually goes through a request for proposal (RFP), demonstrations with real scenarios, and contact with the vendor’s existing customers (reference checks).
• Vendor lock-in: buying ties the organization to the vendor’s roadmap and prices, so the exit and data-return terms are reviewed before signing.
• The best-of-breed approach: a related question in the full bank.
• The sunk cost: Sunk cost and opportunity cost.
• Total cost of ownership: "Total cost of ownership (TCO)" (in the full bank).