Product decisions
Should your clinic build or buy a patient portal?
Buy when an existing product fits the service. Build when a specific, valuable journey cannot be supported well enough by the tools available to you.
“We need a patient portal” can mean several different things. One clinic wants patients to book follow-ups without phoning. Another needs ongoing information submissions and a staff review queue. A third wants a branded home for instructions and progress between appointments.
Those are different product decisions. Start by describing what the patient must be able to complete and what the team needs to do afterwards. Only then compare an existing product with a bespoke build.
Check what you already have
Your current practice or booking system may already offer part of the journey. A feature that is poorly configured, difficult to find or badly explained can look like a missing capability. Check the actual patient experience before buying a second tool.
Walk through it on a phone. Try returning after several weeks, recovering an account and changing a detail. Ask the staff member receiving the request whether the information lands somewhere useful. A feature-list tick is not the same as a completed journey.
When buying makes sense
An established product is worth considering when the workflow is common, its configuration supports your service and the team can operate it comfortably. Buying can reduce how much software you are responsible for maintaining, although configuration, integration, support and supplier oversight still take work.
Ask the supplier to demonstrate your journey with realistic examples. Check what happens when the patient has missing information, cannot sign in, needs support or changes an appointment. Ask how records can be exported and what happens when the contract ends.
When a bespoke portal earns its place
A focused build is more compelling when the service has a distinctive repeat journey, the current tools create substantial manual work, or patients and staff need a shared experience that available products cannot provide without awkward workarounds.
That does not mean building a clinical record system from scratch. A portal can provide a carefully scoped patient-facing layer while existing systems retain their defined responsibilities.
CadenceRx shows founder work at Cadence Health connecting a patient journey with the operation behind it. Nudge shows a companion-app approach to support between appointments. The useful question is which part of your service needs that sort of continuity—not whether it should copy either product wholesale.
Compare the whole commitment
| Question | What to establish |
|---|---|
| Does it fit the journey? | The patient can complete the actual task, including exceptions. |
| Does it connect? | The team receives usable information without another copying job. |
| Who runs it? | Support, access changes, updates and incident ownership are explicit. |
| What does it cost over time? | Include implementation, licences, hosting, maintenance and change. |
| Can you leave? | Understand data export, ownership and transition arrangements. |
For a bespoke build, agree who owns the source code, how the service is hosted and who responds when it fails. For a bought product, ask the equivalent questions about supplier responsibilities and contractual limits. Neither route removes the clinic’s need to understand how its service operates.
Scope the first release around one outcome
A useful first brief might be: returning patients can review their details, submit one type of follow-up request and see what happens next; staff can receive, review and resolve it. That gives both sides a complete journey to test.
Account recovery, staff permissions, appropriate data protection and a non-digital fallback belong in that initial discussion. Clinical review rules belong to the responsible clinical team. Removing unnecessary friction should not remove necessary checks.
A demo can show whether an idea makes sense. A pilot should establish whether people can use it and the team can support it. Wider rollout should follow what those checks reveal. You do not need to commit to every future feature to make the first journey work.