Maria Ebrahimi
Maria Ebrahimi
  • Home
  • About
  • Experience
  • Services
  • Projects
Maria Ebrahimi
HomeAboutExperienceServicesProjects

Shafadoc — Doctor Appointment Booking Platform

Shafadoc — Doctor Appointment Booking Platform

Shafadoc — Doctor Appointment Booking Platform

A full appointment-booking platform for hospitals and doctors, built solo end-to-end in Next.js — a public SEO-optimized website and a data-heavy admin panel, both shipped by one developer.

ROLESolo Frontend Developer
STACKNext.js + TypeScript
PLATFORMWeb App
TIMELINE10 Months
Scroll to explore

Project Overview

// section.overview

01

A booking platform connecting patients, doctors, and hospitals

Shafadoc is a two-sided appointment-booking platform built entirely in Next.js — a public-facing website where patients search doctors and hospitals and book appointments, and an admin panel where staff manage doctors, schedules, content, and hospital locations. As the sole frontend developer, I owned both halves: a public site rendered with a mix of SSR, ISR, and SSG depending on page volatility for strong SEO and fast load times, and an operationally dense admin panel built around AG Grid for large tabular datasets, CKEditor for rich content management, and React Leaflet for visualizing hospital and doctor locations on interactive maps.

A complete digital transformation for auto service centers
ROLESolo Frontend DeveloperWebsite + admin panel, end-to-end
PLATFORMWeb AppPublic website + admin panel
STACKNext.jsAG Grid, CKEditor, React Leaflet
GOALFast, SEO-Ready Booking PlatformMaintainable at scale, solo-built

Key Screens

// section.key.screens

02
Two products, one consistent system
Every screen was built to handle real data volume without sacrificing speed or clarity.
Home Page
Doctors List
Appointments Modal
Calendar Modal
Doctor Profile
Doctor Appointments (Admin)
User Sub-users
User Appointments

Project Problem

// section.problem

03

One developer, two demanding surfaces to ship and maintain

Shafadoc needed two very different products under one roof: a public website that had to load fast and rank well on search engines, and an internal admin panel dense enough to manage thousands of doctors, hospitals, and appointment records. Building and maintaining both alone meant every architectural decision had to hold up under nested, interdependent logic without a team to catch mistakes or split the workload.
Public pages needed strong SEO without sacrificing dynamic, frequently changing data
Different pages had very different freshness needs — some near-static, some updated constantly
Admin panel required managing large doctor/hospital datasets without UI slowdown
Rich content (doctor bios, articles) needed non-technical staff to edit safely
Hospital and doctor locations needed clear, interactive map-based visualization
Complex, nested business logic (schedules, sub-users, appointments) had to stay maintainable solo
No second developer to review architecture decisions or share the maintenance load

Stakeholder Needs

// section.stakeholder.needs

04
What the product needed to succeed
Working directly with the product owner, the core technical requirements were clear from day one.

Strong Search Engine Visibility

The public website needed to rank well for doctor and hospital searches, which meant server-rendered, crawlable pages and a properly generated sitemap.

Fast Page Loads Across the Site

Patients searching for doctors needed near-instant page loads, even on content-heavy pages like doctor profiles and hospital listings.

A Capable Admin Panel for Non-Technical Staff

Hospital staff needed to manage large volumes of doctors, schedules, and appointments through tables and forms that stayed fast and usable at scale.

Rich Content Management

Doctor bios, hospital descriptions, and articles needed a rich-text editing experience staff could use without touching code.

Location-Based Discovery

Patients needed to visually locate nearby hospitals and doctors on a map, not just browse a flat list.

Maintainable Architecture for the Long Term

Since one developer would own the codebase indefinitely, the architecture needed to stay clean and extensible as features were added over time.

Customer Needs

// section.customer.needs

05
What patients and hospital staff actually needed
Two very different users had to be served well by the same platform.
Patients: fast search and booking flow with minimal friction
Patients: clear doctor profiles with real availability and location
Patients: the ability to manage appointments for family members (sub-users)
Hospital staff: an admin panel that handles large datasets without lag
Hospital staff: safe, simple content editing without developer involvement

Design Process

// section.design.process

06

ARCHITECTURE PLANNING

Mapping page types to SSR, ISR, and SSG rendering strategies

Public Website Build

SEO-optimized pages, sitemap generation, performance tuning

Admin Panel Core

AG Grid tables for doctors, hospitals, and appointments

Content & Location Tools

CKEditor integration and React Leaflet map views

Booking Logic

Nested scheduling, sub-users, and appointment flows

Optimization Pass

Performance and maintainability review across both surfaces

Launch

Production deployment, solo-maintained going forward

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
  1. ARCHITECTURE PLANNING

    Mapping page types to SSR, ISR, and SSG rendering strategies

  2. Public Website Build

    SEO-optimized pages, sitemap generation, performance tuning

  3. Admin Panel Core

    AG Grid tables for doctors, hospitals, and appointments

  4. Content & Location Tools

    CKEditor integration and React Leaflet map views

  5. Booking Logic

    Nested scheduling, sub-users, and appointment flows

  6. Optimization Pass

    Performance and maintainability review across both surfaces

  7. Launch

    Production deployment, solo-maintained going forward

The Solution

// section.solution

07
How the platform was built to handle both sides at once

SEO-Optimized Rendering Strategy

[01]

Pages were rendered using a deliberate mix of SSR, ISR, and SSG based on how often each page's data changes, paired with a generated sitemap — giving strong SEO without giving up performance.

Scalable Admin Data Tables

[02]

AG Grid powers the admin panel's core tables — doctors, hospitals, appointments — handling large datasets with sorting, filtering, and inline editing without performance drop-off.

Rich Content Editing for Non-Technical Staff

[03]

CKEditor integration lets hospital staff edit doctor bios, hospital descriptions, and articles directly, with no developer involvement required.

Interactive Location Mapping

[04]

React Leaflet renders hospital and doctor locations on interactive maps across both the public site and admin panel, making location-based discovery visual instead of list-based.

Learning & Reflections

// section.learning.reflections

08
01

Choosing the Right Rendering Strategy Per Page

Not every page needed the same rendering approach. Matching SSR, ISR, or SSG to each page's actual data volatility was key to getting both SEO and performance right at the same time.

02

AG Grid at Scale Needs Careful Configuration

Handling large admin datasets smoothly meant going beyond default AG Grid setup — tuning column virtualization and data-fetching patterns to keep large tables responsive.

03

Rich Text Editors Need Guardrails

Giving non-technical staff a CKEditor instance meant thinking carefully about sanitization and consistent output, so content stayed safe and visually consistent across the site.

04

Solo Ownership Forces Architectural Discipline

Without a team to share the maintenance load, keeping nested business logic — schedules, sub-users, multi-role appointments — clean and predictable was essential to staying productive alone.

05

SEO Is a Frontend Architecture Decision, Not an Afterthought

Building the sitemap and rendering strategy in from the start, rather than retrofitting it, made the site's SEO performance far more reliable.

06

Map Integrations Reward Early Data Modeling

Getting hospital and doctor location data modeled consistently early on made the React Leaflet integration straightforward instead of a late-stage scramble.

Next Project

Solar & Wind Energy Management

Solar & Wind Energy Management

Front-End Developer

Front-End Developer
profile

Let's Talk

Ready to build something great together?

I'm currently available for new opportunities and exciting projects.
Feel free to reach out — I usually reply within 24 hours.

© 2026 Maria Ebrahimi— Designed & built with care.