The build-operate-transfer model is an arrangement where a partner builds your software, runs it in production until it's stable and your team is ready, then hands over the code, cloud accounts, documentation and runbooks on a date you choose. In healthcare it gets a platform live without hiring a full engineering and operations team on day one. Digital Scientists built CommuniCare's MDS platform from April 2024, ran it through rollout, then handed it to CommuniCare's own team. It has recovered $10M+ to date, with $24M+ in forecast PDPM revenue.
What is the build-operate-transfer model?
It's three phases with one team accountable through all of them. The partner builds the platform, operates it in production with monitoring, releases, security updates and support, and then transfers it to your team or your MSP when you decide the time is right.
In healthcare software it solves a specific problem: the people who build a clinical platform know where it breaks, and the first months in production are when it breaks most. Build-operate-transfer keeps those people on call through that stretch, then moves the knowledge to you on purpose instead of by accident. It's the back half of our healthcare platform operations practice: we run what we build, or hand it over when you're ready.
Why use build-operate-transfer for healthcare software?
Because operations, not launch, is where healthcare platforms prove themselves. A nurse calling for backup at 3 AM needs the platform to work. Your integrations will break when a vendor changes something. HIPAA doesn't pause while you hire.
Founders and operators use the model to get a product live before they have an engineering lead, an on-call rotation and a release process of their own. You get a team that is accountable for uptime and outcomes, not just code quality, and you still own everything. The code and IP are yours, and the repositories sit in your organization from day one.
How does build-operate-transfer compare with the alternatives?
Each path trades speed against how much you own and run yourself.
| Build in-house | Partner builds, you run it from launch | Build-operate-transfer | |
|---|---|---|---|
| Time to live | Hiring time, then the build | The build, but launch lands on a team that hasn't run it | The build; the builders run it through rollout |
| Who's on call early | Your new team, learning as it goes | Your team, without the people who wrote the code | The engineers who built it |
| Ownership | You own the code, IP and roadmap | You own the code, IP and roadmap | You own the code, IP and roadmap from day one |
| Knowledge transfer | Not needed | A handoff at launch, often thin | Gradual: your engineers work releases and incidents alongside ours, then lead |
| Best when | You already have a product and operations team | The platform is simple and low risk once live | The platform is clinical, integrated and has to stay up |
What does the operate phase include?
Everything it takes to keep a clinical platform up: monitoring with on-call paging, scheduled releases, security updates, L2 and L3 support and every third-party integration, done by the engineers who built it. Your IT team or MSP keeps L1, users, desktops and network. We don't run a helpdesk.
NeverAlone shows what that looks like over years, not months. We built it as a 90-day MVP for CommuniCare and have run it 24/7 since March 2021. It now serves 30,000 patients across six states, handles 100,000+ calls a year, answers in under 3 minutes, and holds a 96% treat-in-place rate. Every one of 750+ managed iPads is checked every two hours for battery and network. When a telephony provider moved to a new sign-in method, we moved NeverAlone's E911 connection to it and re-tested address validation and callback numbers. See the NeverAlone case study.
Running a platform every day keeps us grounded in the challenges of everyday care delivery. It's also what makes the transfer work: the runbooks are written by people who have used them at 3 AM.
What do you get at transfer?
You get everything needed to run the platform without us. Most of it is already yours before the transfer starts.
- Code and IP. Repositories in your organization with full history, branches and build pipelines. Yours from day one.
- Cloud accounts. Accounts in your name. Admin access moves to your team and ours is removed.
- Documentation. Architecture, data flows, integration specs, the security plan and a log of key decisions, kept current while we run it.
- Runbooks. How to deploy, roll back, rotate credentials, answer each alert and reach each vendor, rehearsed with your team.
- Knowledge. Your engineers run releases and incidents with ours until they lead them, over a transition period we agree with you.
How did CommuniCare's MDS platform go from build to transfer?
We built it, ran it through rollout, then handed it to CommuniCare's own team. That's build-operate-transfer in practice.
The platform gives MDS coordinators in CommuniCare's skilled nursing facilities AI recommendations built on PointClickCare data. It scans for 200+ clinical events that change an MDS assessment and surfaces each recommendation inside the PointClickCare workflow, linked to its source documentation, for the coordinator to validate. We started in April 2024 and supported the rollout with on-site go-live support. Once the platform was stable and CommuniCare's team was ready, it moved to them.
The results stayed with the platform: $10M+ recovered to date, and $24M+ in forecast PDPM revenue. Read the CommuniCare MDS case study for the full story.
What breaks a transfer, and how do you avoid it?
Transfers fail on the things nobody wrote down: a credential only one engineer knew, a vendor contact in someone's inbox, an integration quirk that lived in a Slack thread. Plan for the handover from the first sprint and those gaps never form.
- Code in your repositories from day one. Nothing to migrate at the end, and no question about who owns it.
- Vendor contracts in your name. You hold the EHR, telephony, video and cloud contracts. We open and manage vendor cases while we run the platform, then your team does.
- Runbooks written while operating. Every alert, deploy, rollback and credential rotation gets documented when it happens, not reconstructed at handover.
- Access that is easy to remove. Least-privilege access for each party, logged, so removing ours at transfer is a checklist item.
When is your team ready to take over?
When the platform has been through a few release cycles without surprises and someone on your side can lead it. The common triggers: you've hired an engineering lead, the platform is stable, or an investor or acquirer wants the team in-house.
The handover is gradual. Your engineers work real releases and incidents alongside ours, then take the lead with us as backup, then we step back. If you'd rather your MSP run the platform, that's a transfer too, with the same runbooks, documentation and side-by-side handover. Some clients never transfer. CommuniCare took the MDS platform in-house and kept us running NeverAlone. You pick the timing.
Where does a build-operate-transfer start?
It starts with a platform we build. We support only platforms we built, because we can't stand behind code we don't know.
If you're starting fresh, operations is planned in the Blueprint and built in from the first sprint: monitoring, runbooks, release process and who owns L1. See healthcare product development. If someone else built your platform, start with the platform modernization assessment, $25K over four weeks, then we rebuild or harden what needs it and run what we've built. If we built it and your team wants it now, move straight to a transfer plan. To work out which fits, talk it over with us.
Frequently asked questions
What is the build-operate-transfer model?
A partner builds your software, runs it in production until it's stable and your team is ready, then hands over the code, cloud accounts, documentation and runbooks. You choose when the transfer happens.
Who owns the code during the operate phase?
You do. The code and IP are yours, and the repositories sit in your organization from day one. Running the platform doesn't change ownership; it only changes who is on call.
How long does the operate phase last?
Until the platform is stable and your team is ready. Common triggers are hiring an engineering lead, a few release cycles without surprises, or an investor or acquirer wanting the team in-house. The handover itself runs over a transition period you agree with us.
Can our MSP take over instead of our own team?
Yes. Handing the platform to your MSP works the same way: the same documentation, runbooks and side-by-side transition. Many clients keep their MSP on L1 and the desktop and keep us on L2 and L3 instead.
Will Digital Scientists run a platform someone else built?
Not as-is. We support only platforms we built. For a platform someone else built, start with the platform modernization assessment ($25K, four weeks), then we rebuild or harden what needs it and run it.
Do you sign a BAA during the operate phase?
Yes. We sign a BAA with every covered entity before we touch patient data. Our security plan is mapped to NIST CSF 2.0, and each client gets a security addendum.
