A clinic website has two very different possible jobs.
The first is public:
Help a patient understand the clinic, services, doctors, location and how to book.
The second is private:
Let a patient access records, documents, bills or care information.
The first is a website.
The second begins to look like healthcare software.
For 2026 planning in Nigeria, I would budget like this:
| Scope | Planning budget | Typical outcome |
|---|---|---|
| Professional clinic website | ₦450,000–₦900,000 | Services, doctors, contact, location, mobile design |
| Appointment-focused clinic website | ₦700,000–₦1.5m | Structured booking/enquiries, multiple services/locations, CMS |
| Booking + payments / deeper admin | ₦1m–₦2m+ | Scheduling rules, deposits, notifications, operations |
| Patient portal | Scope as software | Authenticated private information and workflows |
What a patient needs from the public site
A patient should not need to investigate your navigation to answer basic questions.
Make these easy to find:
- services;
- doctor/specialist information where relevant;
- opening hours;
- address and directions;
- phone/WhatsApp;
- appointment action;
- what to bring or expect where useful;
- emergency guidance where the clinic has a defined policy.
For a general structure, use my clinic website checklist.
What increases the price?
Multiple services and locations
One clinic location with six services is simpler than a group with several branches, specialists and different schedules.
Each additional structure needs a clear content model so the website does not become a list of duplicated pages.
Doctor profiles
Profiles can improve trust and help patients choose the right service.
They also create content-maintenance responsibility when doctors join, leave or change schedules.
Appointment scheduling
A request form is straightforward.
Real-time scheduling becomes more complex because the system may need to understand:
- doctors;
- locations;
- appointment types;
- duration;
- availability;
- cancellations;
- rescheduling;
- deposits;
- reminders.
See my broader booking website cost guide if scheduling is central to the project.
Payments
If the clinic accepts appointment deposits or other payments online, the website needs verified payment state.
Paystack currently lists Nigerian local online transaction pricing at 1.5% + ₦100, with the ₦100 waived under ₦2,500 and local transaction fees capped at ₦2,000. See Paystack pricing.
Do not mark an appointment paid only because a browser returned to a success page. Payment verification belongs in the backend workflow.
Keep public forms small
Healthcare creates an obvious temptation to ask for everything.
A first-contact form might not need a full medical history.
Ask what staff actually need before they can call the patient back or confirm an appointment.
Nigeria’s data-protection framework is overseen by the Nigeria Data Protection Commission. See the NDPC for current regulatory material.
At a practical level, define:
- what data the form collects;
- why it is collected;
- where it is stored;
- who receives it;
- who can access it later;
- how long it is kept.
A patient portal changes the risk profile
Once users log in to see private records, the application needs proper authentication and authorization.
OWASP’s Application Security Verification Standard provides a framework for testing technical security controls in web applications. See OWASP ASVS.
If a portal uses a platform such as Supabase, database-level access rules such as Row Level Security can help enforce which rows users can reach. Supabase recommends enabling RLS on exposed tables and applying least-privilege grants. See Supabase RLS.
The larger point is stack-independent:
A patient should not be able to reach another patient’s data because the interface forgot to hide a button.
The public website can launch before the portal
A clinic does not have to solve every digital workflow at once.
A sensible sequence can be:
- credible public website;
- appointment requests;
- verified payments where useful;
- only then, a properly scoped private portal.
That gets the acquisition problem solved without rushing the sensitive software problem.
What should the quote include?
Ask for clarity on:
- services and doctor templates;
- branches/locations;
- appointment behaviour;
- payment scope;
- data collected in forms;
- CMS/editor access;
- analytics;
- SEO;
- domain/hosting ownership;
- security responsibilities;
- maintenance;
- what is explicitly not a patient portal.
If your clinic needs a website but the conversation is already drifting into “patient dashboard, results, bills and documents,” send me the desired workflow. I can help separate the public website from the private software before the quote becomes impossible to compare.
