Pulse Clinic

Overview

Pulse Clinic is a healthcare management web application that connects patients with providers through a unified platform for appointment scheduling, digital intake forms, and document management. I built the back-end alongside a teammate as part of a six-week developer placement program that pairs developers with industry mentors to plan, build, and ship a real product from scratch.

The Program

This project came out of a free developer placement program designed to simulate a professional environment. Over six weeks, participants were paired with seasoned industry mentors who guided the team through the full product lifecycle — from initial planning and architecture through development and deployment. My role focused on back-end development, owning the API layer, database design, authentication flow, and Appwrite integration while collaborating closely with front-end teammates.

The Problem

Healthcare interactions still involve too much friction. Patients struggle to find the right provider, deal with phone-tag to book appointments, and fill out the same paper forms at every visit. Providers spend time on administrative overhead that pulls them away from patient care. Both sides need a centralized, digital-first system — but most existing solutions are either enterprise-priced or painful to use.

The Solution

A responsive web application that gives patients and providers each a tailored dashboard. Patients can search for providers by specialty and rating, book and reschedule appointments, complete intake forms with file uploads, and manage their health documents in one place. Providers get a management view of their appointments, patient submissions, and incoming forms — all behind secure, role-based authentication.

Key Features

• Secure authentication and registration with role-based access for patients and providers
• Provider search with filtering by specialty, location, and top-rated doctors
• Full appointment lifecycle — booking, rescheduling, cancellation, and history
• Digital intake forms with file attachment support for insurance cards and medical records
• Personalized dashboards surfacing upcoming appointments, submitted forms, and relevant alerts
• Responsive UI with DaisyUI components for consistent, accessible interactions across devices

Technical Decisions

Why Appwrite for the back end? The six-week timeline meant we needed a backend that handled auth, database, and file storage without spending weeks on infrastructure. Appwrite gave us a unified SDK for all three, and its permission model let us enforce patient-provider data boundaries at the database level rather than only in application code.

Why DaisyUI over shadcn/ui or Radix? With a compressed timeline and a team split between front-end and back-end, DaisyUI’s ready-made component set on top of Tailwind let the front-end team move fast without sacrificing design consistency. It reduced the number of styling decisions that needed cross-team coordination.

How we split the work. I owned the Appwrite schema design, authentication flow, API routes, and file storage logic. My teammate handled the front-end components, routing, and UI state. We synced daily with our mentor, who pushed us toward patterns we’d encounter on a real engineering team — code reviews, documented API contracts, and feature branches.

What I Learned

Working under a six-week deadline with a mentor reviewing our decisions changed how I think about trade-offs. We had to scope aggressively — features like real-time notifications and provider availability calendars got cut early so we could ship a polished core. The mentor pushed us to document our API contracts before writing code, which eliminated most of the integration friction between front-end and back-end. It was the closest thing to a professional sprint cycle I’d experienced, and the collaboration and accountability made the final product significantly stronger than what I would have built solo.