Every cancer program that decides to take survivorship seriously arrives at the same fork: build it yourself, or use something built for the purpose. The honest answer is that both are right in different situations, and the deciding factors are rarely the ones that come up first in the meeting. This is a criteria-based way to make the call, with no vendor names and no pretending that building is always the wrong move.
What does building a survivorship program in-house actually involve?
Building in-house means assembling four things yourself: clinical content across the survivorship domains, a patient-facing product, a way to get structured information back to the care team, and someone to maintain all of it. Most teams underestimate the fourth. Content ages, and an unmaintained program quietly stops being used.
The content job is bigger than it looks. Survivorship spans physical recovery, emotional health, sexual health, work and finances, relationships, and long-term surveillance. Writing plain-language, accurate material across all of that, and keeping it current as guidelines shift, is a standing editorial commitment rather than a one-time project. Our overview of the seven domains of survivorship gives a sense of the surface area involved.
The product job is the part organizations usually plan for and still underestimate. A patient-facing tool needs onboarding, reminders, accessible design, mobile behavior, translation if your panel needs it, accessibility review, security review, and a support path for when a patient cannot log in. None of that is exotic engineering. It is simply a real product, and real products need a team that owns them past launch.
Then there is the return path. Information a patient enters between visits is only useful if it reaches the care team in a form a clinician can read in under a minute. Building that means agreeing on what gets summarized, how it appears in the chart, and who reviews it. Programs that skip this step end up with engagement data nobody uses.
On cost, keep the framing simple and qualitative. Building is capital plus ongoing engineering time, and the ongoing part does not end. Reasonable people can disagree about the size of that number, but nobody should model it as a one-year expense.
What does using a platform involve?
Using a platform means the content, the patient experience, and the maintenance already exist, so your work shifts to configuration and workflow. You decide which patients are invited, what your team sees, and how it fits your visits. Cost becomes a scoped subscription instead of an open-ended engineering commitment.
The work does not disappear, it changes shape. Someone still has to own the program internally: choosing the patient cohort, deciding when invitations go out, and making sure the summary lands somewhere a clinician actually looks. That is usually a part-time responsibility for a nurse navigator or program coordinator rather than a new hire. Our guide to how to start a survivorship program walks through that operational side in more detail.
There are also real trade-offs to name. You are accepting someone else's model of survivorship, which means you influence the roadmap rather than control it. You are depending on a vendor's continuity. And you need to confirm the data arrangement fits your governance rules before anything goes live. Those are legitimate reasons to push hard in evaluation, and they are exactly the questions a serious buyer should ask.
What you get in exchange is time. A program can be running with patients this quarter rather than after a build cycle, and the between-visit experience is maintained by someone whose full-time job it is. For a fuller picture of the category, see what a digital survivorship platform is.
How do the two compare?
On most criteria the difference is not quality, it is time and who carries the load. Building gives you full control and costs sustained engineering and editorial effort. A platform gives you speed and maintained content and costs you some control. The table below sets the two side by side.
Here is the same set of criteria applied to both paths, stated plainly.
| Criterion | Build in-house | Use a platform |
|---|---|---|
| Time to launch | Typically a year or more | Weeks |
| Staffing load | Engineering, clinical content, and product roles | One part-time program owner |
| Patient-facing continuity | You design and maintain it | Included and kept current |
| Documentation support | Custom work for each summary | Structured summaries included |
| Upkeep | Ongoing engineering and content review | Carried by the vendor |
One row deserves a note. Documentation support here means producing a clear record of what a patient reported and what was addressed between visits, which supports accurate documentation of care complexity within existing Medicare care management pathways. The specifics vary by program and are better walked through on a demo call than generalized in an article.
When does building in-house make sense?
Building wins more often than vendors admit. If you already run an internal software team alongside a clinical content group, if your survivorship workflow is genuinely unusual, or if you need full control of the instrument for research, building is the better decision. In those cases a platform is a constraint, not a shortcut.
The first case is capability you already have. Some cancer programs sit inside organizations with a mature internal software group and a clinical content team that already writes and reviews patient education. If both exist and have capacity, the marginal cost of adding survivorship is far lower than it would be for a program starting from zero. You also get something no vendor can sell you: a tool shaped precisely around how your clinicians work, integrated with systems you already own, on your own release schedule.
The second case is genuine workflow oddity. Most survivorship programs look broadly alike, which is why products exist. But some do not. If your program is organized around a disease group with unusual surveillance patterns, or built around a care model that no general product represents well, configuration will keep feeling like a fight. Bending a platform into an odd shape is worse than building the right shape once.
The third case is research, and it is the strongest one. If survivorship data is going to support publishable work, you need control of the instrument: exact item wording, version history, defensible data provenance, and the freedom to change measures for a protocol without waiting on someone's roadmap. That level of control is hard to obtain from a commercial product, and researchers are right to insist on it. A vendor may run an IRB-approved feasibility study within a large health system's survivorship program, but that is a different thing from you owning the instrument yourself.
There is a fourth, quieter case: strategic differentiation. If survivorship is central to how your organization positions itself, and leadership intends to fund it as a durable capability rather than a project, building can be the right long-term choice even when the near-term math favors buying. The failure mode to watch for is enthusiasm without a maintenance budget. A build that launches well and then loses its team is worse than no build at all, because patients were invited into something that stopped being tended.
What should you evaluate either way?
Use the same criteria for both paths. If you hold a build and a platform to one standard, the comparison stops being ideological and becomes a decision about fit, timing, and who carries the work in year three. These are the questions worth answering before you commit either way.
- Clinical coverage. Does it address the full breadth of survivorship, or only symptom tracking? Ask which domains are covered and how content is reviewed.
- Time to first patient. Not time to contract or time to code complete. How long until a real survivor is using it.
- Clinician burden. How many seconds does it take a clinician to get value from what a patient submitted? If the answer is more than a minute, it will not survive a busy clinic.
- Continuity between visits. What happens in week six, when nobody has an appointment? This is where survivorship programs actually live or die.
- Documentation output. Does it produce a usable record of what was reported and addressed, and does that record reach the chart?
- Maintenance owner. Name the person or team responsible in year three, for both paths. If you cannot, you have found your answer.
- Data and governance fit. Where does the data live, who can access it, and does that satisfy your own review process before launch, not after.
- Patient experience. Sit with the actual product a patient would use. Would you send it to someone in your family after treatment? Pair this with a look at how a survivorship care plan fits into the same journey.
Oncera is on one side of this comparison, and we would rather be chosen for fit than by default. If speed, maintained content across all seven domains, and low clinician burden are what your program needs, see how Oncera works for clinics. If you have the team and the reasons to build, build it well.
This article is general educational and operational guidance for cancer programs, not medical, legal, or procurement advice. Clinical decisions and survivorship care plans remain the responsibility of the treating care team.