How We Built
The Cupping Guy

The Brief — What We Were Asked to Build

The Cupping Guy is a specialist Hijama (wet cupping) and muscular therapy practice based in London. When 9WEB was brought on, the client had no website and no digital infrastructure at all. Appointments were managed manually through WhatsApp and phone calls — which worked when the client had a handful of patients, but quickly became unmanageable as the practice grew.

The brief had two distinct parts:

Off-the-shelf solutions like Calendly, Acuity or Squarespace bookings were considered and rejected. They either lacked the custom client record management needed, added unwanted branding, or couldn't integrate with a dedicated client portal. The decision was made to build everything bespoke.

Website Design — Look, Feel & Structure

The design brief for the public website was: trustworthy, clean, and health-focused. Hijama is a traditional Islamic and holistic therapy — the design needed to feel calm and professional, not clinical. Patients needed to feel they were in safe, expert hands before they'd even picked up the phone.

Colour palette: Deep forest green as the primary brand colour, paired with white and a warm off-white. Green was chosen deliberately — it signals healing, nature and wellbeing without the starkness of a medical white. A teal accent was used for calls-to-action to create contrast and guide the eye toward booking buttons.

Typography: A clean sans-serif (Plus Jakarta Sans) throughout — readable at all sizes, professional, never cold. Headers carry appropriate weight without feeling aggressive.

Page structure built:

• Homepage — hero with a clear headline and CTA, services overview, about snippet, trust signals (years of experience, treatments delivered), and a direct link to the booking portal
• Services pages — individual pages for Hijama (Wet Cupping), Fire Cupping, Deep Tissue Massage, Spinal Alignment, Sports Massage, Posture Correction and Detox. Each with treatment description, what to expect, preparation advice and a booking CTA
• About page — practitioner background, qualifications, why Hijama, Islamic context of the practice
• Contact page — location map, phone, email and a link to the portal

Mobile-first approach: The majority of health and therapy searches happen on mobile. Every page was designed mobile-first — the desktop layout is an enhancement, not the primary focus. Touch targets, readable font sizes and fast-loading images were non-negotiable.

Frontend Code — HTML, CSS & JavaScript

The website frontend was built in clean, semantic HTML5 with custom CSS3 — no Bootstrap, no heavy UI framework. This kept the site fast (critical for Google Core Web Vitals) and gave us full control over every pixel.

Why no framework? Bootstrap and Tailwind are excellent tools, but they add overhead. For a focused 6-page site, a purpose-built stylesheet is lighter, faster and simpler to maintain. The CSS was structured using custom properties (variables) for the colour palette and spacing system, making global changes trivial.

/* Brand variables — change here, updates everywhere */
:root {
  --green-primary:  #1a6b35;
  --green-dark:     #0f3a1f;
  --teal-accent:    #00bfa6;
  --white:          #ffffff;
  --off-white:      #f7f9f4;
  --font-body:      'Plus Jakarta Sans', sans-serif;
  --radius:         10px;
  --shadow:         0 8px 32px rgba(15, 58, 31, 0.12);
}

JavaScript: Vanilla JS only — no jQuery, no React. The scripts handled mobile navigation toggling, scroll-triggered animations using the Intersection Observer API, smooth anchor scrolling and form validation on the contact page.

// Reveal elements as they scroll into view
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.classList.add('visible');
      observer.unobserve(entry.target);
    }
  });
}, { threshold: 0.12 });

document.querySelectorAll('.reveal').forEach(el => {
  observer.observe(el);
});

Performance: Images were compressed and served in WebP format where supported. Fonts were loaded with display=swap to prevent invisible text during load. The site consistently scores 90+ on Google PageSpeed Insights — which directly impacts search rankings.

Database Design — The MySQL Schema

The booking portal is backed by a relational MySQL database. Getting the schema right at the start is critical — a poorly structured database creates problems that compound over time. We mapped out all the entities, their relationships and their constraints before writing a single line of PHP.

The database has five core tables:

The appointments table is the heart of the system. Its status column uses an ENUM — 'pending', 'confirmed', 'cancelled', 'completed' — which constrains the value at database level, not just application level. This prevents dirty data from ever entering the system.

Foreign key constraints between appointments → clients and appointments → services ensure referential integrity — you can never have a booking for a non-existent client or a deleted service.

Backend API — PHP 8 Endpoints

The backend is built in PHP 8 following a clean endpoint-per-action pattern. Rather than a heavy MVC framework, we used a lightweight router that maps URL paths to handler functions — keeping the codebase minimal and easy to reason about.

All database access uses PDO with prepared statements. This is non-negotiable — it is the only correct way to interact with a MySQL database in PHP. String concatenation in SQL queries creates SQL injection vulnerabilities; prepared statements make that structurally impossible.

// ✅ Correct — prepared statement, SQL injection impossible
function getClientByEmail($pdo, $email): array|false {
    $stmt = $pdo->prepare(
        'SELECT * FROM clients WHERE email = :email LIMIT 1'
    );
    $stmt->execute(['email' => $email]);
    return $stmt->fetch(PDO::FETCH_ASSOC);
}

// ❌ Wrong — NEVER do this (SQL injection risk)
// $result = $pdo->query("SELECT * FROM clients WHERE email = '$email'");

The core API endpoints built:

The Booking Logic — How Slot Generation Works

The availability engine is the most technically interesting part of the system. It needs to answer a simple question — "what times are free on this date for this service?" — but doing so correctly requires several steps.

function getAvailableSlots($pdo, $date, $service_id): array {

    // 1. Is this date blocked entirely?
    $blocked = isDateBlocked($pdo, $date);
    if ($blocked) return [];

    // 2. Get working hours for this day of week
    $dayOfWeek = (int) date('N', strtotime($date)) - 1;
    $hours = getWorkingHours($pdo, $dayOfWeek);
    if (!$hours) return []; // day off

    // 3. Get service duration
    $duration = getServiceDuration($pdo, $service_id);

    // 4. Generate all possible slots
    $allSlots = generateSlots(
        $hours['start_time'],
        $hours['end_time'],
        $duration
    );

    // 5. Remove already-booked slots
    $booked = getBookedTimes($pdo, $date);
    return array_diff($allSlots, $booked);
}

Handling race conditions: Two clients could theoretically see the same slot available at the same moment and both try to book it. To handle this, the final booking write uses a database transaction with a SELECT ... FOR UPDATE lock on the relevant time slot row. If both requests arrive simultaneously, the database serialises them — the first commits successfully, the second gets a conflict error and the user sees a "sorry, that slot was just taken" message.

Authentication & Security

Any system handling personal health data and client records has a serious obligation to be secure. We took a layered approach — multiple independent security controls so that if one fails, others still protect the system.

Email Automation — Confirmations & Reminders

Automated emails are a core feature of the booking experience. Clients expect an immediate confirmation when they book, and a reminder before their appointment. We built this using PHPMailer — the industry standard PHP email library — sending via a dedicated SMTP relay for reliable delivery.

Why not PHP's built-in mail() function? Because it's unreliable on shared hosting, offers no authentication, and gets flagged as spam far more often. PHPMailer with SMTP authentication gives us proper delivery, TLS encryption, and bounce handling.

function sendBookingConfirmation($client, $appointment, $service): bool {
    $mail = new PHPMailer(true);
    $mail->isSMTP();
    $mail->SMTPAuth   = true;
    $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
    $mail->Username   = getenv('SMTP_USER');  // from .env
    $mail->Password   = getenv('SMTP_PASS');  // never hardcoded

    $mail->addAddress($client['email'], $client['first_name']);
    $mail->addBCC('bookings@thecuppingguy.com'); // practitioner copy
    $mail->Subject = 'Your appointment is confirmed — The Cupping Guy';
    $mail->isHTML(true);
    $mail->Body    = renderEmailTemplate('confirmation', [
        'name'    => $client['first_name'],
        'service' => $service['name'],
        'date'    => formatDate($appointment['appt_date']),
        'time'    => $appointment['appt_time'],
    ]);
    return $mail->send();
}

SMTP credentials security: Notice the credentials are fetched from getenv() — they live in a .env file on the server, outside the web root, and are never committed to any repository. This is standard practice and means credentials are never exposed even if source code is somehow leaked.

Three automated emails are sent:

1. Booking confirmation — triggered immediately on successful booking. Contains service name, date, time, location details and preparation notes specific to the treatment booked.
2. 24-hour reminder — sent the day before the appointment. This runs via a scheduled task (cron job) that queries for all appointments happening tomorrow morning and emails each client.
3. Cancellation confirmation — triggered when a client or the practitioner cancels. Both parties are notified with the next-steps message.

The Admin Panel — What the Practitioner Sees

The admin panel is the practitioner's command centre. It lives at /admin — a route that checks for an admin session on every request. No admin session means an immediate redirect to the admin login page, with no information about what's behind the route.

Admin capabilities built:

• Dashboard overview — today's appointments at a glance, upcoming bookings this week, total clients registered, recent cancellations
• Calendar view — monthly calendar showing booked, available and blocked days. Click any day to see that day's appointments in full detail
• Appointment management — view, confirm, complete or cancel any appointment. Add private practitioner notes visible only in the admin panel
• Client directory — searchable list of all registered clients with full contact details, health intake notes and complete appointment history per client
• Availability management — set working hours per day of week. Toggle days on/off. Add blocked dates (holidays, training days) with a reason note
• Service management — add, edit or deactivate services. Update prices, descriptions and durations. Deactivated services stop appearing in the booking flow without deleting historical data

Deployment — Taking It Live

The platform is hosted on Hostinger shared hosting — deliberately. The client didn't need a VPS or cloud server; shared hosting with PHP 8 and MySQL is perfectly capable of handling this traffic volume, costs a fraction of the price, and is far simpler to manage.

Before going live, a deployment checklist was worked through:

The full project — website design, frontend code, database design, backend API, admin panel, email system and deployment — was completed and delivered by 9WEB. The platform has been running reliably since launch with zero unplanned downtime.