The fractional, forward deployed CTO.
One person, two jobs, done in the codebase. The fractional CTO and the forward deployed engineer are usually sold as different products. For healthcare operators, they are the same product, and splitting them is the reason most engagements stall.
Executive read
- Healthcare operators keep buying two roles when they need one. A fractional CTO who advises on strategy without touching the code, and a forward deployed engineer who ships code without sitting in the strategy room. The seam between them is where most healthcare AI engagements die.
- The model that works is one senior person who writes the merge commit and attends the board call. Strategy without code context becomes abstract. Code without strategic alignment optimizes the wrong thing. Healthcare makes the seam worse because compliance, clinical workflow, and EHR interop are properties of the code, not the deck.
- Cara's view: the fractional CTO and the forward deployed engineer should be the same hire for any healthcare operator under fifty engineers. The contract should reflect it.
The market is selling two halves of one job.
The fractional CTO market in 2026 is dominated by advisory work. Calendar meetings, strategic opinions, board prep, vendor selection. The deliverable is judgment, delivered in a room. The forward deployed engineering market, by contrast, ships code inside the customer's repository but is structurally excluded from the planning conversation. The FDE knows what the code is. The fractional CTO knows what the company should do. The customer pays for both and gets neither.
The split is a sales-side convenience, not a buyer's requirement. Strategy disconnected from code becomes wishful. Code disconnected from strategy gets optimized against the wrong target. The handoff between the two is the costliest seam in healthtech and the seam where most AI engagements quietly fail.
What the role actually looks like.
One senior engineer, on the vendor's payroll, with enough tenure to defend an architecture decision in front of a board and enough current familiarity with the codebase to merge the PR that implements it. The week is split roughly in half.
Monday is engineering. Standup, queue triage, pair programming with the customer's developers, code review on anything that touches PHI or billing. Tuesday is planning. Architecture decisions, founder memos, vendor calls, the harder of the integration questions. Wednesday is production code. Thursday is the strategy room. Board calls, safety evaluations, hiring loops. Friday is written: workflow evaluations, incident postmortems, the weekly summary the customer's executive sponsor signs.
The split is not a constraint. It is the whole point. The person who merges the commit is also the person in the board meeting. Neither half is delegated. Neither half is translated.
Healthcare is the domain where the split hurts most.
Compliance is a code property. HIPAA, SOC 2, and the specific scope of a BAA show up as audit logs, schema design, prompt routing, and which model provider sees which payload. They do not show up as slides. A fractional CTO who has not read the implementation cannot defend the audit. An FDE who has not sat in the legal call does not know which clauses the implementation needs to satisfy.
Clinical workflows are unforgiving. Software used by a clinician under load fails in ways that are not visible in a feature spec. Architectural decisions, retry behavior, queue depth, idempotency on a scheduling write, all have to be grounded in real failure modes. Those failure modes are visible from inside the code or from inside the workflow. Rarely from inside a strategy meeting alone.
EHR interop is brownfield. Epic, Cerner, AdvancedMD, Athena, eClinicalWorks. FHIR where it works, HL7v2 where it does not, a CSV drop where neither does. The decisions about how to integrate are simultaneously strategic (which surface area, on what timeline, against which vendor relationship) and technical (which auth flow, which sandbox, which payload). Splitting the person who decides from the person who implements adds a translation layer healthcare cannot afford.
Where this engagement actually fits.
Post-seed, pre-Series A operators where product-market fit exists and the founder needs senior technical authority without a full-time CTO salary on the cap table. The model is cheaper than the hire and faster than the search.
Brownfield modernization inside an MSO or CIN inheriting incompatible stacks. The work is part architecture (which system stays, which goes, what the integration backbone looks like) and part code (the actual migrations, the data reconciliation, the auth surface). One senior person can hold both.
Pre-clinical launch where the safety architecture and the medical director conversation are happening in the same month. The fractional CTO needs to know what the code does to write the medical director memo. The engineer needs to know what the medical director said to write the code.
CTO transition bridges. A departing CTO, a recruiting process measured in quarters, and a system that has to keep shipping. A fractional, forward deployed CTO holds both the architecture and the room until the permanent hire lands.
When it is the wrong model.
When a full-time CTO hire is feasible and the candidate is available, hire the full-time CTO. The model is a bridge, not a destination.
When the company culture requires long-tenured employees in the senior technical seat, fractional anything will rub. The model assumes the operator is comfortable with senior outside leadership.
When the operator actually wants advisory work, decoupled from code, the fractional CTO market already serves that need. Do not pay for an FDE you will not let into the repository.
How the deal should be structured.
Quarterly retainer with consistent senior involvement. The same person at kickoff is the person merging the commits. Named individual, written into the SOW, with a notice period if rotation is ever proposed and a customer right to interview a replacement.
Full IP transfer in the MSA, not buried per-SOW. Everything the engagement produces, code, infrastructure, evaluations, runbooks, lives with the customer. No perpetual licensing. No second engagement required to operationalize the first.
Clean exit at engagement end. A 90-day exit ramp written into the engagement at the start, with knowledge transfer obligations, documentation standards, hiring support for the customer's internal team, and a price for the transition. The model assumes the customer will eventually run the system without the vendor in the room. The contract should make that assumption real.
The entry point.
Cara's entry point for this engagement is a two-week architecture read. One senior engineer, on Cara payroll, on-site for the discovery and remote for the synthesis. The deliverable is a written architecture analysis: what the stack is, what is load-bearing, what is fragile, where AI fits cleanly, where it does not, what the next ninety days should look like, and what the buyer would be signing up for if the engagement extended.
No team commitment, no platform lock-in, and no obligation to extend. The read either earns the longer engagement or it does not. Either way the customer keeps the document.
Related reading.
For the broader argument about why Forward Deployed Engineering is the right operating model for healthcare AI in 2026, see Forward deployed engineering for healthcare. For the buyer-side checklist of ten questions every healthcare operator should require a vendor to answer in writing before signing an FDE-style engagement, see The FDE pod versus the consulting engagement. For Cara's own definition of an Embedded engagement (FDE plus PM, on Cara payroll, on-site at meaningful intervals, with contractual IP transfer and a written exit ramp), see Cara Embedded Services.
Sources
- Cara, Forward deployed engineering for healthcare ↗
- Cara, The FDE pod versus the consulting engagement ↗
- Cara Embedded Services ↗
- Nils Widal, The fractional, forward deployed CTO ↗
- Palantir, A day in the life of a Forward Deployed Software Engineer ↗
- CIO.com, Forward Deployed Engineers as the new AI limiting factor (Gartner) ↗