A patient portal is not simply a clinic website with a login button. If patients can book appointments, view test results, pay bills or retrieve private records, the project becomes a software system with identity, permissions, integrations and ongoing responsibilities.
For initial Nigerian budgeting in 2026, I would use ₦2 million–₦5 million for a focused custom self-service portal without clinical-record integration, ₦6 million–₦15 million or more for a record-aware portal with one meaningful healthcare-system integration, and ₦15 million+ for complex multi-site systems. These are illustrative scoping allowances, not surveyed market averages, fixed quotations or promises of regulatory compliance. An existing clinic software subscription may already include a portal and be a much better purchase.
The useful question is not “How much does a portal page cost?” It is which patient journeys are worth digitising, and what systems must be trusted for those journeys to work?
First, separate the three products people call a patient portal
A public clinic website helps people find doctors, understand services and request appointments. You can often launch this without patient accounts. See my clinic website cost guide if that is all you need.
A patient self-service portal adds authenticated access to appointments, billing, notifications or documents. Once a patient signs in, the system must decide exactly what that person can see and change.
An electronic health record (EHR/EMR) system manages clinical records and staff workflows. A patient portal may connect to it, but it should not casually become a replacement for it. If your current EHR has a patient-facing module, assess that before commissioning another database.
Patient portal development cost in Nigeria: practical budget bands
| Purchase | Illustrative initial allowance | What you are actually buying |
|---|---|---|
| Configure an existing EHR/vendor portal | Vendor quote, licence and setup costs | Activation, branding, staff training and any supported integrations |
| Focused custom self-service portal | ₦2m–₦5m | Patient accounts, appointment status, non-clinical notifications, billing view and staff administration |
| Custom portal with sensitive record access | ₦6m–₦15m+ | Above plus carefully controlled documents/results, audit trails, record-system integration and stronger testing |
| Multi-site or deeply integrated platform | ₦15m+ | Multiple facilities, more roles, legacy-system connections, data migration, operational resilience and support |
The numbers are my planning allowances for discussing scope, not a Nigerian market-price study. The last two rows can exceed those amounts substantially when clinical integration, independent security review, legal assessment or legacy-data cleanup is involved. A portal that handles real health records should never be approved from a budget table alone.
For a small clinic, a subscription is usually the first option to evaluate. A custom portal is easier to justify when the existing product cannot support a necessary workflow, several systems need connecting, or the clinic is building a differentiated service across locations.
What makes a patient portal expensive?
1. Identity is not the same as permission
Logging in proves that someone has authenticated. It does not prove they may view a particular result or bill. A patient, receptionist, clinician, branch manager and administrator need different permissions. Guardian or family access introduces another explicit relationship to verify.
In operational software I have worked on, permission design is most reliable when written as who may do what, to which record, under which conditions. That is the question I would insist on answering before portal screens are designed.
A practical acceptance test: patient A must not be able to retrieve patient B’s record by changing an ID, opening a copied link or calling the underlying API. Staff permissions need the same negative tests. Supabase’s Row Level Security guidance illustrates why database rules and privileges matter beyond hiding buttons.
2. Connecting to the clinic’s existing records
Ask the EHR vendor what it actually exposes: an API, supported exports, a secure integration service, or nothing usable. A portal that must manually re-enter lab results is not the same project as one that retrieves approved results from the source system.
HL7 FHIR is a healthcare interoperability standard worth discussing where relevant, but the presence of FHIR terminology in a quotation does not establish that your particular vendor supports the required endpoints or permissions.
Before budgeting integration, confirm which system owns each record, whether the portal only reads or can write back, what happens when systems disagree, and who resolves a failed sync.
3. Handling health information changes the obligation
Nigeria’s Data Protection Act 2023 treats health status as sensitive personal data and sets requirements around its processing and security. A developer’s promise of “encrypted data” is not a complete privacy or compliance plan.
A real project needs decisions on data minimisation, access logging, retention, breach handling, backups, service-provider responsibilities and patient support. The clinic should obtain appropriate legal/privacy and security review for its actual processing activities. No website developer should promise compliance merely because a login screen and HTTPS exist.
4. Payments need a trustworthy state
If patients pay deposits or bills online, the system must reconcile the payment with the right patient and obligation. A successful redirect is not sufficient evidence that the bill is paid. Paystack’s verification documentation explains server-side transaction verification; its webhook guidance explains event-origin checks and retries.
Ask what happens when a patient pays twice, a webhook arrives late, an appointment is cancelled, or a refund is initiated. Those are product requirements, not cosmetic edge cases.
5. Support and accessibility are part of delivery
Patients may use older phones, slower connections, assistive technologies or shared devices. Account recovery, readable results, simple navigation and safe session handling deserve deliberate testing. The W3C WCAG guidance is a useful accessibility reference.
Also budget for staff onboarding, failed-login support, monitoring, security updates and incident response. A launch without someone responsible for the system afterwards is an incomplete purchase.
Three examples that lead to very different quotations
Clinic A: Reduce appointment phone calls. Patients need to request appointments, receive confirmation and see whether a slot is approved. No medical history is exposed. The clinic may need a better public website and a scheduling tool, not a custom patient portal. Buying existing software or starting with the clinic website is likely the responsible first step.
Clinic B: Let patients retrieve approved diagnostic reports. Now the system must authenticate the patient, link them to the correct report, control when results become visible, record access and support secure retrieval. The clinic’s laboratory software and data-handling obligations drive the quote more than the number of pages.
Clinic C: Coordinate several branches. A patient may visit different locations, staff roles vary by branch, and old systems may disagree. Identity matching, delegated access, integrations, migration, audit trails and support become major workstreams. This is closer to a custom software programme than a website project.
Buy, configure or build: a decision rule
| Your situation | Better first move |
|---|---|
| Your EHR already includes a usable patient portal | Configure and test it before buying another system |
| You mainly need appointments and reminders | Use an established booking tool or a focused website integration |
| You need a branded interface over a supported EHR API | Scope an integration and portal layer, without duplicating clinical records unnecessarily |
| You need unusual multi-branch permissions or several legacy connections | Commission paid discovery for a custom build |
| You cannot yet describe who owns each record | Resolve the data and operational model before requesting a build quote |
Custom development is not inherently better because you own the code. It becomes valuable when ownership solves a real constraint and you can fund its continued operation.
What a serious development quote should include
I would ask for these deliverables in writing before approving a project:
- Scope and exclusions: exact patient, staff and administrator journeys, plus what is deliberately outside phase one.
- Data ownership and integration map: source systems, fields, permissions, sync direction, vendor dependencies and failure handling.
- Security and privacy work: role matrix, access tests, logging, data minimisation, review responsibilities and agreed acceptance criteria.
- Payment rules, if applicable: verification, reconciliation, reversals and the staff process for resolving exceptions.
- Testing evidence: normal journeys, denied-access cases, mobile usability, accessibility and recovery after failures.
- Launch and rollback: staging, backups, deployment ownership and what happens if the new portal must be withdrawn.
- Handover: repository, hosting and domain access in the clinic’s control, documentation, training and support terms.
A quotation that only lists “dashboard, patient login, admin panel and API” leaves the most expensive questions unanswered.
For the wider budgeting process, my custom software development cost guide explains why requirements and operational risk change the price. If you are building a new healthcare product rather than digitising an existing clinic, the MVP development cost guide may be a better starting point.
What to prepare before contacting a developer
Bring the name of your existing clinic/EHR software, the three patient tasks you most want to improve, the number of locations, the types of records involved, and who currently approves access or resolves mistakes. You do not need to send real patient records or passwords to request an estimate.
If the project includes payments, describe how billing works today and whether deposits, part-payments or refunds are needed. You can also review the separate payment integration cost guide.
My recommendation: start with the smallest workflow that genuinely reduces patient friction or staff workload, then test the permission and data boundaries before expanding. If you are deciding between configuring an existing system and commissioning a custom portal, tell me about your project. I can help define the first responsible technical scope and whether MVP development is the right route.