Free Guide · Platform Strategy
The question isn't "can we build this." It's "do we want to own the maintenance, the support, and the staying-current burden for the next three years?" Here's the framework we use to answer it.
Use this before any significant platform decision — EHR evaluation, custom tooling, third-party integrations, infrastructure components. It works for "should we build this feature ourselves?" and for "should we license this vendor's product?" The goal is to surface the costs that don't appear in a demo or a vendor proposal.
The Five Questions
Question 1 of 5
What is the true total cost of ownership?
The number that matters isn't the licensing fee. Most teams look at line-item cost in isolation. True TCO includes five components that rarely appear in a vendor proposal:
The licensing fee is the number everyone sees. The maintenance tax is the number that kills velocity.
Question 2 of 5
What does this cost when we're 3× our current size?
The most expensive decisions in digital health aren't the ones that fail immediately. They're the ones that succeed for 18 months — and then become the ceiling.
Answer the TCO question twice: once for today, and once assuming you're 3× your current size (headcount, patient volume, clinic count, whatever your primary growth axis is). The platform chosen at 10 clinics may be the wrong answer at 30. The EHR chosen for 5,000 patients may not survive to 50,000.
If the answer changes dramatically at 3×, that's not disqualifying — but it should be explicit in the decision. "We're choosing this knowing we'll probably migrate in two years" is a valid decision. "We didn't think about it" is how you end up with an emergency migration.
Free Guide
Enter your email to read all 5 questions, the TCO breakdown, and the decision matrix — plus new guides as they're published.
Question 3 of 5
Do we want to own the maintenance and staying-current burden?
Build vs. buy isn't a binary anymore. It's a spectrum: build from scratch, build on OSS, buy and extend, buy and integrate, buy and trust. But across all of them, the core question is the same: who owns the maintenance?
When you build, you own everything — the feature, the bug fixes, the upgrades, the security patches. When you buy, you're betting that the vendor's incentives stay aligned with yours. When you partner, you're layering dependencies.
Ask: in 18 months, when this needs to be updated because your product has evolved or their API has changed, who does that work? What does it cost? Is that a sustainable answer at scale?
A good rule of thumb: if you're not willing to staff a team to maintain it, don't build it.
Question 4 of 5
Does this touch our core differentiation?
There are two categories of technical decisions: things that make you different, and things that keep the lights on.
Things that make you different — proprietary clinical workflows, unique care models, patient engagement mechanics that are yours — should almost always be built. These are the things that are hard to replicate and are central to your value proposition. Buying them means your differentiation is someone else's product.
Things that keep the lights on — billing logic, authentication, document storage, calendar management — should almost always be bought. The cost of building these things right is high, and the competitive advantage of building them yourself is zero.
The expensive mistake is getting this backwards: building commodity infrastructure when you should be buying, and buying differentiating product when you should be building.
The subtler version: the distinction isn't always at the feature level — it's often at the layer level. A single capability can have a backend primitive you should buy and an experience layer you should build on top of it. Scheduling is the clearest example. The engine itself — availability windows, calendar management, appointment creation — is commodity infrastructure. The patient-facing flow on top of it — which provider routes to this patient type? which visit types are available at which stage of care? what conditional logic governs eligibility? — is where your differentiation lives. Buy the scheduling engine. Build the scheduling experience.
Question 5 of 5
What's the migration cost if we get this wrong?
Every platform decision has a reversal cost. Not accounting for it is how teams end up locked into the wrong tool indefinitely — not because migrating is impossible, but because the cost of migrating never feels lower than the cost of staying.
Before committing: map the exit. What data would you need to export? In what format? How long would a migration realistically take? What would it break, and for how long? Is there an established migration path, or would you be improvising?
A platform with a high migration cost requires different contractual protections and architectural guardrails than one where leaving is straightforward. Both can be right choices — but only if you've accounted for the difference.
TCO Breakdown: What to Model
| Cost component | What to include | What teams often miss |
|---|---|---|
| Licensing / subscription | Annual contract value; per-seat or per-patient pricing at your current scale | ↑ Pricing tiers that kick in as you grow — what does this cost at 3× patients? |
| Implementation | Setup, configuration, data migration, staff training | ↑ The time your internal team spends on vendor management and user onboarding — not just the vendor's hours |
| Integration engineering | Hours to wire into existing stack, API work, custom front-end development | ↑ Ongoing maintenance as both products evolve — not a one-time cost |
| Maintenance tax | Sprint hours per month on break/fix, workarounds, and EHR-related tickets | ↑ Opportunity cost: what doesn't get built because this gets prioritized instead |
| Migration / exit cost | Data export complexity, cutover time, staff retraining, downtime risk | ↑ The architectural debt that accumulates when teams design assuming they'll never leave |
"The question I ask before any build-or-buy decision: what will this cost us when we're 3× our current size, and will the team who maintains it still have capacity to build?"
— Alex Kramer, ARK FoundryDecision Matrix
| Scenario | Verdict |
|---|---|
| Core to your clinical differentiation; no vendor option fits your care model | Build |
| Commodity infrastructure (auth, document storage, calendar management) a vendor already does well | Buy |
| Commodity backend primitive, but your user-facing flow requires unique UX, routing logic, or care model–specific business rules (e.g. scheduling) | Buy infra + Build experience |
| Specialized capability you need once, not as an ongoing core system | Buy |
| You need the vendor's data network or distribution, not just the product | Partner |
| You need the feature fast; a vendor exists; you may rebuild it later when you have the team | Buy |
| The vendor's roadmap will diverge from your clinical model within 18 months | Build |
| You want ownership of the capability but can't staff the maintenance | Buy |
| You're acquiring a capability primarily for the proprietary data it will generate | Build |
From Practice
We recommended against a $50K acquisition. The sticker price was genuinely low for the asset's value. But integration cost was 3–4 months of engineering. Maintenance would have been 10–15% of a developer's time indefinitely. Opportunity cost: it would have delayed two features already on the roadmap and driving retention. The real cost wasn't $50K — it was closer to $400K when we modeled it honestly. We passed.
We chose Firebase over Postgres for the home exercise MVP. The argument for Postgres was correctness — it's the right long-term answer for structured clinical data. The argument for Firebase was that we needed to ship in 6 weeks, we had no DBA, and this was an MVP with an uncertain roadmap. Firebase's flexibility bought us optionality we couldn't afford to build. That decision held for 5+ years without a migration. Sometimes buying time is the right build/buy answer.
I bring pattern recognition from a decade of making these calls in digital health — including the TCO modeling that accounts for technical debt, team capacity, and competing priorities.
This framework reflects ARK Foundry's approach to platform decisions across digital health engagements at Series A and B. It is a practitioner's framework, not a universal formula — every decision has context that a matrix can't capture. Use it to surface the right questions before committing.